we need websites to reference this stuff to like museums and such for the artical to survive On Sat, Feb 15, 2025 at 12:35 PM Frank Leonhardt via cctalk < cctalk(a)classiccmp.org&gt; wrote:

6 bit characters were used by CDC 24 bit machines. 4 chars per 24 bit word. Sent from my iPhone

On Sat, 2025-02-15 at 17:22 -0500, Paul Koning via cctalk wrote: Teletype machines used 5-bit Baudot code, including shifts between "Figs" and "Letters." The ILLIAC I console was a TTY. ILLIAC used hexadecimal input. But instead of 0-9 and A-F, it used letters that were 10-15 in binary in Baudot "Figs" mode: KSNJFL. There were two mnemonics to remember that: "King Size Numbers Just For Laughs" and "Kind Souls Never Jostle Fat Ladies."

On Sat, 2025-02-15 at 23:19 +0000, Chuck Guzis via cctalk wrote: Well beyond then. The Clearpath 2200 went out the door in the early 2000's, when Angus McRonald retired. He was the last one left who was using old Voyager codes that were trapped in the Univac because nobody wanted to pay to revise them for newer computers. Univac also had a quarter-word mode for ASCII, even as far back as 1108. The newer FORTRAN V compiler was called the ASCII compiler because CHARACTER type was, by default, quarter-word instead of sixth-word.

On Sat, Feb 15, 2025, 7:59 PM Chuck Guzis via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: Well... the pdp-10 could use any number of bits per character... the underlying instructions made packing and unpacking easy. Warner

Yes, the B1700/1800/1900 systems had bit-addressable memory, but I think the data registers were limited to 24 bits.

On Sat, 15 Feb 2025 at 15:29, Van Snyder via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: I presume you're referring to Larry Sanger, who was the co-founder of Wikipedia. In any case, the process appears to be working as designed - someone thought that the article should be deleted, but once the nomination was made the article got more eyes on it, and it's looking like it will end up being kept. -Henry

On 15/02/2025 20:33, Van Snyder via cctalk wrote: Peter Onion has a rather fine 803 emulator, and the Algol tapes. And a working 803. I've only got bits of one in my shed. https://www.peteronion.org.uk/Elliott/

I want a piece of the action. I have an 8-channel paper tape reader and I'm happy to archive any tape you care to bring by. Dave Wise in Hillsboro Oregon ________________________________ From: Van Snyder via cctalk &lt;cctalk(a)classiccmp.org&gt; Sent: Saturday, February 15, 2025 3:10 PM To: cctalk(a)classiccmp.org &lt;cctalk(a)classiccmp.org&gt; Cc: Van Snyder &lt;van.snyder(a)sbcglobal.net&gt; Subject: [cctalk] Re: Elliott Algol On Sat, 2025-02-15 at 21:19 +0000, Frank Leonhardt via cctalk wrote: Paul Pierce just told me that Al Kossow has a paper tape reader at CMH. CHM can also read 7-track mag tapes on their 1401s.

Sid If it serves any purpose I could read the 5 track tape, I have a 5/6/8 hole sprocket drive reader - in Dorset, UK - and an 8 hole friction drive reader (perhaps kinder on tapes, but n/a in this instance). Martin -----Original Message----- From: Sid Jones via cctalk [mailto:cctalk@classiccmp.org] Sent: 15 February 2025 14:52 To: General Discussion: On-Topic and Off-Topic Posts &lt;cctalk(a)classiccmp.org&gt; Cc: Sid Jones &lt;jonesthechip(a)logicmagic.co.uk&gt; Subject: [cctalk] Re: Elliott Algol IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five-hole tape in a drawer somewhere in my untidy office... As used in UCNW Bangor, 1971-1974. Regards Sid -----Original Message----- From: Frank Leonhardt via cctalk Sent: Saturday, February 15, 2025 2:43 PM To: cctalk(a)classiccmp.org Cc: Frank Leonhardt Subject: [cctalk] Elliott Algol As those of us with a few years will know, Tony Hoare (and Jill's) implementation of Algol 60 on the Elliott 803 was a highly significant event in the history of computer languages. It was the first practical commercial Algol compiler, launched block structures languages, and played a part in Elliott selling nearly 300 803B computers at a time when 300 computers was a big number. Obviously the US preferred Fortran and COBOL for commercial use, and there were other Algol compilers in some shape or other knocking about in universities. But I'd say this implementation put block structured programming into the mainstream. (And it was the first high level language I used, but that's beside the point). Now some kid on Wikipedia thinks it's not notable and is trying to delete it because he can't find much on it doing a Google search. Wikipedia may be sinking under activists and egos, but I think we need to put this misapprehension straight. Unfortunately we may be arguing with an idiot. https://en.wikipedia.org/wiki/Elliott_ALGOL If course, if anyone thinks it wasn't significant, that's an opinion too, but I'd like to hear why. Thanks, Frank.

On 15/02/2025 16:35, Jon Elson via cctalk wrote: Running anything like Algol on a machine with drum memory seems a bit optimistic!

On 15/02/2025 20:53, ben via cctalk wrote: 6 bit characters were fine if you didn't care about proper capitalization and your only language was English. Julf

On Sat, 2025-02-15 at 13:38 -0700, ben via cctalk wrote: An Icelandic chain could be gotten for an IBM 1403. I reverse engineered a program that converted numbers to Icelandic words, for check printing. So I added an Icelandic encoding to my Autocoder cross assembler. The Computer History Museum has a 1401 that was originally German — so it needs 50hz power. AFAIK, they didn't get a German chain that included umlauts. The usual 1403 setuip on a 1401 was to use a 47- character chain, but it was possible to get 63-character chains that included box-drawing characters. Those kinds of chains were used to print the Automated Logic Diagrams, or ALDs. Maybe IBM offered chains for Germany and France with more than 47 characters, to have all the accents. But they would print slower. IBM also offered a 15-character chain that had only digits plus five other characters — minus sign, dollar sign, comma, decimal, asterisk — for printing numeric-only reports. It was much faster than the 47-character chain. Of course, all the chains had the same number of links (I don't remember how many), but more repetitions with smaller character sets.

On 16/02/2025 20:51, paul.kimpel--- via cctalk wrote: I can't find the context for this, but it was early EBCDIC devices which lacked square brackets, and there was a big debate in the academic world where to put them in the code page... https://x3270.miraheze.org/wiki/Why_are_the_square_bracket_characters_displ… ... and here is a 3270 keyboard.... https://sharktastica.co.uk/directory?id=94OROEAU Dave

I've never seen an ASCII terminal that was missing square brackets. But in theory those codes were "national use" codes, and for non-English language use they would be redefined as A with umlaut or stuff like that. This is why RSTS/E at some point introduced parentheses as alternates for the square brackets it had always used as directory name delimiters. For us in the US that was never interesting. The problem was fixed fairly well with the introduction of the DEC Multinational Character Set, which later morphed into ISO Latin-1 (with the curious omission of the oe ligature) and later the various other Latin-<n> sets. And the problem was solved completely with Unicode. paul

No, since current Unicode is an upware compatible extension of the original. Typical modern terminal emulator programs handle Unicode; my Mac certainly does and there are even examples for Windows (like Putty). No, but you could make one up easily enough. Start with Latin-1, and replace the few characters that are different. A VT220 reference will tell you the ones to replace. Any font editor should do this easily. paul

On 2/17/25 12:11, ben via cctalk wrote: I believe that this was a feature for a limited set of characters in Videotex. Namely, a diacritic mark followed by a character produced the character with the diacritic attached. Of course, this would be trivial on a bitmapped graphics terminal. --Chc

Oh? Certainly by today's standards a drum memory machine is quite slow. But in their day they were used for serious work. To pick one example, the ARMAC machine developed at CWI in Amsterdam (then called MC, Mathematical Center) had a drum main memory coupled with a one entry cache to hold the most recently accessed drum track. That was the main machine at MC for a couple of years, until the Electrologica X-1 (with instruction times in the 20-30 microsecond range) replaced it. Before the ARMAC came the ARRA 2, which had drum memory without the cache. It worked well enough that Dutch aircraft manufacturer Fokker commissioned a copy, named FERTA. It was used to do the design of at least one of their major commercially successful airliners. Yes, it did, though commercial core memory machines appeared a number of years before that. For example, the EL-X1, which was a core memory fully transistorized computer, came out in 1958. It appears to be the first commercial computer with interrupts as a standard feature, which prompted Dijkstra to write his Ph.D. thesis on the problem of how to create reliable code with interrupts. He wrote the ROM BIOS for that machine. 1958. The X1 is where Dijkstra and Zonneveld created the first ALGOL compiler, in 1960. Unlike a number of early compilers that one was a full implementation except for the one or two small "features" that by then had already been recognized as mistakes. That compiler ran in 4 kW 27 bit words, requiring several passes. A later version that took advantage of a memory upgrade -- to 16 kW -- was a full compile-load-execute system. So "ample memory" is a bit of a debatable question. It depends a lot on who is doing the work. For Dijkstra and Zonneveld, 4 kW was useable and I suspect they would have considered 8 kW "ample". For the creators of the DEC PDP-11 operating systems DOS-11 and RT-11, 8 kW (16 bits, so 16 kB) was ample; IBM engineers required 128 kW for something not as good (OS/360 PCP v19.6). Today's programmers often think in terms of megabytes if not gigabytes as the minimum tolerable, while many of those who hang out on this list enjoy the challenge of squeezing stuff into a small microcontroller, or the boot block of some disk device. For an extreme example, consider the "programmable I/O" state machines in the Raspberry Pico microcontroller. It has two or three engines, each with 4 state machines that share the program memory -- 32 words of 16 bits. With care, you can do a lot with those. I'm thinking of doing a "bit banging" implementation of Ethernet with that device... Keep in mind that cycle time in those days wasn't necessarily constrained by the logic but by the memory. Early core memories had cycle times of many microseconds (the X1 for example had 8 microsecond core, I think). CDC delivered 1 microsecond core memory cycle time in 1964, but it took some rather mind bending electronic circuitry to make that possible. Algol-60 never changed after the Revised Report of 1962, which was really the "V1.0" release. Algol-68 is an entirely different language, just as Pascal is an entirely different language. As for ASCII, that is exactly what it was originally. There have been lots of other character set definitions since then, though the mind bending variety of language-specific sets was finally fixed once and for all with Unicode. Yes, Unicode keeps growing to add more obscure character sets, but it's still the same standard. Which one? Electrologica had several, CDC had a bunch, as did every other vendor. Some things make life simpler, such as stack operations and subroutine call instructions that support recursion. But none of those are required; the EL-X1 had none of these. Its successor the X8 did because it was designed with the knowledge of Algol in mind (the X1 predates Algol). And as a result, the transformation from Algol source code to machine code is in a number of places more straightforward. But you can compile anything you want to any machine you want; if it's good enough to be considered a general purpose computer it can be handled. Another example is the CDC 6000 series mainframes, for which a bunch of compilers were created including Algol 60 as well as Algol 68. That machine has no index registers, no stack, no recursion; it only has 8 primary registers and its subroutine call overwrites memory. Not very friendly, but it just means a bit more work for the compiler writer. paul

The thing you really need for good ALGOL code generation is a target architecture designed to support it. All of the early implementations I know about that attempted full support of ALGOL-60 targeted a virtual machine at run time. The outstanding counter-example, of course, are the Burroughs B5000/6000/7000 stack machines, later known as Unisys A Series, and currently still being marketed and supported by Unisys as their ClearPath MCP line. The B5000 was designed in the early '60s, with first customer delivery on 1 April 1963. The ALGOL code generation was good enough (from a one-pass compiler, no less) that it became the assembly language. There never was an assembler that ran on those systems, although there was a basic assembler (termed OSIL) for it that ran on the older Burroughs 220 and was used to bootstrap early versions of the ALGOL compiler and OS. Once ALGOL could compile itself, OSIL was abandoned. The Burroughs ALGOL dialect is heavily extended, but at its core it was still a quite complete implementation of Revised ALGOL-60.

The question concerned good ALGOL code generation, not the feasibility of ALGOL code generation.

On 2025-02-16 4:52 p.m., Paul Koning via cctalk wrote: With all the cache's used on modern machines, accessing memory is a Forbidden operation. I have trouble understanding the fine points of accessing a local variable in Algol with a display. Books tend to spend more time on the evils of a dangling else, and gloss over the run time action of a display. Have a good example or reference book I can find free on line. Also is there a ENGLISH description of the EL-X8? Ben.

On Mon, Feb 17, 2025 at 09:11:17AM -0500, Paul Koning via cctalk wrote: [...] That's the very old-school approach for weird CISC architectures which were mainly programmed in assembly language or with naivee compilers. It's most definitely not a *good* way to do it, performance-wise. So of course x86 supports it. When I first encountered x86's ENTER and LEAVE instructions, I thought "that's on crack". Being x86, it almost never removes features and often even doubles-down, and so this still works and is even supported in 64-bit long mode. Although the exact terminology and implementations can vary by language, these days that inner function would normally be called a "closure" which "captures" variables from the outer function. In your example, j but not i is captured by f2, and so f2 doesn't need access to all of f1's stack frame, just its j. I wrote a contrived test program in Rust and inspected the machine code, and what it did was to pass the address of j as a hidden parameter to f2. This meant that f2 already had that address in a register and didn't need to do an extra memory access to find it. The nested call used the normal CALL/RET instructions which do not do the slow and complex microcoded operations on stack frames that ENTER does. How slow are we talking? ENTER/LEAVE is also at least order of magnitude slower than CALL/RET on modern x86. On my Haswell, CALL is ~2 cycles, whereas ENTER is ~80. It's a bit better on e.g. Zen 4 at ~20 cycles, but still not great. However, I'd contrived the code so that it didn't get optimised away. Since j is not modified by the code (unless your "..." elision does it), the compiler could have passed the *value* of j as a parameter as the changed value doesn't need to be propagated back up the call stack, saving another memory access. Or most likely it'd have noticed that f2 was a good candidate for inlining and now f1 and f2 share the same stack frame and can trivially access each other's variables. ENTER/LEAVE might have perhaps been more useful on the 286 and mitigated some of its many performance problems in protected mode, but I'd rather just use pretty much anything else, possibly even pen and paper, in preference to segmented x86.

On Sun, 2025-02-16 at 18:52 -0500, Paul Koning via cctalk wrote: When Tom Pennello was a grad student studying under Frank de Remer at ACSC, he collected a big pile of codes in languages that had nested lexical and dynamic scopes (such as recursive internal functions). He found that chasing up-links was much faster than displays. In some cases, creating and destroying the display took six times longer than executing the function. I mentioned this to Malcolm Cohen and me mumbled something about a "trampoline." I have no idea what that is.

On Mon, 2025-02-17 at 09:13 -0500, Paul Koning wrote: The display isn't static for nested recursive functions (as in Pascal) and you want to have "deep binding," not "shallow binding." The "up link" for a recursive function passed to another recursive procedure as an actual argument should be the "up link" as of the moment of invocation of the procedure getting the nested one, not as of the moment the nested one finally gets invoked by way of the formal argument during a recursion by the procedure that got it as an actual argument. Pennello had some Pascal "compiler breaker" codes that he would use to test compilers. After he graduated, he worked for Frank de Remer at MetaWare. They marketed Pascal compilers for many machines. Tom called it "overextended Pascal." I don't know whether the Algol 60 Report or the Algol 68 standard or the Pascal Report explicitly specified deep binding, but it's more useful than shallow binding. The Fortran standards explicitly require deep binding, but not using those words.

On 2/16/25 15:52, Paul Koning via cctalk wrote: CDC 6000-series turned in better performance benchmarks on COBOL that did the high-end IBM S/370 iron. There are huge advantages to fast instruction set execution operating on large word sizes. Just ask Don Nelson (he who played the bass drum in the Los Trancos Woods marching band). Two things that worked to CDC's advantage in addition to the simple instruction set was that the 6000 was a three-address architecture with no condition code register (conditional branches were made on the content of a register). --Chuck

Also multiple functional units, seriously interleaved memory, and a bucket full of other tricks. The way loads and stores are requested by the programmer naturally makes them background operations, and the "stunt box" handles that background process. Not directly tied to application performance but very nice for the OS is an amazingly efficient way to switch between processes, the "exchange jump". VAX almost got this, but the 6000 does it better, taking advantage of the read/restore cycle to do a read/update and run the context switch at memory speed. Ignoring initiation time it takes less than 3 microseconds (in 1964!!). paul

Yes, though it's possible to enable such things with condition code machines if the setting of the condition code is selective. The Electrologica machines have this: there is an instruction modifier bit that tells the machine to update the condition flag based on result zero, result positive, or a third option that I never remember -- or to leave it untouched. Subroutine calls save the flag and the return can restore it if you want, or not if you don't. Finally, almost all instructions can be conditional on the flag if you want, either "execute if flag set" or "execute if flag clear" or unconditional. The EL-X1 Wikipedia article shows an example. I don't know that one, but there is the famous OTOD -- convert a 60-bit value to a 20 digit octal string. I did a variation on that (not quite as slick) to convert a 60-bit value to a 15 digit hex string. Interesting. I worked on a 6500 so a lot of optimizations were not relevant, but I spent a while studying code in NOS to learn how to do it. One thing that did matter was shuffling instructions around to avoid NOP padding. I once had a piece of code that was subject to hard real time constraints -- which I did not know -- so when I broke it I had to revise it to get rid of all the NOPs. Then it was fast enough again. Really? I never heard of anyone who ran with CEJ disabled -- why would you want to do that? Oh yes... Indeed, though I sure would like to know how to make the timing work. If you do what's documented in the schematics (in a VHDL model) it doesn't work. paul

On 2/17/25 12:30, Chuck Guzis via cctalk wrote: Argh... I know I've seen this trick, but it's been too many years. How about a hint? Interestingly, Google turns up a reference to an article in Software: Practice and Experience on the subject but no free access. My employer at the time subscribed to that journal and it was one of the more useful ones.

On 2/19/25 13:08, Gary Grebus via cctalk wrote: It uses the RJ instruction to record register content, bit-by-bit. Think about it--RJ is about the only instruction that can modify memory without fiddling with the A6 and A7 registers. --Chuck

On Mon, 2025-02-17 at 09:17 -0500, Paul Koning via cctalk wrote: I remember the "stunt box" also being called the "traffic cop." The Denelcor HEP had asynchronous memory access. It had several (sixteen, IIRC) functional units and hardware thread switching. When a memory access occurred, the register file was saved (or maybe there were more register files than hardware processors — my memory is foggy here) and another thread was put into a functional unit. When the memory access was completed, the register file was put into the functional unit queue. Arvind at MIT was a dataflow investigator. Greg Papadopolous (later Chief Technical Officer at Sun Microsystems) developed the Monsoon tagged-token dataflow computer as his PhD project. Rishiyur Nikhil described a RISC architecture that was augmented with asynchronous memory access and automatic thread switching.  Burton Smith and James Rottsalk founded Tera Computing to develop a computer called the Multi Tread Architecture or MTA, IIRC based on Nikhil's ideas. They bought the ashes of Cray and promptly changed their name to Cray. But the MTA had a fatal flaw that neither Tera nor the Cray engineers they absorbed were able to resolve: It had a 100 MHz bottleneck. Even so, it was faster than the "supercomputer" that IBM was offering at the time — but only on a sort benchmark.

On Sat, 2025-02-15 at 12:53 -0700, ben via cctalk wrote: The IBM 704, first delivered in 1956, had 8,192 words of 36-bit core  memory. The IBM 701, developed in in 1951 and delivered in 1953, had  memory consisting of 72 Williams Tube CRTs; some were later converted to core. Like SWAC, there was a tendency of zero bits to leak into adjacent words, so every ten milliseconds or so, programs would swap CRT memory to drum and back. The first IBM 1401 was announced in October 1959 and delivered shortly thereafter, with 4k characters of of 12.5 microsecond core memory. One could eventually get 1401, 1440, and 1460 with 16k memory. 1410, and the faster but functionally identical 7010, could be gotten with 100k memory.

On 15/02/2025 20:09, Jon Elson via cctalk wrote: Elliott Algol was pretty quick (and therefore practical) - feed the compiler tape in (8-hole) and then feed in your program on five hole. It's been a long time but it was compiling at several cps and your program ran in a few minutes. Then feed in another. You could compile to tape for larger programs. The 803 had 4K or 8K by 39-bit core, but I have a feeling it needed the full 8K for Algol. The later 503 (1963?) was a lot faster. I had access to one but never got it working. This must have been three or four years after the Bendix!

u had a bendix running or still running? On Sat, Feb 15, 2025 at 2:09 PM Jon Elson via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote:

Usagi Electric on youtube has restored a G15 if I understand correctly. Including a project to re-coat a crashed drum. ________________________________ From: Jon Elson via cctalk &lt;cctalk(a)classiccmp.org&gt; Sent: Saturday, February 15, 2025 5:05 PM To: Adrian Stoness via cctalk &lt;cctalk(a)classiccmp.org&gt; Cc: Jon Elson &lt;elson(a)pico-systems.com&gt; Subject: [cctalk] Re: Elliott Algol On 2/15/25 15:31, Adrian Stoness via cctalk wrote: Nope. In about 1973 or so, one of the guys in our group spotted a NASA listing of a Bendix G15 free for the cost of shipping (which was not insignificant!) He convinced the Engineering School to pay for it. It had been on a NASA spaceflight tracking ship, and was "supposed" to be operational. We got it delivered, hooked up to massive 240 V power feed, and started trying to learn how to run the thing. Nobody ever really got the hang of it, they were all used to lights and switches consoles. The G15 did almost everything through the typewriter. You could dump a block of drum tracks with a written command. I spent a few days poking at it and I really couldn't get it to do a whole lot. Very likely dirty contacts in the keyboard were garbling the commands I thought I was entering. I THINK the typewriter dutifully printed whatever you typed via mechanical coupling, even if the computer did not register those keystrokes. There was a huge box of telephone-style relays that sat under the typewriter that I think encoded the key contacts to a binary code. So, PLENTY of contacts that could foul up the encoding. Anyway, I got pretty frustrated, and eventually pulled the cover off the drum and discovered there were two tracks totally scored down to the brass, and a couple more that were a bit scored. The cover on the drum was just deep drawn aluminum with caterpillar grommets around the cable entries. NOWHERE NEAR a hermetic seal! After that discovery, there was not much interest in the beast. Jon

We have two G15’s at CHM, one currently on exhibit and one in the warehouse. Lovely machine. Very huggable. Marc

Donald Knuth wrote an ALGOL compiler for the ElectroData/Burroughs Datatron 205, a drum-memory machine with 4080 words of memory, in 1960. It was based on ALGOL 58, though.

On Sat, 2025-02-15 at 10:35 -0600, Jon Elson via cctalk wrote: It was a subset called "ALGO." It punched miles of paper tape as an intermediate, even for dinky programs (which were, of course, all that could fit anyway). I used a G15 at a summer class in 1963. We used Intercom 1000. I found a manual for Intercom 2000 and wrote an emulator (not a G15 emulator). Let me know if you want it.

It would be great to learn more about that. It's a rather early machine for ALGOL to show up there, though a precedessor of ALGOL (IAL, "International Algebraic Language") appeared in 1958. That was a bit of a mess and the 1960 Report on ALGOL-60 is quite different. Apparently IAL served as the inspiration for JOVIAL, though in my view the designer of JOVIAL clearly demonstrated that he didn't at all understand the core principles of IAL or ALGOL. A lot of early "ALGOL" compilers did major subsetting because it was considered to hard to do the real language. Those subsets may not actually bear any real resemblance to the actual language. For example, a "subset" that omits recursion is not ALGOL but rather a mongrel joke. One of the major contributions of Dijkstra and Zonneveld isn't just that they built the first compiler for the full ALGOL-60, but that they invented all the major compiler construction mechanisms to make that possible. This is analyzed very well and in impressive detail in the Ph.D. Thesis of Gauthier van den Hove. paul

On 2025-02-16 7:32 a.m., Paul Koning via cctalk wrote: I disagree here, recursion is just one method of problem solving. While I think, function nesting is too complex for most use, the use of stack based local variables in blocks was a important step foreword. Playing around with META-II, compiler compiler I discovered it had no way of handling local variables and symbol tables, as it just moved text around.I could parse fine, but not generate code. Did many people believe back then that one could just shuffle text around to solve new programing languages like Algol, where it might work with something like Fortran, with some sort of macro processing language.

Wikipedia policy excludes what they call "original research". Unless your article was published by some major mainstream outlet, you're toast, even if you are literally the last person on Earth who knows the stuff. ________________________________ From: Paul Koning via cctalk &lt;cctalk(a)classiccmp.org&gt; Sent: Sunday, February 16, 2025 10:08 AM To: cctalk(a)classiccmp.org &lt;cctalk(a)classiccmp.org&gt; Cc: Paul Koning &lt;paulkoning(a)comcast.net&gt; Subject: [cctalk] Re: Elliott Algol That's true but not my point. Yes, you can solve it in Fortran II, without recursion, even if the most natural solution is a recursive one. My point is that support for recursion, and nested blocks, and nested scopes, is the essence of ALGOL and what makes it different from FORTRAN II. So a language that omits one of those elements cannot legitimately call itself a variant or subset of ALGOL, any more than a language without pointers can legitimately call itself a subset of C. Function nesting is an important mechanism in some scenarios, but admittedly much work doesn't need it. It's useful enough that GNU C added it as a compiler extension. Parsing -- splitting text into tokens (lexing) and building parse trees -- is part of the compiler's job but usually the easiest part. Not quite as easy if you want good error messages or error recovery. Code generation is an independent problem, and something that parses programs without generating code isn't a compiler, it's at best just a front end. You might want to look at the GCC internals manual. GCC has an explicit layering, with front end processing steps that construct parse trees which are then transformed in stages, until they reach the "target" code which converts the final internal representation into actual machine code. I doubt it. Compiler compilers (or more accurately, parser generators, like the famous YACC) are a later development. By the time that compiler writing textbooks like the "dragon book" (Hopcroft and Ullman, if I remember right) came out, the relevant theory was well understood. But writing early compilers required inventing elements of that theory along the way. Again, the Dijkstra/Zonneveld Algol compiler is an example, and Gauthier van den Hove spells it out in detail. Dijkstra invented a stack based parser, somewhat like a recursive descent parser, which he called the "shunting yard" algorithm after railroad yards, as a mechanism for parsing Algol. He also invented "displays" which are a way to find the stack frame for the current static nesting of recursive function calls. paul

On the other hand, site policy has a long list of what publishers they'll accept and not accept. Amateur and hobbyist postings to blogs, for example, are not accepted, even if it's verifiable or reproducible or otherwise high quality. I admit to a bit of pique here: I don't even bother updating Wikipedia articles anymore because they'll always get reverted by someone with less of a life than me for any number of specious reasons. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com -- Understanding is a three-edged sword. -- Babylon 5, "Deathwalker" ----------

do you start discussions around u redits on the articles complaining about the removal ofthe info On Sun, Feb 16, 2025 at 12:45 PM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org&gt; wrote:

On Sun, Feb 16, 2025 at 1:53 PM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org&gt; wrote: This is an almost perfect description of my experience of Wikipedia.

In these cases, did someone roll back your changes? Was discussion added to the Talk tab? I do enough Wikipedia edits that I get to vote on board membership. Or used to. I have only done a few edits in recent years. The trickiest edit has been the page for a woman who was a child actor in the 70s but is now a doctor. The info in her page was wrong (and unattributed) and she hasn't done any interviews in 20 years or described in any media coverage what she has done since leaving the entertainment business. I got her e-mail address and exchanged messages with her. It was completely surreal. We discussed what she wants the general public to know about her now. I asked if she was sure on a few points, e.g., when I thought it might be too specific on where she is now. What is on the page about her is what she felt comfortable with (as of 2019-2020). To get around the "no original research" thing, I added a Talk tab section explaining all of the above and offered to make the email exchanges available (with her contact info redacted). That was 5-6 years ago and no one has edited the page since. If someone has something they think should be in a Wikipedia page and had it removed, I can help get it added to a Talk tab entry at a minimum. On 2/17/25 8:26 AM, David Wise via cctalk wrote:

I tried to delete an “s” from the word states in an incorrect quotation. Changed it twice. It was changed back. Changed the whole meaning of the quote. Sent from my iPhone Robert Harrison bobh(a)tds.net

On 2/20/25 8:06 PM, Nigel Johnson Ham via cctalk wrote: Did Measurements Canada indicate that it was a legal definition or a definition established by the agency. If the definition isn't in enacted legislation, Measurements Canada's statements may not be legal definitions. It depends on the authority granted to them under the legislation that created the agency. But asking for money suggests something sketchy is happening. I do a lot of general corrections in Wikipedia, usually when I am watching old movies, looking up stuff about it and noticing something wrong. But I reading up on the stuff that I used to work on at Burroughs/Unisys that is clearly wrong (for example, I was working on the product after the article says that work stopped on it) and haven't yet come up with an attributable way to correct the page other than to add something to the Talk tab.

Hmmm. This may be a minefield that I don’t want to step in. I used to work with AES folks and there are some strong opinions presented as facts in that area ;)

On 2/21/25 11:31, jim stephens via cctalk wrote: I gave up editing on WikiP years ago, although I still occasionally toss them some geetus because I think that the purpose is a noble one, no matter the flaws in execution. I do however, actively support archive.org, where there's no question of "he said" or faulty memory. The big problem for me is searching the thing, but I imagine that will eventually improve with technological advances. Right now, archive.org is our best general defense against having our history disappear down the memory hole. CHM does a good job as well, as things pertain to computing, interviewing seminal personalities before they shift off the mortal coil. --Chuck

On Sun, 2025-02-16 at 13:08 -0500, Paul Koning via cctalk wrote: I put an LR parser generator that includes Tom Pennello's Forward Move Algorithm for error recovery at https://sourceforge.net/projects/lr-and-lex-gen-fortran/files//?upload_just… It uses Dave Pager's algorithm to generate LALR where possible, and LR where necessary, that is, when states with identical core cannot be merged because of lookahead conflicts. I stopped working on it when I retired. The full exploitation of the extra information in the LR table isn't implemented in the simple parser inside of the parser generator.

Is it posted anywhere? Sent from my iPhone

On 2/16/25 12:41, Van Snyder via cctalk wrote: It also had better diagnostics than say, the S/360 USA Basic FORTRAN compiler. --Chuck

On 2/16/25 11:54, Van Snyder via cctalk wrote: A co-worker from long ago who was part of the IBM COMTRAN project once told me that the IBM PL/I group was the biggest bunch of misfits that had ever been assembled. I won't go any further on that, because I'd be engaging in gossip. --Chuck

I remember PL/C, a compiler for student use created at Cornell U. My compiler class was at first required to build on that, because the prof had been the lead implementer of PL/C. We finally got excused from that requirement because we had to use lots of macros, and the macro processing in that compiler often caused the compiler to crash. The problem is the macro expander (foolishly) tried to honor the "source margins" property of the original input text. So we switched to Pascal on the PDP-10, which was vastly superior in every way, and I haven't been tempted to touch PL/I since. paul

My father (a metrologist and professor of mechanical engineering) would read ALGOL programs written by others, based on their resemblance to English. And yes, it was for years the choice for expressing algorithms in journals such as CACM. The fashion of rendering keywords as bold text fits that usage very well. On the other hand, it's clear that, at least starting with ALGOL 60, we're dealing with a programming language meant to be run on actual computers, and if there was any doubt about that the work of Dijkstra et al. should settle the question. If a language doesn't have blocks (whether with begin/end keywords or something equivalent, as ALGOL 68 allows) it can't reasonably be called ALGOL or even a subset. Well, "ALGOL 58" is not a thing. The document describing the 1958 language called it "International Algebraic Language". I only glanced at it -- the first time I saw an actual description is when I read the 1958 report in an appendix of Gauthier's thesis -- but my memory is that it can't be thought of as a subset of Algol 60 but rather a dead end relative that went off in a wrong direction that the 1960 report abandoned. paul

On Sun, 2025-02-16 at 16:59 +0000, Chuck Guzis via cctalk wrote: The JPL suite of navigation software — orbit and trajectory determination, trajectory planning, … — started out in FAP and IBMAP on IBM 709 and 7090 and 7094 computers. It was converted to Fortran by about 1966. It eventually grew to more than sixty programs, encompassing about six million lines. In the mid 1990's a middle manager got a wasp up his ass and decreed it all had to be re-written in C++. I urged them to study Les Hatton's measurements that the average C++ program cost six times more during its entire life cycle than an equivalent program written in Fortran, C, or Ada. They did it anyway. They asked for 120 work years of funding. Fifteen years later they said "we're about 90% finished. We have a few loose ends. We only need another 120 work years of funding." It was used side-by-side with the legacy code for the Phoenix Mars lander. One of the navigators whispered to me "It doesn't work!" Instead of the original ODP (Orbit Determination Program) name, it's now called MONTE (Mission analysis, Operations, and Navigation Toolkit Environment). It works now. There's a python program that's helpful for preparing its input. Of course, that program is called MONTE Python. The Fortran-based ODP was maintained by a staff of 6.5 full-time equivalent. The MONTE staff is more than thirty. The Fortran standard has remained under development. FORTRAN 66 was the first language standardized by ANSI. Since then, standards were published in 1977, 1990, 2003, 2008, 2018, and 2023. A revision is under development. Intel provides free compilers for Windoze and Linux. The GNU compiler — gfortran — is available for many programs, but has an "interesting" definition of standard conformance. Sun offered a free compiler, but that got the axe when Oracle bought Sun. NVidia offers a compiler that includes CUDA extensions. And of course Cray (now part of HP/E) has one.

On 16/02/2025 14:56, Paul Koning via cctalk wrote: Certainly, it's the BEGIN/END (or compound statements) that Algol introduced which matter. Algol 58 had it. As to 58 not being a thing - as I said it didn't crystallise until Algol 60 but I'd still argue it was a thing... The origin of IAL later Algol later Algol 58 was described in the Perlis and Samuelson report published by the ACM at the time (Association for Computer Machinery). I'll spare you the details (I have a copy on paper in front of me reproduced in Jean Sammet's "Programming languages: History and Fundamentals - "Preliminary Report - International Algebraic Language" from Vol 1 Issue 12). I'd love to see the "1958 report in an appendix of Gauthier's thesis", but I'm sure I don't have it.  Apart from the history, part 1 it ends: 1. The new language should be as close as possible to standard mathematical notation and be readable with little further explanation. [We've heard that one since!] 2. It should be possible to use it for the description of computing processing in publications. 3. The new language should be mechanically translatable into machine programs. It's heavily implied that the ACM/GAMM committee intended it to be a standard but they don't quite say so. Algol 60 enhanced the 58 specification, but mostly by adding input/output and practical stuff. As I said, as far as I can make out from the 58 report, Algol 60 simply dropped DO statements, and blank parameter positions. Unfortunately the preliminary report published by the ACM was never followed up by another as far as I know (as mentioned above the appendix to Gauthier's thesis, of which I'm unfamiliar, would be of great interest!!!) It's worth noting that the Algol 58 specification was the basis for other languages like JOVIAL, CLIP, NELIAC and MAD. But one really interesting first about Algol (apart from it being the first inter-organisational attempt at standardising a language) is that it explicitly broke it into a reference language, a publication language and hardware representation. I believe the reference language was the most significant, as it could be used to publish algorithms in a standard form before hardware and compilers were developed to run them directly. It was the only language permissible for the publication of algorithms in the ACM Bulletin through most of the 1960s. I believe that stuff published in the Algol Bulletin was translated into Fortran in order to test it!

It's true that what we now call ALGOL 58 was never a specification, let along a standard. But it wasn't a dead end, either. The title of the report that described it was "Preliminary Report--International Algebraic Language" (Communications of the ACM, Volume 1, Number 12 (December 1958), pages 8-22). It was a progress report on the effort to design a new language. The ACM-GAMM committee kept refining their ideas and eventually came up with ALGOL 60. The problem was that the ideas proposed by the committee's progress report were so interesting that the report quickly spawned numerous implementations, each with their own dialect and limitations, including JOVIAL, NELIAC, ALGO for the Bendix G-15, and two versions from Burroughs known as BALGOL, one for the 220 and one for the Datatron 205.

I would call that an "electrostatic printer" -- xerographic printer work that way, depositing plastic soot that is then melted onto the paper. At U of Illinois I used a printer very much like what you describe, made by Varian. That was a dot matrix line printer -- a row of pixels across the page at once -- we used for printing music scores. 100 dpi or so if I remember right. paul

On 2/17/25 09:03, Jon Elson via cctalk wrote: I think the stuff may still be available in single sheets for physics demonstrations and perhaps for use in kymographs not using ink. I checked up on availability perhaps 20 years ago, but not recently. --Chuck

On Mon, 2025-02-17 at 17:35 +0000, Chuck Guzis via cctalk wrote: I think the printer beside the B220 in the Caltech Boothe computer center was probably mistakenly called a teledotis printer. It definitely deposited soot on the paper, and then thermally fused it.

On 2/17/25 16:32, Martin Bishop via cctalk wrote: 30 years ago or so, I had THREE Versatec 1200A printers at home. I did have one running for a while, but if you didn't use it frequently, the liquid toner would settle out and there was not a great way to re-suspend the toner particles.  I was glad to retire them for laser printers, and get rid of the smelly toner and chalky paper. Jon

Indeed. There's a wonderful photo of them by Ansel Adams. Look for it; it shows the two of them doing a mad-genius imitation, with a random collection of waveguides and the like in their hands. The Varian printer had one interesting issue. It had a chain drive, with some slack in the chain. If you fed it data non-stop it worked great, but if you ever had to pause the data stream, the stop and start of the paper would leave a gap in the output. Very visible if you were trying to plot continuous lines (like the 5 horizontal lines in a music score). The original application to feed that printer on the PLATO system was a batch job that routinely got pre-empted by the scheduler, just long enough for its buffer to go empty. I ended up doing the whole job in PPUs (reading the input file as well as feeding the printer). paul

Yes, that's the one. Impressive photo. paul