Early Programming Books
toby at telegraphics.com.au
Sun Jun 20 21:13:18 CDT 2021
On 2021-06-20 10:06 p.m., ben via cctech wrote:
> On 2021-06-20 6:57 a.m., Toby Thain via cctech wrote:
>> On 2021-06-20 1:39 p.m., Paul Birkel via cctech wrote:
>>> I'm much more curious about programming books that were *not* machine
>>> That is, about "general principles" of designing/preparing software for
>> Not sure if it's what you are looking for, but if you haven't, check out
>> "Classic Operating Systems" by Per Brinch Hansen.
>>> Of course, one needs a language; McCracken (1957) defines TYDAC.
>>> Much later (1968) Knuth defines MIX.
>>> In between perhaps one could argue that ALGOL 58 qualifies as such a
>>> language-for-demonstration, but I don't believe that there were any
>>> specifically about programming in ALGOL 58. I presume that there were
>>> eventually such books for ALGOL 60.
>> Pretty sure I own one, by Dijkstra. Will get details later if you are
> I suspect after 1958 people stopped thinking of real world programming
> problems. All the general programming books, seem to want to get rid of
> the "goto" or have Strange-multi-level variables or procedures or just
Structured Programming is even manifested in a language as neckbeardy as
C; it's not only for quiche eaters any more.
> use unbounded memory. Operating system books have chapters about some
> logic construct only to state later in the book, "That does not apply
> to this system setup".
> My latest gripe, is I still am looking for a algorithm to generate
> code for a single accumulator machine for an arithmetic expression.
Tried the Shunting Yard algorithm? But watch out, it was invented by a
> Parenthesis need to evaluated first and temporary variables allotted,
> thus a two pass algorithm. Everything is single pass. Recursive decent
> can parse but can't generate 'correct' code. A-(B+C) is LD B ADD C ST T1
> LD A SUB T1, not LD A ST T1 LD B ST T2 LD C ADD T2 NEGATE ADD T1
More information about the cctalk