On 02/19/2015 04:42 PM, Guy Sotomayor wrote: That wasn't very good practice, was it? Write on a coding form (or paper), then punch, run an 80-80 list on a 407 and hand check, correct and then submit. --Chuck

On 02/19/2015 06:46 PM, Lyndon Nerenberg wrote: CDC management so detested programmers punching their own cards that they made it really inconvenient. There was a keypunch located at each corner of the building,*on a timer*--one of those clickety-click ones with a knob. I recall that you could get about 10 minutes per twist. I mean, why waste your time keypunching, when you could submit it to the gals in keypunch to mis-type your stuff? Of course, real terminals were kept from the programmers as well. When we finally managed to talk management into installing real video terminals, they took about 15 of them and put them all on tables in *one* room. Heaven forfend that anyone should have one on their desk! It didn't really matter much to me--being in systems software, I used lots of committed block time usually during the wee hours of the night where there were keypunch machines available all over an essentially empty building. If I needed a patch card while I was on the machine, I could always run the o26 PPU program on the DD60 operator's console. The way to be productive back then was to be invisible. --Chuck

On 2/19/15 5:30 PM, Chuck Guzis wrote: Nope. It was (and still is) how I write code (sit down and compose at the keyboard). One of my old bosses at IBM once said "Yea, Guy just waves his hands over the keyboard and programs come out". TTFN - Guy

I don't know about on MVS but on VM there is a comprehensive system which is fully integrated with the editor XEDIT. You do have to create a reference for each change, but once that's done you can just edit away and the editor maintains a separate file of changes for that module. One major problem with the system is that it only works for card images , so columns 73-80 are used as sequence numbers. When a deck has to be re-sequenced a kind of madness ensues. Dave G4UGM COBOL

On 02/20/2015 07:22 AM, Shiresoft wrote: That's not an unusual skill if you spent hours day after day, poring over OS core dumps trying to figure out what went wrong. I can--and suppose many other OS developers also--remember instruction codings for machines not seen in decades. It used to be the custom that one learned to program a computer by first learning the instruction opcodes and format. I recall coding forms labeled "IBM 1620 Absolute Programming System". IIRC (and I'm not sure that I do) the flipside was an SPS coding form. I'm not at all certain that such a skill is even marginally valuable today. Who codes much in assembly, much less machine code? C has firmly established itself in the once memory-constrained MCU world, so not even there. It's a skill of fossils, like being able to recite great chunks of Caesar's commentaries on the Gallic War. At best, most can vaguely misquote "Gallia est omnis divisa in partes tres"--at worst, many don't even know who Caesar was, outside of the name for a salad made with eggs and anchovies. --Chuck

On 02/20/2015 12:27 PM, Mouse wrote: Uh, huh--and probably someone writing a good optimizing compiler. But that's how many people outside the vast sea of script kiddies? To put it another way, how many advertisements for job openings include "must recognize and interpret Super Wazoo 800 machine codes"? I can't recall ever having seen such a requirement. Generally it's something one picks up if and when it's needed, not a particularly unique skill, such as being able to mentally factor 20 digit integers. --Chuck

On 02/20/2015 01:09 PM, Mouse wrote: Like knowing COBOL" :) --Chuck

Excuse my ignorance but then how is a compiler written? I always thought that you would need to know op codes and assembler to write a compiler. I.E. you can't write and efficient compiler by using a high level language.

On 02/20/2015 02:32 PM, Ali wrote: You have a front-end, which does the lexical work and translates the program into some intermediate form, such as a tree. In the middle, you have optimization and checking--and finally, you have the back end which essentially emits code--but that doesn't necessarily imply that the compiler author knows the numeric opcodes or the precise instruction format. Many compiler backends feed into an existing assembler, which puts it all together. Knowing the numeric opcodes and instruction format isn't all that it would seem to be. I never had much more than a passing familiarity with the numeric opcodes of the CDC STAR--given that there was 8 bits for the opcode and 8 more "modifier" bits, you arguably had a machine with thousands of opcodes. What was hardest and very important was committing to memory the *timings* of those instructions, within a superscalar, segmented, pipelined vector architecture. --Chuck

On 2/20/2015 5:02 PM, Dave G4UGM wrote: I would say that is 50%. If you have LEXX and YACC you tend have a UNIX system with a C compiler. How do handle byte operations in C like *x++ on a PDP 10? Time for POWER code re-arrangement. Ben.

From: Johnny Billquist Sent: Friday, February 20, 2015 4:51 PM Are you even certain that it is a byte operation??? All I see is an increment of an object in memory pointed to by the variable "x". Now, had we been told what the declaration of "x" is, the question would be more meaningful, but if it's something less than word sized, then the byte manipulation instructions would work just fine. I don't see a problem, and think that this is a pretty weak straw man. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

On 2015-02-21 02:11, Rich Alderson wrote: Good point. I just assumed that x was a char pointer. But actually, unless I'm confused, it's a dereference of x (which is some kind of pointer), followed by an increment of that pointer. But I could be remembering wrong in which order these operations bind. Agree. Not sure what ben was trying to make of this. No matter which way to read things, there are no special problems on a PDP-10. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2015-02-21 02:26, Chuck Guzis wrote: Misunderstanding 1: a char do not need to be 8 bits. Also, an int is defined to be whatever size makes most sense on a machine. It can be any number of bits. The only thing guaranteed is that an int is between a short and a long in size. (They can all be equal.) All that said, much C code make way more assumptions than the standard allows. Plenty of sloppy programmers around. And all that said, I do think the basic "unit" must be the same in all places. So if you report sizeof as 9-bit chunks somewhere, it needs to be 9-bit chunks everywhere else as well. So you cannot have sizeof(int) == sizeof(char), unless they actually contain the same number of bits. And since sizeof returns an integer, you pretty much also needs to make one a multiple of the other as far as number of bits goes. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 02/20/2015 09:47 PM, Eric Smith wrote: What does the C standard say about the physical size of an int in bits, versus the largest and smallest integer that can be held in those bits? Consider a 64 bit int which is a simple degenerate floating point number with 16 bits of mantissa (presumably set to 0) and 48 signed bits of mantissa. All math done in unnormalized floating point. Does C require 1's or 2's complement or can it support sign-magnitude integers? --Chuck

Keep in mind, that K&R C is a C, not just "C like", without many of the restrictions of ANSI C. I actually agree with most of the ANSI CHANGES to C. BUT, K&R C IS C, not "C like", in spite of not being "ANSI C" On Sat, 21 Feb 2015, Sean Conner wrote: Some minor NITS: IIRC, K&R permitted sizeof(short) <= sizeof(long) You COULD build a C with 32 bits for every type. You COULD build a C with 16 bits for every type, but hopefully would not. Memory was more limited in those days; IIRC, K&R warned against assuming that sizeof(char*) == sizeof(int) those should be 0 .. 65535 16 bit 2's complement goes from -32768 ... 32767 does the ANSI standard leave off the -32768? (not objecting, just curious) likewise -2,147,483,648 -- Grumpy Ol' Fred cisin at xenosoft.com

On 2/21/2015 10:07 AM, Fred Cisin wrote: The compilers for some of the Texas Instruments DSP devices are like that. TMS320C33 (and variants), for example. In my application, raw speed was very important and there wasn't a lot of 8-bit data. Bob.

Okay. Well, we _can_ have short/int/long all having 64 bits. Even char, too, I think. Well, this makes it impossible to implement long long, which (loosely put) must have at least 64 bits of range. But let's pretend that long long doesn't exist, or perhaps that all the bit counts you give are doubled, or some such. I'm not sure. The C99 draft I have says (6.2.6.1) [#5] Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.41) Such a representation is called a trap representation. Footnote 41 says 41)Thus, an automatic variable can be initialized to a trap representation without causing undefined behavior, but the value of the variable cannot be used until a proper value is stored in it. The boolean operations on unsigned integer types would have to be implemented in a way that's careful to avoid messing up the magic exponent-field value (they couldn't just be 64-bit boolean operations, in general). The wording about "character type" above appears to be intended to support idioms like for (i=0;i<sizeof(thing);i++) ((char *)&thing2)[i] = ((char *)&thing1)[i]; However, there are constraints on how integers are represented, specifically on how signed and unsigned integers are related, that might break the above. 6.2.6.2 (remember the missing supserscripting): [#1] For unsigned integer types other than unsigned char, the bits of the object representation shall be divided into two groups: value bits and padding bits (there need not be any of the latter). If there are N value bits, each bit shall represent a different power of 2 between 1 and 2N-1, so that objects of that type shall be capable of representing values from 0 to 2N-1 using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified.44) 44)Some combinations of padding bits might generate trap representations, for example, if one padding bit is a parity bit. Regardless, no arithmetic operation on valid values can generate a trap representation other than as part of an exceptional condition such as an overflow, and this cannot occur with unsigned types. All other combinations of padding bits are alternative object representations of the value specified by the value bits. [#2] For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. There need not be any padding bits; there shall be exactly one sign bit. Each bit that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type (if there are M value bits in the signed type and N in the unsigned type, then M<=N). If the sign bit is zero, it shall not affect the resulting value. If the sign bit is one, the value shall be modified in one of the following ways: -- the corresponding value with sign bit 0 is negated (sign and magnitude); -- the sign bit has the value -(2N) (two's complement); -- the sign bit has the value -(2N-1) (one's complement). Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one's complement), is a trap representation or a normal value. In the case of sign and magnitude and one's complement, if this representation is a normal value it is called a negative zero. ... [#5] The values of any padding bits are unspecified.45) A valid (non-trap) object representation of a signed integer type where the sign bit is zero is a valid object representation of the corresponding unsigned type, and shall represent the same value. 45)[...basically a repeat of footnote 44, above...] I think this permits what you sketch, but your sketch is brief enough I'm not entirely sure. It's also possible I've missed a constraint somewhere else that's relevant. I'll ask my go-to C guy about this. FSVO "byte", I agree. However, since we've been discussing C, there's a _lot_ of (C) code that assumes that char * has the same size and representation as other pointer types, even though there's no justification in the C spec for such an assumption. (POSIX, on the other hand, may impose such a restriction; I don't have even a draft of POSIX handy to check.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sat, 21 Feb 2015, Chuck Guzis wrote: Will you include optional conversion for morse code for the console I/O? (dot/dash/space) ANSI C will be incompatible with it, but a K&R C might be possible. -- Grumpy Ol' Fred cisin at xenosoft.com

Could work, just as today some C implementations do long long by gluing together two 32-bit words. Of course not. With difficulty. Integer shift couldn't be just a shift operation applied to the 64-bit representation; it would have to be more complex than that. But it could certainly be done. If the padding is scattered around sufficiently randomly it might be easiest to implement shift operations as calls to a support function. Given its genesis - the era and the original target - I kind-of do. Yes. Not very C-friendly - or, to turn it around, C is not very bit-addressable-hardware-friendly. It certainly would be possible to design a C-ish language with support for directly addressible bits. I think it'd be an interesting experiment. C is oblivious to a lot of things - though its influence, mostly through Unix and then POSIX, is strong enough that many of them aren't noticed nowadays (and I think the world is the poorer for it). Yes. I've felt that way about POSIX for some time now: that anything that can't be fit into a POSIX framework semi-can't be done, producing a positive feedback loop that only ensures the POSIX way becomes even more entrenched. I became very aware of this in 2002, when I was hired to take an experimental encrypted distributed storage paradigm and make it mountable as a filesystem on a Unixy system (NetBSD, specifically). The impedance mismatch was severe, because the paradigm in question couldn't really support a POSIXy write() directly - it had versioning and a naive implementation would have created a new version of the file on every write(). Since it didn't do delta compression (and really couldn't, given the way it was encrypted), this would have meant that small changes to large files would have flooded the system with similar large files whose similarity could not be exploited to reduce storage costs. I ended up introducing a `freeze' operation, so that write() affected only a not-yet-stored copy-in-progress, with it getting pushed to the tree of versions only upon freezing. Yes - though modern C has aliasing rules that make life significantly easier for optimizing compilers (but correspondingly harder for programmers used to the "pointers are just memory addresses" mental model. :-) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 02/21/2015 08:25 PM, Eric Smith wrote: The reason I asked was because of the Seymour Cray/Jim Thornton philosophy on design. I don't know if this is reflected in the Cray 1, but it certainly is the case in the CDC 6000-7000 series as well as the STAR/Cyber 200/ETA-10 line. The 6000/7000 machines have a long add (60 bit) unit, but no integer multiply/divide unit--it's possible to perform a multiply or divide yielding a 60-bit integer, but it's a bit involved and generally not done. So significance on integers is limited to 48 bits out of 60. The Cray 1, of course, didn't even have a divide unit--just a "floating point reciprocal approximation" instruction. The Cyber/STAR goes a bit farther in not mentioning the word "integer" at all and divides the 64 bit word into two parts--the exponent/length high-order part of 16 bits and the significand/index part of 48 bits. Any integer operations are conducted as "index" operations and the sign bit is bit 47. Period--no 64 bit integers at all. Bit-logical operations operate on the entire 64 bit word. Double-precision floating point is the pretty much the same on both 60 and 64-bit systems--an upper and lower floating point part, each being a complete floating point number with exponent. No integers per se. I know there was a C for the ETA units, but I don't know if a C existed for the 60-bit machines. But it wouldn't surprise me if it did. --Chuck

The one C compiler that was written at my University for the Tops-20 allowed you to select 6, 7, 8 or 9-bit chars. This was written in 1984-88 or so, and was a pure K&R compiler with prototypes added. This was, at the time, standards conforming because K&R didn?t require any of that fancy ANSI-C stuff (which was still years away). There were a number of tricks used to make the math work out right, since the architecture was word addressed. IIRC, it relied on char * pointers being ?special?. All pointers were 36-bit in size, with some of the upper bits being used to address sub-word quantities for character operations. The character size was, iirc, fixed for all compilation units. The compiler was a wizard at figuring out all the nuances. But since only 22 of the 36 bits could ever be used for an address, the extra bits in pointers were otherwise ?wasted?. It make conversion between int and pointers and doing math on them somewhat undefined or at least somewhat different than one would otherwise expect. Sadly, at the time a metric truckload of code expected pointers and ints to be freely convertible, and all pointers to be byte addressable with a linear space. It was ?C? enough that most things ran well enough. Many constructs that you wouldn?t think would work in this mixed up, jumbled up world actually did work. Also, IIRC, there was no such thing as a void * in this compiler (and if there was it would be identical to a char *). But it did mean that something like: char ch[10]; char *cp = ch + 5; (char *)(int *)cp; /* Might not equal cp any more */ gcc has (had?) a pdp10 mode to support the toad-1, but I never used that. And I stopped using Greg Titus? C compiler back in ?89 when I left school. It was sold to some outfit out of Santa Fe and Greg moved there about the same time I left school to support it. Not sure what ever happened to him after that. He also taught my intro to C class, so I learned all manner of ?safe? C perversion from him?. Warner

Yes and no. It has to be made up of an integral number of chars in the sense that sizeof(int) must be an integer. But those bits do not have to all be value bits; some can be padding bits. Five seven-bit chars plus one extra bit in a 36-bit word won't fly (and not just because of the minimum information content of a char). Of course, C being what it is, you might be better off scrapping formal conformance to the spec and building a not-quite-C language that's more useful on that hardware. 60-bit words? I'd be inclined to use 10-bit, or perhaps 12-bit, chars. Whether it's reasonable to call those `bytes' depends on whether you buy into the modern "`byte' means `octet'" interpretation. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 2015-02-21 01:02, Dave G4UGM wrote: Uh... LEX and YACC are used for the frontend side. They do not have anything to do with code generation. :-) Using LEX and YACC, you will still need to write the code that actually generates the output from the whole thing. LEX and YACC essentially implements the parsing of the source code for you. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2015-02-21 02:40, Chuck Guzis wrote: I would dare to say that pretty much none are, and none have been for the last 30 years at least. Yes. That is pretty much how compilers work today as well. You compile to some abstract intermediate form, and then you have a backend that translates into actual machine code for the target machine. It's been that way for a long time... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol