On 2021-06-20 1:39 p.m., Paul Birkel via cctech wrote: Not sure if it's what you are looking for, but if you haven't, check out "Classic Operating Systems" by Per Brinch Hansen. Pretty sure I own one, by Dijkstra. Will get details later if you are interested. --Toby

When it comes to McCracken I feel a bit like Homer Simpson "Donuts ... is there anything they can't do?" He certainly made a career out of writing programming language instruction texts. -----Original Message----- From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Norman Jaffe via cctech Sent: Sunday, June 20, 2021 10:26 AM To: General Discussion, On-Topic Posts Only Subject: Re: Early Programming Books I have two books on ALGOL 60 from 1962 - A Guide to ALGOL Programming, Daniel D. McCracken A Primer Of ALGOL 60 Programming, E.W. Dijkstra For APL, there is this from 1962 - A Programming Language, Kenneth E. Iverson However, I also have a reference from 1960 - LISP I Programmer's Manual, J. McCarthy et al. From: "General Discussion, On-Topic Posts Only" <cctech at classiccmp.org> To: "Paul Birkel" <pbirkel at gmail.com>, "General Discussion, On-Topic Posts Only" <cctech at classiccmp.org>, "dave g4ugm" <dave.g4ugm at gmail.com> Sent: Sunday, June 20, 2021 5:57:08 AM Subject: Re: Early Programming Books On 2021-06-20 1:39 p.m., Paul Birkel via cctech wrote: Not sure if it's what you are looking for, but if you haven't, check out "Classic Operating Systems" by Per Brinch Hansen. Pretty sure I own one, by Dijkstra. Will get details later if you are interested. --Toby

Thank you for the references Paul. Found it at: www.cs.utexas.edu/users/EWD/MCReps/CR1957-009.PDF Also found "Course on programming in ALGOL 60 (11th Edition)" (1970): https://www.cs.utexas.edu/users/EWD/MCReps/CR1970-013.PDF Now I need to translate them from Dutch. Perhaps there already exists an English translation of either? -----Original Message----- From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Paul Koning via cctech Sent: Sunday, June 20, 2021 4:58 PM To: Norman Jaffe; cctalk at classiccmp.org Cc: General Discussion, On-Topic Posts Only Subject: Re: Early Programming Books Off-Topic Posts" <cctalk at classiccmp.org> Dijkstra and Zonneveld wrote the first ALGOL compiler in 1961, so there might be documents from that time, most likely in the CWI (Mathematical Center) archives. There's a course textbook on programming that is not machine specific, by Dekker, Dijkstra and van Wijngaarden, "Course on programming automatic calculating machines", November 1957. It's quite extensive; the document is 110 pages long. paul

On 2021-06-20 10:06 p.m., ben via cctech wrote: Structured Programming is even manifested in a language as neckbeardy as C; it's not only for quiche eaters any more. Tried the Shunting Yard algorithm? But watch out, it was invented by a quiche eater...

On 2021-Jun-20, at 7:38 PM, ben via cctech wrote: The parser generates a tree of the algebraic expression, the tree is representative of the evaluation order of the expression, earlier evals lower in the tree, the node at the top is the last evaluated. Then walk the tree from the bottom up to generate code. I think code to do this (efficient compiler code generation) has been done like a gazillion-billion times since 1960.

On 2021-06-20 9:01 p.m., Brent Hilpert via cctalk wrote: Computer science people seem to like to brag about how to parse. Walking a tree does not solve the tree was built in the wrong order.Parenthesis first implies input string re-scanning and text movement.This what I can't seem to find a good algorithm for. FORTRAN II and IV did quite well before all this computer science. FORTRAN solved real world problems, ALGOL has yet to have I/O. LISP still can't be compiled.PASCAL is only educational problems, and C mutated into Monster. JAVA is not open source. Very little new stuff is on multi-pass parsing.I have a 70's computer design of modest word length (20 bits) that needs 1970's computer science, and 64KB of memory and removable disks. Ben.

Some may find this paper interesting on the FORTRAN I compiler: https://www.cs.fsu.edu/~lacher/courses/COT4401/notes/cise_v2_i1/fortran.pdf I will add that the diagnostic error messages for FORTRAN I were pretty good for the time. Missing a comma in a computed GOTO? There was an error message that directly addressed this error. Back when I was still in the business of writing compilers, the "Dragon Book" ("Compilers: Principles, Techniques and Tools", Aho, Sethi; Ullman) was the standard reference. I don't know if it still is. The earlier book by Saul Rosen is also pretty good. FORTRAN (as opposed to Fortran) is somewhat odd lexically when compared with other languages. There are no reserved words, there is no concept of whitespace (except in Hollerith constants) and combinations of EQUIVALENCE and COMMON have sent many a compiler designer to tipple. But there are lots of ways to skin the proverbial cat. When I had to produce an extended BASIC compiler for the 8085 using only a floppy-disk MDS 800 system, I adopted a technique I learned from an old IBM COMTRAN compiler guru. Lay out the semantics of your compiler; lexical elements, their characteristics, etc. and then think of them as tokens for a hypothetical machine that takes as input lexical elements and produces some sort of code as output. Initially, my exposure to this technique was in a COBOL dialect translator--you took more or less standard COBOL as input and produced bastardized COBOL as output. You design the instruction set of your hypothetical machine, then either interpret it or use those instructions to produce macro calls. ASM80 on ISIS II had a relatively weak macro facility, so we wrote the macro processor in PL/M. Worked like a charm--in 4 months we had a working compiler. I still have the design paper that I wrote for it. For whatever an old man's story is worth... --Chuck

On 6/20/21 11:48 PM, Van Snyder via cctalk wrote: I remember compiling FORTRAN II on a 1620 using the card compiler (no disk and no operating system). You read the first pass of the compiler in (load up the card reader and hit LOAD on the console) which included the addition and multiplication tables. You then read in the source deck; while that was reading a duplicate with annotation was punched, followed by the symbol table. You then read in the second pass of the compiler along with the just-punched deck, and an object deck was punched. Load the runtime library in with the object deck and you're good to go. It's been over 50 years since I last did this, so I may have gotten something wrong in my wetware. But you get the general idea. This was very different from compiling when the 1620 had a 1311 disk drive attached. There was an operating system of sorts and real JCL. --Chuck

On Mon, 2021-06-21 at 06:02 -0700, jim stephens via cctalk wrote: CHM has a 1620 that was running for a while. IIRC, somebody told me that the reason it stopped running was a damaged fan in the core memory. Nobody explained why that was a real problem. They didn't get a 1622, so they built a PC interface that made the appropriate noises when cards were being "read" and "punched". I don't know whether their PDP-1 still works. Several years ago, they let me play "Space War" for a few minutes. Watching it load from a stack of fan-folded paper tape was half the fun.

On 6/21/21 10:55 AM, Paul Koning via cctalk wrote: memory. Nobody explained why that was a real problem. > Core memory is fairly sensitive to temperature. In the case of the 1620, there is a heating system that brings the core memory box up to its operating temperature, which is why it takes several minutes after you turn on power before the machine will run. > Possibly the fan problem meant the temperature control system was no longer adequate. For some (jprobably hallucinatory) reason, I thought there was a project at CHM to replace the 1620 core stack with semiconductor memory. Guess that never happened. --Chuck

Perhaps you were thinking about the CDC 6500 at the late lamented LCM? That got some replacement stacks, which was an interesting puzzle because the read data connection out of the memory modules is a differential analog signal carrying the sense wire data, so the replacement module had to produce signals of that form. paul

Some vague memory says Purdue. LCM actually got it running, which was an interesting problem. It required recreating the inter-chassis cables (since the original ones were cut as part of dismantling the machine) and restoring the cooling system. That was a bit tricky since it uses non-PC coolant, which actually still exists but can't be manufactured any longer -- you have to use whatever recycled material still exists in the world, and find a graybeard AC tech who knows how to work with the stuff. I think the machine is pretty much original except that a few core stacks were busted so they were replaced by RAM based emulations. And it may be that the original console display wasn't used because of worries of breaking it -- the design of that machine wasn't very good and it apparently has reliability issues. paul

When cleaning out a 3rd party CDC dealer quite a few years back, he remarked that the CDC machines going way back all the way to the 800s were fantastically unpicky about how they were cooled. He just used a garden hose connected to the building potable water, and if the machine under test needed more coolant because it was running warm, it just pumped more supply. Heated waste water went down the drain. This unlike the IBM water machines. -- Will

On Mon, 2021-06-21 at 17:26 -0400, William Donzelli via cctalk wrote: I was once told that the most valuable guy in a Honeywell 6080 Multics shop was the plumber.

As I was the original negotiator for the acquisition of the 6500 for LCM (not yet LCM+L :-), allow me to chime in. Paul Allen alerted me to the existence of a "surplus" CDC 6500 at the Chippewa Falls Museum of Industry and Technology in early 2011. (PGA was always on the lookout for interesting systems, especially those with which he had a personal connection.) I spoke to several people at CFMIT, their BoD discussed the possibility, and came back with a "No, thank you." In early 2012, a management team was hired for the museum as we ramped up to opening, consisting of an Engineering Manager and a Business Manager. The latter gentleman was an old friend of PGA and WHG, having been their boss when they were PDP-10 programmers for the Bonneville Power RODS project; he also negotiated the purchase of the Portland Trailblazers basketball team by PGA, and a number of other deals along the way. He picked up the 6500 acquisition, convinced the BoD at CFMIT to sell PGA the system, and it came to pass. We learned when it was delivered that the machine had been at Purdue for its 22 years of active service, from 1967 to 1989, and was purchased back by CDC to donation to CFMIT, part of whose mission was to have at least one of every machine designed by hometown boy Seymour Cray. The CDC FEs used a Sawzall vel sim. to remove all the interchassis cabling, since "no one will ever want to run this thing again". The Engineering Manager, who in previous life wrote the microcode for the XKL Toad-1 System's XKL-1 CPU, hired a new Principal Engineer, Bruce Sherry, to run the restoration of the 6500. (Bruce designed the XNI-1 Ethernet board for the Toad-1, then went off to Strobe Data to do designs like their Nova and PDP-11 clones. He also designed the 2nd generation Massbus Disk Emulator at LCM.) Bruce found that the company which originally built the cables still had the Cray design files, so they could recreate them; the pins were silver rather than gold or tin, so he had to buy a brick of silver bullion for the company which made the pins (need: c. 10,000, minimum order: 50,000). Bruce brought in a wonder worker from Strobe, the late David Cameron, to do the wiring; between 2012 and 2020, when we closed down, we found *3* miswirings out of that 10,000 or so. Because of Cray's physical design for the memory, Bruce had to spec out a plexiglass box into which he inserted a small memory card, in order to keep the proper airflow characteristics in the memory bays. Bruce's business card at LCM listed his title as "Technomancer". Rich

On Mon, 2021-06-21 at 18:55 -0500, Gavin Scott via cctalk wrote: One of my colleagues, about fifty years ago, wanted to use the 1620 for telemetry processing. So he replaced the arithmetic tables to do decimal with ones that did octal instead. The code was, of course, in assembler, not FORTRAN.

On 6/21/21 1:39 AM, ben via cctalk wrote: What is a register, but a memory location with a special name? I'm assuming that your model does have memory. Again, look to the older systems, such as the much-maligned (by Dijkstra) 1620. You have *no* user-addressable registers--it's all memory-to-memory. In lieu of a stack, you need temporaries in which to stash intermediate results. (The IBM 360 has no stack.) One of the restrictions of non-recursive functions in FORTRAN was because the idea of a machine-implemented stack was relatively uncommon--the Burroughs B5000 (1961) was an outlier in general systems architecture at the time. Thinking about registers, I recall that the initial versions of the STAR-100 mapped the register file (256x64 bits) into the user's low memory, so you could have both vectors and scalars as register-resident. It turned out later to play hob with the scheduling hardware, so the capability was disabled. My recollection from X3J3 is that "Fortran" was officially endorsed with F90. F77 still has FORTRAN officially. For heaven's sake, all you need is a decent assembler--even a cross-assembler. Writing compilers in a HLL is a recent (post 1970) thing. Macros help to encapsulate things, but they're not an absolute necessity. We used PL/M to provide a macro facility that ISIS ASM80 lacked because it was there and convenient. Sigh. It's a shame that absolute (machine language) coding isn't taught anymore. The 1620 (and probably other IBM hardware) even had coding forms for it--pencil-and-paper assembly coding. My recollection is that the absolute forms were on the reverse side of the SPS coding form. If you don't have another system to provide cross compilation/assembly, you bootstrap from machine code. There are two things that can etch instruction codes (not symbolic aliases) into one's memory, more or less permanently. One is absolute machine-language coding; the other is analyzing postmortem memory dumps, day after day. --Chuck

The reason Dijkstra maligned the 1620 is not because of its lack of registers but because of its lack of interrupts and inability to save the full execution state. It's not so much that registers have special names but that they have a distinct place in the instruction set. It may be explicit, as in current machines, or implicit in some older machines that only have one "accumulator", like the ARRA or the CDC 6000 series PPUs or the PDP-8. The registers may actually be implemented as memory (PDP-6 and PDP-10 without the "fast registers" feature), and perhaps the Philips PR8000 which had 8 sets of 8 registers, one per interrupt level. Independently, registers may appear in the memory address space, as in the PDP-10 or the Electrologica X8. The X8 also has a stack, not surprising given that Dijkstra was heavily involved in its design. That machines came out in 1964 I think. More or less, except for the Burroughs mainframes where everything was done in ALGOL or a dialect -- such as ESPOL which was the variant used for writing the kernel. It apparently didn't have an assembler; the little bit of machine code it needed to get the OS started was as I understand it written in hex (or octal?) machine code. Some early assemblers are only barely an assembler; consider the Electrologica X1; its assembler takes only a few hundred words, in ROM. But it has only a rudimentary symbol table and equally rudimentary opcodes; they don't quite rate the usual tag "mnemonic"... paul

On 6/21/21 1:13 PM, Paul Koning wrote: Somewhere I've got the Dijkstra paper. The 1710 version of the 1620 did have interrupts and some later versions even had binary math (options). One of the big issues of the original Model 1(Cadet) and the Model II was that there were digits with special properties, such as numeric blank and record mark that had no instructions to test for their presence--and any attempt to do math (or comparison) with them would result in an error stop. Even their definition was a bit fuzzy. Anything that had the 8 and 4 bits set, but not the 2--84 and 841--was a numeric blank. Same for record and group marks. Rather than multipunch record marks on my object decks, I used a period, which read in as 821, but functioned as a record mark. Basically, you read the special digits in and kept track of where they were. You could save enough of the execution state via the Dump Numeric opcode to see what was going on, but there was no corresponding Read Numeric opcode to read to the end of core. That was a fault of the I/O implementation, not the basic system architecture. But then Dijkstra should talk--how about the wonderful I/O capabilities of the first version of Pascal? No, my point was that they're memory, however they're addressed (i.e. how they're called). In fact, if one looks at the lower level PIC microcontrollers, read/write memory *is* the register set (Harvard architecture; program memory is execute-only). A hardware "stack" is a convenient way of auto-addressing memory. Again, the Burroughs architecture was an outlier from the general machine population. IBM 650 SAP at least had mnemonics. The 1401 opcodes at least hinted at their function. --Chuck

On 6/21/21 4:04 PM, Van Snyder via cctalk wrote: I stand corrected--and I should be ashamed, particularly since I rescued a version of the Wirth Pascal for the CDC 6000. Still have it around here somewhere. Sometimes the wetware throws a parity error. --Chuck

On 6/21/21 4:56 PM, Paul Koning wrote: BB is only useful if you're using a single-level subroutine structure, which , in production code, is almost never the case. It's more useful as a debugging register. The usual way to handle subroutine calls is to use BTM (Branch and transmit immediate), with the immediate value being the return address, which is stored just below the jump target. Mechanism for return depended on the presence of the indirect addressing option. (it, like many other features, was standard on the Model II, but not on the Cadet). If you had it, you simply did an indirect branch (49) referencing the transmitted return address. If you didn't have the option installed, you transmitted the return address into the P-field of a branch (49) instruction and jumped to that. Remind you of anything? --Chuck

On 6/21/21 2:47 PM, Fred Cisin via cctalk wrote: As far as I can recall, Fortran 8x was the draft standard from X3J3. It was never, IIRC, formally certified as final. When the successor of F77 was plotted by X3J3, the target was supposed to be F88. Due to some epic squabbling in committee and unfavorable reaction to the 8x draft standard, the eventual finalized version turned out to be F90. (For a brief time, I served as an alternate to our official member of X3J3). IBM threw a fit because X3J3 wasn't swallowing IBM's Vectran extensions wholesale. DEC had similar gripes (they wanted it to look more like F77) and both threatened to pull out of X3J3. Jeanne Adams found herself trying to hold the whole affair together; it was pretty ugly by all reports. So yes, from the 8x draft, "Fortran" was part of the verbiage. More war stories... --Chuck

In an earlier message, I referred to the Aho et al. "Dragon Book" and then incorrectly cited the 1986 "Red Dragon Book". My reference was the 1977 "Green Dragon Book", also by Aho et al, but carrying the title of "Principles of Compiler Design". Gotta keep my dragons straight. --Chuck

On 2021-06-21 1:05 a.m., Van Snyder via cctalk wrote: But with all this computing science, they have yet to make a clean meta compiler like Meta II, or Tree meta.

On Mon, Jun 21, 2021, at 12:05 AM, Van Snyder via cctalk wrote: [snip] Out of curiosity, which parser generator is this?; i.e., the one you use written by Al Shannon, and since updated? I went digging in my files and online, though only cursorily, and found Hyacc <http://hyacc.sourceforge.net/> by Xin Chen, which I hadn't previously known about, but was wondering if you were referring to it, or something else, maybe the original implementation of LR in Fortran 66, e.g. <https://doi.ieeecomputersociety.org/10.1109/TSE.1981.230837>? -- Daniel Moniz <dnm at pobox.com> [http://pobox.com/~dnm/]

On Mon, 2021-06-21 at 20:49 -0700, Daniel Moniz via cctalk wrote: It's that IEEECS program, Al Shannon's LR program, which I substantially revised, keeping Al's original structure but using more modern Fortran idioms. I also added a front-end, for which the parser was generated by itself, that makes it easier to use. It is also easier to integrate with the remainder of the program. The parser procedure that interprets the table generated by the generator creates an abstract syntax tree, for which I set up an easier way to integrate that with the grammar. I've used it for half a dozen projects during the last forty years. I also provided it to the students in my compiler classes for fourteen years. I'm happy to send it to anybody who wants it.

May I respectfully suggest that you don't know WTF you're talking about? LISP compilers have existed for decades. One of the *early* MIT AI Lab papers by Guy Steele is a comparison of the compiler for MACLISP (the Project MAC dialect of Lisp, nothing to do with Apple computers) with the then current FORTRAN compiler for the PDP-10 (called "F40"), in which the LISP compiler generated better code than the FORTRAN compiler. Things have not degenerated since then. Rich

On Mon, 2021-06-21 at 17:47 -0400, Rich Alderson via cctalk wrote: Dave Card took Cray's eight favorite Fortran benchmarks and re-wrote them in SISAL. They all ran faster.

Any language can be interpreted or compiled. For some languages, like LISP and TECO, interpreting is a rather natural implementation techniques, while for others (C, ALGOL) compilation is the obvious answer. But either is possible. For example, there is a compiled TECO -- it turns the editor commands into PDP-10 machine code and then executes it (Stevens TECO, if I remember right). Of course there are implementations that are borderline between the two. The common Python implementation is an example, with its bytecode that is interpreted. Forth is partly bytecode and partly straight machine code. The Electrologica ALGOL compilers used somewhat similar mixtures of pseudocode and machine code. DEC's PDP-11 Fortran IV used bytecode, while Fortran IV-Plus uses machine code. (Two compilers for the same machine, two different approaches.) paul

I?d like a copy. This is the card version? Sent from my iPhone

On 2021-06-22 3:10 p.m., r.stricklin via cctech wrote: Reading a book on Lisp, 40 years ago is not being up to date on the topic.It mostly covered the eval loop, and how Lisp can be written in Lisp. When Lisp gets better keywords like HEAD and TAIL I might want to use it, if I had need for it. Right now I am looking at META-COMPILERS, not some thing new because I need a bootstrap language for a single accumulator machine with modest memory usage. 1965 to 1985 generated most of the new computing languages,operating systems and ideas. Sadly most of it seems lost source code wise. Ben.

On Tue, 2021-06-22 at 19:45 -0400, Paul Koning via cctalk wrote: I re-created the Bendix G-15 Intercom 2000 from a manual. Not running, of course, on a real G-15. Is there a G-15 emulator? CHM has a G-15, but I understand it's not in operating order. | The same goes for Multics I think the 80286 was a better platform than the original for Multics. And, of course, the Pentium is even better. Is Multics available for Intel systems? A Purdue professor had a 20-drawer card file of 1620 software. The fire marshall insisted he had to get rid of it. I understand he gave it to CHM. Is it still there?

On Tue, Jun 22, 2021 at 11:46:13PM -0700, Van Snyder via cctalk wrote: I wrote a simulator yeaaaarrrrrs ago. I don't think it is online ATM, I will have to check. Rob Kolstad is apparently also working on one. We keep meaning to cross-check each others' work but then life happens. mcl

On 6/23/21 10:17 AM, Lee Courtney via cctalk wrote: There has been a steady stream of misinformation about CHM's 1620 in the past week. I had been staying out of making any comments about it since I was hoping you or Dave were still watching this mailing list.

You gave a link to the "images" on bitsavers, so what did you mean by "not on-line"? paul

On Sun, Jun 20, 2021 at 08:06:26PM -0600, ben via cctalk wrote: [...] TL;DR: you're probably setting so many implicit design constrants that such an algorithm cannot exist. That accumulator machine sounds a bit like the 6502, for which there are plenty of BASIC interpreters which can parse and evaluate that expression. BBC BASIC is my favourite, but Apple's or Microsoft's implementation also do the job. The ones I've looked at were recursive-descent. Other more advanced parsers take too much precious memory. The modern hotness for parsing is parser combinators, but they're really just a fancy way to write recursive-descent parsers which are easier to read and reason about. They certainly can parse something as simple as "A-(B+C)", since recursive-descent can. Code-generation is a whole different can of worms and unlike the well-trodden path of parsing, is still not a solved problem in computer science. All of the compiler textbooks I've checked, including the infamous Dragon book, handwave code generation, introducing the tree-matching algorithm which works well for straight-line code on their made-up educational CPU architectures, but leaves a lot on the table with real-world CPUs. This limitation probably doesn't matter for your CPU. It seems that you might want to produce code directly from parsing. This shortcut can work if you're producing code for a stack machine such as FORTH, but not a register machine (unless you use your registers as a stack). A common wheeze on the 6502 is to implement a virtual stack machine interpreter, and then the compiler targets that. To do code-generation "properly", you need a multi-pass algorithm: parse the source into a tree, optionally do tree-to-tree transformations to do type checks and/or apply optimisations, and then apply the tree-matching algorithm to that to produce machine code. This is all well-described in any good compiler textbook. Note that except for trivial expressions, you'll need a stack and/or other registers to squirrel away intemediate results. Consider "(A*B)-(C*D)": you need to save the result of one of the multiplications before doing the other and then the subtraction. In the case of the tree-matching algorithm, if your CPU (or rather, the model given to the tree-matcher) is too limited to evaluate a given expression, it will definitively fail and give you a subtree that it cannot match. You then have the "joy" of fixing the model, possibly by adding virtual instructions which are really library calls. For a simple CPU, such calls might account for most of the generated code, at which point a virtual machine becomes a good idea. The book "Writing interactive compilers and interpreters" may be more suitable if you're looking for quick hacks to get up and running on a small machine, assuming you can lay your hands on a copy.

As an academic exercise that's pretty trivial. But why would you want to do that? Apparently some people think that this is how you create expression parsers, but that isn't actually a useful or necessary approach. It's entirely trivial to do a sequential scan over the expression tokens and produce corresponding code, in one pass without backtracking or text manipulation. BTW, on code generation: it's true that this is complex, and a still evolving field, if you consider optimization. But a straightforward code generator fed by the parse tree isn't very hard, and requires no great magic. I still have the one I wrote in compiler class back in 1976; it took a week of work and that included learning Pascal and linked lists. paul

TYDAC (TYpical Digital Automatic Computer) is very much an instruction set of its time. Memory is 2000 words of ten decimal digits and sign. Words are either numbers or instructions. I/O is punch cards, special typewriter, or a paper-tape reading device on the typewriter. Four magnetic tapes are assumed as auxiliary memory. ALU includes an Accumulator (11 digits + sign) and Multiply-Quotient (10 digits + sign). Instruction set includes floating-decimal add, multiply, and divide. 46 instructions (out of a possible 100) are defined. -----Original Message----- From: dave.g4ugm at gmail.com [mailto:dave.g4ugm at gmail.com] Sent: Sunday, June 20, 2021 10:51 AM To: 'Paul Birkel'; 'General Discussion: On-Topic Posts' Subject: RE: Early Programming Books Paul, I assumed that was the case, but the inclusion of the Wilkes book confused me. I think there really is a spectrum of books, so say pre-1955 all books assumed the reader had little knowledge of programming. For example the MK1 guide I pointed you to is V2. Its rumoured that Turing wrote V1 and no one could understand it but I think it more likely the machine changed. I also looked at the IBM 701 manuals and they too have some generic info at the front. However I also wonder what the earliest books were like. Dave G4UGM (You might want to e-mail Simon Lavington https://www.essex.ac.uk/people/lavin12900/simon-lavington he has done a lot of research on early computing, and might know more.) the effect

Basically, pre-1960, there couldn't be a 'general book on programming', since every system was a unique environment - the only languages that could even be remotely considered to be common were ALGOL 60 and FORTRAN II... and they were 'extended' by every manufacturer to provide, at least, some form of I/O beyond line printers and punch card readers / punches or to support different character sets. Algorithms could be written in ALGOL or FORTRAN, but usually had to be 'translated' to the particular flavour of the language provided by the manufacturer... [Even well past 1960, FORTRAN implementations drifted from standards... for example, FORTRAN on the Data General Nova supported recursive functions, something that was would cause massive problems on other systems...] From: "General Discussion, On-Topic Posts Only" <cctech at classiccmp.org> To: "General Discussion, On-Topic Posts Only" <cctech at classiccmp.org> Sent: Sunday, June 20, 2021 9:34:18 AM Subject: Re: Early Programming Books Aside from the very general Algol report and the Iverson book on APL, I have to admit that most of my programming knowledge came out of manufacturer's manuals, specific to a maker's systems. The APL book was, at the time, pretty much useless for writing any sort of serious code until you got hold of the manual for a particular system that you were going to use. Even the early McCracken books on FORTRAN had a section in the rear that attempted to gloss over different manufacturer's features and "extensions" (e.g. What does "B" punched in column 1 of a FORTRAN statement card mean--and for what system?) Lest anyone forget, that in the pre-1960 world, a lot more of production code was written in the assembly code/autocoder of a particular system. Even the DEC "Introduction to Programming" dealt specifically with the PDP-8 and was useless for the PDP-10. ACM CALGO back then accepted algorithm submissions in FORTRAN or Algol, but that's hardly an instructional text. I guess the question boils down to 'In the world before 1960, how *useful* was a general book on programming?" --Chuck

True, unless you were to set out to write a general course on programming that doesn't dig down to the level of any particular assembly language or machine architecture. From a quick look, I think the 1957 course by Dekker, Dijkstra, and van Wijngaarden I mentioned in my previous note does just that. And that explains the title, "Programming automatic calculating machines" (as opposed to the more common "Programming the xyzzy-42 machine"). paul

If you bring up the Android (maybe apple, too) translate and engage the camera icon an aim it at the screen, you can peruse it as well. It would be cool to find some utility to break up the PDF if the OCR is accurate enough and re-assemble it in some fashion similar to the auto camera translation, so that the formatting and illustrations could be retained in the translted document. thanks Jim On 6/21/2021 1:43 AM, Paul Birkel via cctalk wrote:

Well, utility depends on the objective. One that immediately springs to mind in an era when "computing" had a dearth of practitioners would be to inform various audiences "what is involved". The Dekker (1957) reference seems to be targeted at an audience interested in expressing mathematical statements in terms of the von Neumann model, generally building up to the idea of algorithms and their general reduction to a sequence of computational steps in that model of computation. This would be a pre-ALGOL 58 world and one can see the paper as a motivation for an ALGOL- (or FORTRAN-) like language. (Caveat: I've just skimmed a poor translation; more careful study required!) The McCracken (1957) book seems to be targeted at an audience of future practitioners, giving a feel for how a hypothetical instruction set would be employed "in daily practice" to solve problems. Perhaps answering the question of "would I like to become [or could I handle becoming] a 'programmer' " in an era when that was about to become a new specialty and career path. A numerical analyst (e.g.) might find the Dekker text more accessible; an engineer might find the McCracken book more to their liking. IMO, "in the world before 1960" both are "useful" without becoming a machine-specific instruction manual or cook-book. -----Original Message----- From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Chuck Guzis via cctech Sent: Sunday, June 20, 2021 12:34 PM To: Paul Birkel via cctech Subject: Re: Early Programming Books Aside from the very general Algol report and the Iverson book on APL, I have to admit that most of my programming knowledge came out of manufacturer's manuals, specific to a maker's systems. The APL book was, at the time, pretty much useless for writing any sort of serious code until you got hold of the manual for a particular system that you were going to use. Even the early McCracken books on FORTRAN had a section in the rear that attempted to gloss over different manufacturer's features and "extensions" (e.g. What does "B" punched in column 1 of a FORTRAN statement card mean--and for what system?) Lest anyone forget, that in the pre-1960 world, a lot more of production code was written in the assembly code/autocoder of a particular system. Even the DEC "Introduction to Programming" dealt specifically with the PDP-8 and was useless for the PDP-10. ACM CALGO back then accepted algorithm submissions in FORTRAN or Algol, but that's hardly an instructional text. I guess the question boils down to 'In the world before 1960, how *useful* was a general book on programming?" --Chuck

Since the question was asked "where do I find those CWI (MC) reports?"... CWI has a document search, but they don't make it easy to find. Here it is: https://ir.cwi.nl -- I haven't explored all the things it can look for, but it definitely can find documents by words of the title, or by author name. paul

Sounds very promising, thank you for the tip. -----Original Message----- From: dave.g4ugm at gmail.com [mailto:dave.g4ugm at gmail.com] Sent: Sunday, June 20, 2021 4:01 PM To: 'Paul Birkel'; 'General Discussion: On-Topic Posts' Subject: RE: Early Programming Books Paul, What about Approximations for Digital Computers Cecil Hastings Jr., Jeanne T. Wayward, and James P. Wong Jr. Whilst its about a specific problem its not machine specific. It was originally published as papers in 1955 and as book later, but my copy retains its 1955 copyright. Dave

On Sun, 20 Jun 2021, Bill Degnan via cctech wrote: 1949 Edmund Berkeley "Giant Brains, Or Machines That Think" It wasn't until Jim Warren that that phrase got corrected to "machine WHO think", as isn't thinking the measure of which pronoun to use? It seems to me that there were a few basic genres: books that were references for a specific machine or language (often the "standards" were loose enough that it would be a specific implementation of a language on a specific machine) and books about theory and principles of computing, and books that purported to be about theory and principles, but that were closely tied to a specific machine or language -- Grumpy Ol' Fred cisin at xenosoft.com