Re: Early Programming Books

[Lee Courtney via cctalk]

Hi Paul - the images are on-line, I blame my inept typing and editing
skills for not properly deleting that line. Originally I wrote that line as
they are not on-line via CHM. But, I thought to look on Al's site and of
course there they are. Which is the important thing - that people can get
access to them.

Computers...jeesh! Do what I want, not what I say!  ;-)

Lee

On Wed, Jun 23, 2021 at 10:26 AM Paul Koning  wrote:

>
>
> > On Jun 23, 2021, at 1:17 PM, Lee Courtney via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > "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?"
> >
> > Yes. Catalog entry here:
> > https://www.computerhistory.org/collections/catalog/102710141
> >
> > Many years (decades?) ago Dave Babcock and I read all the cards as part
> of
> > the original 1620 project at CHM. Thank God for Bitsavers.org because the
> > images of the software are available here:
> > http://bitsavers.org/bits/IBM/1620/
> >
> > Enjoy!
> >
> > Lee C.
> >
> > The obvious question is why is this material not on-line
>
> You gave a link to the "images" on bitsavers, so what did you mean by "not
> on-line"?
>
> paul
>
>

-- 
Lee Courtney
+1-650-704-3934 cell

Re: CHM's 1620 (was Re: Early Programming Books)

[jim stephens via cctalk]

On 6/23/2021 10:25 AM, Al Kossow via cctalk wrote:

On 6/23/21 10:17 AM, Lee Courtney via cctalk wrote:

Many years (decades?) ago Dave Babcock and I read all the cards as 
part of

the original 1620 project at CHM.


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.


This is my fault, and I apologize.  I had the 1620 at USL that I first 
mentioned and it was a lament that a solid machine with printer and card 
reader / punch plus a spare cpu was not preserved to my knowledge.  
There was a great donation made to the CHM, and that is the source of 
the misunderstanding.


The system I speak of was in Lafayette, LA, and it would probably not 
have been feasible to save the 1620, or the GT-40 that was in my lab there.


That system to my knowledge has nothing to do with the museums holdings.

It's just a lament that such a gem was not saved or fate is unknown.  I 
appreciate finding out that what did get to the CHM from that collection 
is in good hands.


Thanks
Jim

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 23, 2021, at 1:17 PM, Lee Courtney via cctalk  
> wrote:
> 
> "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?"
> 
> Yes. Catalog entry here:
> https://www.computerhistory.org/collections/catalog/102710141
> 
> Many years (decades?) ago Dave Babcock and I read all the cards as part of
> the original 1620 project at CHM. Thank God for Bitsavers.org because the
> images of the software are available here:
> http://bitsavers.org/bits/IBM/1620/
> 
> Enjoy!
> 
> Lee C.
> 
> The obvious question is why is this material not on-line

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

paul

CHM's 1620 (was Re: Early Programming Books)

[Al Kossow via cctalk]

On 6/23/21 10:17 AM, Lee Courtney via cctalk wrote:


Many years (decades?) ago Dave Babcock and I read all the cards as part of
the original 1620 project at CHM.


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.

Re: Early Programming Books

[Lee Courtney via cctalk]

"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?"

Yes. Catalog entry here:
https://www.computerhistory.org/collections/catalog/102710141

Many years (decades?) ago Dave Babcock and I read all the cards as part of
the original 1620 project at CHM. Thank God for Bitsavers.org because the
images of the software are available here:
http://bitsavers.org/bits/IBM/1620/

Enjoy!

Lee C.

The obvious question is why is this material not on-line

On Tue, Jun 22, 2021 at 11:46 PM Van Snyder via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, 2021-06-22 at 19:45 -0400, Paul Koning via cctalk wrote:
>
> >
> > There's actually a surprising amount of preserved material  Both
> > in source form, and both run in emulation.
>
> 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?
>
> > For most of this the source code still exists, though I'm not sure
> > about the 1620 bits.
>
> 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?
>
>
>

-- 
Lee Courtney
+1-650-704-3934 cell

Re: Early Programming Books

[Mark Linimon via cctalk]

On Tue, Jun 22, 2021 at 11:46:13PM -0700, Van Snyder via cctalk wrote:
> Is there a G-15 emulator?

I wrote a simulator yers 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

Re: Early Programming Books

[jim stephens via cctalk]

On 6/22/2021 11:46 PM, Van Snyder via cctalk wrote:

| 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?
I'm not sure what you are talking about.  Intel's engineers studied the 
Multics ring architecture then bungled the implementation of it.  the 
Intel 286 has nothing but that in common with Multics.


Thru the efforts of several very talented people, and the releasing of 
the archived sources that MIT had had, as well as a backup from a very 
good system, a Multics emulator was written that can be found to run on 
Linux and on the Raspberry pi, and presumably other platforms to which 
the emulator can be ported.


Is multics available for intel systems, as in did it ever run native.  
never.


but it does run just fine on Intel systems of about any sort running an 
appropriate host OS.


thanks
Jim

Re: Early Programming Books

[Van Snyder via cctalk]

On Tue, 2021-06-22 at 19:45 -0400, Paul Koning via cctalk wrote:

> 
> There's actually a surprising amount of preserved material  Both
> in source form, and both run in emulation.

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?

> For most of this the source code still exists, though I'm not sure
> about the 1620 bits.

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?

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 22, 2021, at 5:43 PM, ben via cctech  wrote:
> 
> ...
> 1965 to 1985 generated most of the new computing languages,operating
> systems and ideas. Sadly most of it seems lost source code wise.
> Ben.

I might push the start of that back to 1955, but apart from that I agree you 
have a good point.

There's actually a surprising amount of preserved material.  The SIMH project 
has been a very impressive help with that, as is Bitsavers.  Then there is 
Hercules and DtCyber, to mention just two classic architectures preserved in 
emulators -- and each of these comes with a substantial body of operating 
systems and languages.

The famous THE system has been preserved.  The first ever ALGOL-60 compiler 
also (more precisely, the third, load and go, version of that compiler -- but 
that was a small incremental change not affecting the essential structure).  
Both in source form, and both run in emulation.  The same goes for Multics, and 
OS/360, and CDC COS and Scope and Kronos, and Burroughs mainframe MCP.  There 
is a collection of PDP-1 software, and IBM 1620 software, and so on.  You can 
still run APL\360 as it existed on the IBM 360 mainframes, and you can 
experience the PLATO system just as it was in the late 1970s (for that, see 
cyber1.org).

For most of this the source code still exists, though I'm not sure about the 
1620 bits.  So you aren't limited to playing with it, you can study the code, 
in as much depth as you care to.  Some have gone deep enough to get a Ph.D. for 
their work (Gauthier van den Hove's extremely detailed analysis of that first 
ALGOL compiler).

Of course there's also a lot that has vanished.  The machine on which I learned 
assembly language seems to have vanished from history except for one sales 
pamphlet (the Philips PR8000).  Software of the MC (CWI) research machines is 
pretty much gone, which is quite unfortunate since one of them is an ARMAC demo 
program written by Dijkstra containing his original implementation of the 
"shortest path" algorithm that later became the essence of several Internet 
routing protocols.

paul

Re: Early Programming Books

[ben via cctalk]

On 2021-06-22 3:10 p.m., r.stricklin via cctech wrote:




On Jun 22, 2021, at 12:40 PM, ben via cctech  wrote:



Lisp is evaluated, not compiled from what little I have read.
If I could read the papers (for free) I could know more.


So… have I got this right?

1. You admit directly you have only a little knowledge on the topic.
2. You choose to stand by your uninformed opinion (and dig your heels in 
deeper, even) instead of accepting information from somebody with more 
knowledge and/or direct experience, or taking the initiative to learn more 
about it yourself, before spouting off about it on a public mailing list.


Jesus take the wheel.


ok
bear.

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.

Re: Early Programming Books

[r.stricklin via cctalk]

> On Jun 22, 2021, at 12:40 PM, ben via cctech  wrote:

> Lisp is evaluated, not compiled from what little I have read.
> If I could read the papers (for free) I could know more.

So… have I got this right?

1. You admit directly you have only a little knowledge on the topic.
2. You choose to stand by your uninformed opinion (and dig your heels in 
deeper, even) instead of accepting information from somebody with more 
knowledge and/or direct experience, or taking the initiative to learn more 
about it yourself, before spouting off about it on a public mailing list.


Jesus take the wheel.


ok
bear.

Re: Early Programming Books

[Jay Jaeger via cctalk]

I’d like a copy.  This is the card version?


Sent from my iPhone

> On Jun 22, 2021, at 3:28 PM, Van Snyder via cctalk  
> wrote:
> 
> On Tue, 2021-06-22 at 15:44 -0400, Paul Koning via cctalk wrote:
>> The Electrologica ALGOL compilers used somewhat similar mixtures of
>> pseudocode and machine code.
> 
> The IBM 1401 Fortran compiler 1401-FO-050 (subset of Fortran II)
> generated machine code for integer operations, and bytecode for
> floating point. The machine didn't have any floating-point hardware.
> The bytecode was smaller than subroutine calls would have been.
> Floating-point arithmetic was rather well done. Up to 20 decimal
> digits, with two guard digits. Only significant defect was that
> rounding wasn't symmetric. Gary Mokotoff did a very good job. I have
> the source code if anybody wants it.
> 

Re: Early Programming Books

[Van Snyder via cctalk]

On Tue, 2021-06-22 at 15:44 -0400, Paul Koning via cctalk wrote:
> The Electrologica ALGOL compilers used somewhat similar mixtures of
> pseudocode and machine code.

The IBM 1401 Fortran compiler 1401-FO-050 (subset of Fortran II)
generated machine code for integer operations, and bytecode for
floating point. The machine didn't have any floating-point hardware.
The bytecode was smaller than subroutine calls would have been.
Floating-point arithmetic was rather well done. Up to 20 decimal
digits, with two guard digits. Only significant defect was that
rounding wasn't symmetric. Gary Mokotoff did a very good job. I have
the source code if anybody wants it.

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 22, 2021, at 3:40 PM, ben via cctalk  wrote:
> 
> ...
> Lisp is evaluated, not compiled from what little I have read.
> If I could read the papers (for free) I could know more.
> Refal "Recursive functions algorithmic language" from Russia
> looks just what I was looking for. Around since 1966.
> Ben.

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

Re: Early Programming Books

[ben via cctalk]

On 2021-06-21 3:47 p.m., Rich Alderson wrote:

Date: Sun, 20 Jun 2021 22:19:02 -0600
From: ben via cctalk 



LISP still can't be compiled.


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


Lisp is evaluated, not compiled from what little I have read.
If I could read the papers (for free) I could know more.
Refal "Recursive functions algorithmic language" from Russia
looks just what I was looking for. Around since 1966.
Ben.

Water Cooling and Hot Climates was RE: IBM 1620; was: Early Programming Books

[Dave Wade G4UGM via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Van Snyder via
> cctalk
> Sent: 22 June 2021 00:00
> To: cctalk@classiccmp.org
> Subject: Re: IBM 1620; was: Early Programming Books
> 
> On Mon, 2021-06-21 at 17:26 -0400, William Donzelli via cctalk wrote:
> > > Of course, nowadays, the old R22 systems are being refilled with
> > > purified propane, called R290.  Cheap, with better thermal
> > > properties than R22, but probably not legal when LCM picked up the
> 6500.
> >
> > 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.
> 
> I was once told that the most valuable guy in a Honeywell 6080 Multics shop
> was the plumber.
> 

I don't ever remember the 6080 being water cooled? I Thought Honeywell/GEC was 
all air cooled. All the L66s (which were from what the Multics machine was 
developed) were air cooled.

I was told the following tale by one of my Honeywell contacts

... Apparently the last Shah of Iran owned a Level 66 for the use of his secret 
police. Apart from the fact that the OS had been modified by Honeywell Italy, 
and the documentation for this was in Italian which no one on the job 
understood, and when the OS crashed it was usually in a section of the code 
with Italian comments,  there was also a problem with the power. As the 
temperature rose the power invariable failed. This was because it was run from 
a diesel generator that was out in the sun, it over heated and cut out.

... any way after many complaints the military man in charge came to the 
Honeywell staff and told them the problem was solved. They of course asked how 
and were taken to the generator and shown the latest modification. They had 
fitted a new cap to the radiator with a thermometer in it, as often found on 
vintage cars. They had painted a read line on the gauge and assigned a soldier 
to watch it. When the needle got to the line, he blew his whistle and several 
other soldiers appeared and threw buckets of water over the engine until it 
cooled down
 
I just wonder what they did while waiting for it to overheat..

> >
> > --
> > Will

Dave
G4UGM

Re: Early Programming Books

[Daniel Moniz via cctalk]

On Mon, Jun 21, 2021, at 12:05 AM, Van Snyder via cctalk wrote:

[snip]

> denizen of the Fortran committees) is a LALR parser generator. I use
> the generator written by Al Shannon when he was Charlie Wetherell's
> student, now updated, which implements David Pager's algorithm that
> generates a parser that is LR where necessary and LALR or SLR or LR(0)
> where possible.

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  
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. 
?


-- 
Daniel Moniz  [http://pobox.com/~dnm/]

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 20:49 -0700, Daniel Moniz via cctalk wrote:
> On Mon, Jun 21, 2021, at 12:05 AM, Van Snyder via cctalk wrote:
> [snip]
> > denizen of the Fortran committees) is a LALR parser generator. I
> > usethe generator written by Al Shannon when he was Charlie
> > Wetherell'sstudent, now updated, which implements David Pager's
> > algorithm thatgenerates a parser that is LR where necessary and
> > LALR or SLR or LR(0)where possible.
> 
> 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>;?

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.

Re: Early Programming Books

[Daniel Moniz via cctalk]

On Mon, Jun 21, 2021, at 12:05 AM, Van Snyder via cctalk wrote:

[snip]

> denizen of the Fortran committees) is a LALR parser generator. I use
> the generator written by Al Shannon when he was Charlie Wetherell's
> student, now updated, which implements David Pager's algorithm that
> generates a parser that is LR where necessary and LALR or SLR or LR(0)
> where possible.

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  
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. 
?


-- 
Daniel Moniz  [http://pobox.com/~dnm/]

Re: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 4:56 PM, Paul Koning wrote:

> Pascal was done by Wirth, not Dijkstra.  The issue with 1620 state is that 
> you couldn't do multiprogramming because you could not context switch 
> threads.  The problem is the subroutine call; BB (subroutine returns) uses an 
> invisible register.

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

Re: IBM 1620; was: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 18:55 -0500, Gavin Scott via cctalk wrote:
> Oh yeah, that was like 12 years ago? I believe they had gotten the
> 1620 CADET (“Can't Add, Doesn't Even Try”) running

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.

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 6:03 PM, Chuck Guzis  wrote:
> 
> On 6/21/21 1:13 PM, Paul Koning wrote:
>> 
>> 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.
> 
> 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).

That may have been after the time when he did the evaluation (early 1960s).  
The paper in in the EWD collection, I don't have the number handy.

> 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.

Speaking of character I/O, I think he also mentioned as a problem the fact that 
there was a paper tape reader, but it could not read arbitrary 8-bit patterns.

> 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?

Pascal was done by Wirth, not Dijkstra.  The issue with 1620 state is that you 
couldn't do multiprogramming because you could not context switch threads.  The 
problem is the subroutine call; BB (subroutine returns) uses an invisible 
register.

On I/O, it's not all that well known but the I/O system on the Electrologica X8 
(which has a separate I/O coprocessor, vaguely like a CDC 6000 PPU but not 
user-programmable as far as I know) uses semaphores to communicate between the 
two engines.  There's a semaphore that tracks the number of pending requests, 
and another that tracks completions and controls interrupt delivery.  That is 
in addition to the widespread use of semaphores in the THE operating system.  
It's a very nice structure, and very reliable.

paul

Re: IBM 1620; was: Early Programming Books

[Gavin Scott via cctalk]

On Mon, Jun 21, 2021 at 1:43 PM Chuck Guzis via cctalk
 wrote:
> 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.

Oh yeah, that was like 12 years ago? I believe they had gotten the
1620 CADET (“Can't Add, Doesn't Even Try”) running, but there was
something original they didn't have working (could have been the core)
that they had implemented in a little semiconductor board stuck in it.
IIRC the system was in operating condition at the time. But I had
forgotten I ever knew this until you mentioned it.

Re: IBM 1620; was: Early Programming Books

[jim stephens via cctalk]

On 6/21/2021 4:00 PM, Van Snyder via cctalk wrote:

I was once told that the most valuable guy in a Honeywell 6080 Multics
shop was the plumber.

No water cooling.

Re: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 4:04 PM, Van Snyder via cctalk wrote:
> On Mon, 2021-06-21 at 15:03 -0700, Chuck Guzis via cctalk wrote:
>> But then Dijkstra
>> should talk--how about the wonderful I/O capabilities of the first
>> version of Pascal?
> 
> Pascal was developed by one of Niklaus Wirth's students.

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

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 15:03 -0700, Chuck Guzis via cctalk wrote:
> But then Dijkstra
> should talk--how about the wonderful I/O capabilities of the first
> version of Pascal?

Pascal was developed by one of Niklaus Wirth's students.

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 17:47 -0400, Rich Alderson via cctalk wrote:
> > Date: Sun, 20 Jun 2021 22:19:02 -0600From: ben via cctalk <
> > cctalk@classiccmp.org>
> > LISP still can't be compiled.
> 
> 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 papersby Guy Steele is a comparison of the compiler for MACLISP
> (the Project MACdialect of Lisp, nothing to do with Apple computers)
> with the then currentFORTRAN compiler for the PDP-10 (called "F40"),
> in which the LISP compilergenerated better code than the FORTRAN
> compiler.
> Things have not degenerated since then.

Dave Card took Cray's eight favorite Fortran benchmarks and re-wrote
them in SISAL. They all ran faster.
> Rich

Re: IBM 1620; was: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 17:26 -0400, William Donzelli via cctalk wrote:
> > Of course, nowadays, the old R22 systems are being refilled with
> > purified propane, called R290.  Cheap, with better thermal properties
> > than R22, but probably not legal when LCM picked up the 6500.
> 
> 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.

I was once told that the most valuable guy in a Honeywell 6080 Multics
shop was the plumber.

> 
> --
> Will

Re: IBM 1620; was: Early Programming Books

[Rich Alderson via cctalk]

> Date: Mon, 21 Jun 2021 16:02:20 -0400
> From: Paul Koning via cctalk 

>> On Jun 21, 2021, at 3:52 PM, Chuck Guzis  wrote:

>> On 6/21/21 11:53 AM, Paul Koning wrote:

>>> 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.

>> From whence did the LCM 6500 come?

> 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.

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

Re: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 2:47 PM, Fred Cisin via cctalk wrote:
>>> Is Fortran the newer version of FORTRAN ( I II IV )?
> 
> On Mon, 21 Jun 2021, Chuck Guzis via cctalk wrote:
>> My recollection from X3J3 is that "Fortran" was officially endorsed with
>> F90.  F77 still has FORTRAN officially.
> 
> After "FORTRAN 77", but before "Fortran 90", "Fortran 8X"
> (DOD extensions standardized, etc.)

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

Re: IBM 1620; was: Early Programming Books

[William Donzelli via cctalk]

> 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.

So I just reread what I wrote, and see it is crap. What I meant is
that CDC machines going back all the way to the 6000s and 7000s, and
UP TO the 800s, were unpicky. Basically, most of the line.

Me not poet.

--
Will

Re: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 1:13 PM, Paul Koning wrote:
> 
> 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.

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?

> 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.

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.

> 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.

Again, the Burroughs architecture was an outlier from the general
machine population.

> 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"...

IBM 650 SAP at least had mnemonics.  The 1401 opcodes at least hinted at
their function.

--Chuck

Re: Early Programming Books

[Daniel Seagraves via cctalk]

> On Jun 21, 2021, at 4:47 PM, Rich Alderson via cctalk  
> wrote:
> 
>> Date: Sun, 20 Jun 2021 22:19:02 -0600
>> From: ben via cctalk 
> 
>> LISP still can't be compiled.
> 
> May I respectfully suggest that you don't know WTF you're talking about?

I’ll save you some time and trouble, because I’d learned to stop arguing with 
people who hold this opinion:

“WELL ACKSHUALLY” (push glasses up) “THE LISP MACHINES WERE MICROCODED WHICH 
MEANS THERE IS NO REAL LISP MACHINE, THE UNDERLYING MICROENGINE IS THE REAL 
PROCESSOR, AND IT DOES NOT RUN LISP, SO LISP MACHINES DID NOT EXIST.”

They then move the goalposts around regarding what is considered a REAL 
PROCESSOR and what is not until you give up and they “win” by default.

I will now go back to refusing to talk about or work on lisp projects anymore 
because The Community has beaten any will to do so out of me.

Re: Early Programming Books

[Rich Alderson via cctalk]

> Date: Sun, 20 Jun 2021 22:19:02 -0600
> From: ben via cctalk 

> LISP still can't be compiled.

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

Re: Early Programming Books

[Fred Cisin via cctalk]

Is Fortran the newer version of FORTRAN ( I II IV )?


On Mon, 21 Jun 2021, Chuck Guzis via cctalk wrote:

My recollection from X3J3 is that "Fortran" was officially endorsed with
F90.  F77 still has FORTRAN officially.


After "FORTRAN 77", but before "Fortran 90", "Fortran 8X"
(DOD extensions standardized, etc.)

The FORTRAN that I used on the 1620 (1967-1969 at Merritt College (home of 
the Black Panthers) in Oakland) was a possibly local variant called "PDQ 
FORTRAN" ("Pretty Damn Quick"?)



In 1983, I got hired to teach FORTRAN and Microcomputer Operating Systems 
at Merritt, which was now up on the hill, out of reach of the flatlands 
Oakland politics.  The existing teacher had walked out, and I was hired as 
a long-term substitute hours before the class met.
I continued running a software business, in addition to "full-time" 
teaching.


They had had a DEC machine whose drive had never been reliable.  Then they 
sold that to Richmond public school district and bought a roomfulo of 
5150s. 
I taught using IBM PC FORTRAN, which was just fine for teaching, but 
extraordinarily slow (Sieve of Erastothanes benchmark was slower than 
interpreted BASIC).


When Richmond installed it, PG got it wrong about Delta VS WYE three 
phase power!  But, in exchange for everybody publicly saying that it had 
been a "lightning strike" that did it in, PG bought Richmond Schools a 
replacement machine, and the drive reliability problems were finally 
solved.


I stayed in the Peralta Community College District, that Merritt was part 
of, for more than 30 years, and retired with a decent stable state 
administerd pension and very good unstable college administered health 
benefits.


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: IBM 1620; was: Early Programming Books

[William Donzelli via cctalk]

> Of course, nowadays, the old R22 systems are being refilled with
> purified propane, called R290.  Cheap, with better thermal properties
> than R22, but probably not legal when LCM picked up the 6500.

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

Re: IBM 1620; was: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 1:02 PM, Paul Koning wrote:

> 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.

If that was the system in the basement of the Math building, I remember
it well.  When I used it, it was running an enhanced version of MACE;
Greg Mansfield's and Dave Callender's predecessor to Kronos.   Differed
from SCOPE in that much more of the system was CM-resident.  There were
other significant internal differences as well from SCOPE.

Did I ever mention that I was the one who introduced Greg to the wonders
of gelato?  I know that Greg left CDC to work for Cray; but I lost track
of him sometime in the late 1980s.

I can well imagine that it was a struggle to get the system out of the
Purdue location.  What with the 7090s and the 1401, it was pretty crowded.

Of course, nowadays, the old R22 systems are being refilled with
purified propane, called R290.  Cheap, with better thermal properties
than R22, but probably not legal when LCM picked up the 6500.

--Chuck

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 16:13 -0400, Paul Koning via cctalk wrote:
> 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.

Univac 1108 had two sets of registers, selected by a bit in the
Processor Status Word. The "interrupt" set was automatically selected
when an interrupt occurred, so interrupt-service code didn't need to
save registers. They were made from thin-film magnetic memory, not
semiconductors. They occupied "core" locations starting at zero. There
was "core" behind them that could be accessed by setting the indirect-
address bit in the instruction word -- which actually did indirect
addressing if the address wasn't in the register file.

In each set, there were 16 index (X) registers, although X0 always
contained zero, 16 accumulator (A) registers, and 16 general-purpose
(R) registers. R0 was the real-time clock. R1 was for block
instructions. R2 was for mask instructions. X12-X15 and A0-A3 were
actually the same overlapping registers so you could do "accumulator
stuff" to calculate index registers, and then not need to move the
result.

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 11:26 AM, Chuck Guzis via cctalk  
> wrote:
> 
> On 6/21/21 1:39 AM, ben via cctalk wrote:
> 
>> I have 'borrowed' copy of the Green dragon book.
>> The book promotes code generation for a multi register machine. PDP 11,
>> PDP 10, IBM 360. "(C) Bell Labs 1979 " I think is big hint here.
>> 
>> The machine model I am looking at is a single accumulator design like
>> the 6800 or the IBM 1130. A AC,PC,Index and stack. No push or pop,
>> subroutine call returns the old pc in the AC.
> 
> 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.)

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.

> 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.

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.

>> ...
> 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.  

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

Re: IBM 1620; was: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 3:52 PM, Chuck Guzis  wrote:
> 
> On 6/21/21 11:53 AM, Paul Koning wrote:
> 
>> 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.
> 
> No, it was definitely a CHM project--could have been for the 1401,
> though.In way of comparison to the 6000 core, 1401 and 1620 memory
> is much larger, less dense and slower--and I don't believe that the
> machine architecture makes use of a read-modify-write that the 6000 so
> neatly exploited.
> 
> From whence did the LCM 6500 come?
> 
> --Chuck

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

Re: IBM 1620; was: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 11:53 AM, Paul Koning wrote:

> 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.

No, it was definitely a CHM project--could have been for the 1401,
though.In way of comparison to the 6000 core, 1401 and 1620 memory
is much larger, less dense and slower--and I don't believe that the
machine architecture makes use of a read-modify-write that the 6000 so
neatly exploited.

>From whence did the LCM 6500 come?

--Chuck

Re: IBM 1620; was: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 2:43 PM, Chuck Guzis via cctalk  
> wrote:
> 
> 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

RE: IBM 1620; was: Early Programming Books

[Dave Wade G4UGM via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Chuck Guzis via
> cctalk
> Sent: 21 June 2021 19:43
> To: Paul Koning via cctalk 
> Subject: Re: IBM 1620; was: Early Programming Books
> 
> 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
> 

I believe that CHM had several issues with its 1620. There was also a project 
to produce a new console

https://hackaday.com/tag/ibm-1620/

Dave

Re: IBM 1620; was: Early Programming Books

[Chuck Guzis via cctalk]

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

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 1:53 PM, Van Snyder via cctalk  
> wrote:
> 
> On Mon, 2021-06-21 at 06:02 -0700, jim stephens via cctalk wrote:
>> That 1620 would have been a fantastic addition to their running 
>> display.  Much easier to work on than what it sounds like the 1401 is.  
>> And with a duplicate backup.
> 
> 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.

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.

paul

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 06:02 -0700, jim stephens via cctalk wrote:
> That 1620 would have been a fantastic addition to their running 
> display.  Much easier to work on than what it sounds like the 1401 is.  
> And with a duplicate backup.

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.

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 08:26 -0700, Chuck Guzis via cctalk wrote:
> 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.

IBM provided coding forms for the 1401, for both SPS and Autocoder.
They provided a "pocket reference card" for absolute machine code.

The machine had two one-character data registers that connected the CPU
to core, and two address registers. Three index registers were in core.

Univac provided a pocket reference card for the 1108, but didn't bother
with coding forms because assembler input was free form.

Re: Early Programming Books

[Van Snyder via cctalk]

On Mon, 2021-06-21 at 02:39 -0600, ben via cctalk wrote:
> Is Fortran the newer version of FORTRAN ( I II IV )?

The "newer" version of Fortran is Fortran 2018. The working draft for
the next standard is https://j3-fortran.org/doc/year/21/21-007.pdf.

ISO Standard  versions:

ISO R 1539-1972 FORTRAN 66  Fortran IV, ANSI X3.9-1966ISO
1539-1980   FORTRAN 77  ANSI X3.9-1978ISO/IEC 1539-
1:1991  Fortran 90ISO/IEC 1539-1:1997   Fortran 95ISO/IEC 1530-1:2004   
Fortran 2003ISO/IEC 1539-1:2010 Fortran 2008ISO/IEC 1539-1:2018 Fortran
2018
Fortran 66 was the first language standard published by ANSI. At that
time, it was by far the longest standard -- 39 pages -- that ANSI had
published. The longest previous standard was a two-page standard for
screw threads.

The difference between the "year number" such as "90" in the informal
name, and the ISO publication date, was because the Fortran committees'
preference had been to denote the version of the standard by the year
that technical content was frozen. Technical content for Fortran 2018
was frozen in 2015, but a policy change was voted to denote that
standard, and future ones, by the year ISO got around to issuing a
publication. Although the technical content of the next standard was
frozen in February 2021, it will probably be published in 2023.

Re: Early Programming Books

[Chuck Guzis via cctalk]

On 6/21/21 1:39 AM, ben via cctalk wrote:

> I have 'borrowed' copy of the Green dragon book.
> The book promotes code generation for a multi register machine. PDP 11,
> PDP 10, IBM 360. "(C) Bell Labs 1979 " I think is big hint here.
> 
> The machine model I am looking at is a single accumulator design like
> the 6800 or the IBM 1130. A AC,PC,Index and stack. No push or pop,
> subroutine call returns the old pc in the AC.

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.

> Is Fortran the newer version of FORTRAN ( I II IV )?

My recollection from X3J3 is that "Fortran" was officially endorsed with
F90.  F77 still has FORTRAN officially.

> There is very little to to bootstrap with today, that uses a small
> amount of memory.I need a cross compiler for my machine like K C
> style compiler ,not the latest C+-#@? compiler.
> I have no problem with a recursive decent compiler,I just have subtract
> divide and mod reversed in places, something I want to avoid as well a
> DISPLAY's like in Algol or Pascal.

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.

> The machine works on FPGA delopment card, see the bliking lights on the
> kitchen table. No hypothetical here.
> 
> 1) Computer Check
> 2) Front panel  Check
> 3) Bootstrap  loader Check
> 4) Software No Check
> Stage 4 is the problem.

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

Re: Early Programming Books

[Paul Koning via cctalk]

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

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 5:03 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.

Given the MC's mission that fits.  In their early days they did computation 
(numerical methods) on a contract basis for customers.  At first this involved 
one set of people to design the algorithms, and another set of people (called 
"computers", or if you wants to capture the essence of the Dutch word, 
"computresses") to execute them on mechanical desk calculating machines.  
Around 1948 they started an effort to create a computer, in the modern sense of 
the word, to automate that manual labor.  But all along, numerical methods was 
a particular focus.

paul

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 5:23 AM, ben via cctalk  wrote:
> 
> ...
> I want to transformatiom before full parsing expressions, as a text process.
> string "a+(b+c)*c" becomes "((b+c)*c)a+".

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

RE: Early Programming Books

[Paul Birkel via cctalk]

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-boun...@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

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 21, 2021, at 12:19 AM, ben via cctalk  wrote:
> 
> On 2021-06-20 9:01 p.m., Brent Hilpert via cctalk wrote:
>> On 2021-Jun-20, at 7:38 PM, ben via cctech wrote:
>>> On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:
>>> 
 Tried the Shunting Yard algorithm? But watch out, it was invented by a
 quiche eater...
>>> 
>>> The problem needs backtracking to generate correct code. Stack or 
>>> muilti-register machines don't have this problem with temporaries.
>>> Ben.
>> 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.
> 
> 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.

No, it doesn't.  All it requires is a scanner with a stack.  Most programming 
languages can be parsed without backtracking and with very limited lookahead.  
All this was well established in parser theory in the 1970s if not earlier.  
But your confusion is not unprecedented; I remember reading a parser (written 
in the early 1970s) written by someone who read a text book that actually 
claimed the same fallacy.  Needless to say the parser was rather messy, though 
it somehow managed to get the job done.

The "shunting yard" algorithm is a generalized form of the stack based 
expression parsing, applied to whole program parsing.  It was created, I 
believe, by Dijkstra and Zonneveld for the ALGOL-60 compiler they wrote in 
1961, the first ALGOL-60 compiler and, amazingly, an implementation of the full 
language (minus the mistakes), even though it ran on a machine with just 4 kW 
of memory.  For a short description, read Dijkstra's paper describing it, in 
English.  For a very detailed description, read the Ph.D. thesis of Gauthier 
van den Hove, a very impressive work of technical history writing.

The purpose of the shunting yard algorithm is to allow parsing without 
backtracking, which is rather important on a machine without enough memory to 
store the source text, and one that reads the program source from a paper tape 
reader (which, in most of them anyway, does not come with a "reverse" feature).

paul

Re: Early Programming Books

[jim stephens via cctalk]

On 6/21/2021 1:43 AM, ben via cctalk wrote:



But with all this computing science, they have yet to make a clean
meta compiler like Meta II, or Tree meta. 

The compiler structure used in Pick is pretty much like this.

XPL by William M. McKeeman and others which Microdata used to create the MPL
and EPL languages which were the basis for the 3200 OSs was a cross 
compiler with

the starter kit running in the Microdata case on an IBM 360.
thanks
Jim

Re: Early Programming Books

[jim stephens via cctalk]

On 6/21/2021 12:17 AM, Chuck Guzis via cctalk wrote:

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.
The University of Southwestern Louisiana had a running (actually two 
CPUs) and a reader punch and printer that I was able to do this with.  
1974.  I suspect destroyed as they didn't appreciate such.


They had it in storage and I pulled it out and restored it.  That I 
could isn't a credit to me, but to the bullet proof IBM (or close enough 
or me) nature of it, and great manuals.


They did keep the Microdata 3200 which is in the Computer History 
Museum, and was on display prior to their current exhibit layout.


That 1620 would have been a fantastic addition to their running 
display.  Much easier to work on than what it sounds like the 1401 is.  
And with a duplicate backup.


thanks
Jim

Re: Early Programming Books

[jim stephens via cctalk]

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:

Google document translate

Re: Early Programming Books

[ben via cctalk]

On 2021-06-21 2:35 a.m., Peter Corlett via cctalk wrote:


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.


I want to transformatiom before full parsing expressions, as a text process.
string "a+(b+c)*c" becomes "((b+c)*c)a+".


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.


 They need to be saved regardless of what machine model you use.


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.


  I just need calls for mult,divide and special operations. The limitation
is just memory and variable space compared to a larger machine. 2 
addressing modes, Immediate and indexed keep it simple. The compiled
language I plan to design will be simple, but records of some sort will 
be needed. Char,word and Real is all that you get.





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.


Were are the books, writing assemblers and loaders?
Ben.

RE: Early Programming Books

[Paul Birkel via cctalk]

Google document translate gives a modestly useful result after OCRing the UT
original scan (www.cs.utexas.edu/users/EWD/MCReps/CR1957-009.PDF).  Needs
significant further work for readability :-<.

Deeker, et al. appear to approach the topic from the perspective of
mathematics (that is, modestly abstractly) after introducing the standard
von Neumann 5-part model of a machine.  They keep that general description,
mapping mathematical expressions to general operations within that model.
TOC:

1. General Introduction to Automatic Calculators
2, The word
3. The number
4, The Command
5. Block diagrams
6. Subroutines I
7, An elaborate~ example
8. Subroutines II
9. Subroutines III
10. Speed
11. Scaling, Control and Flexibility
12. The Administrative Subroutine I
13. The Administrative Subroutine II
14. Super programs

McCracken approaches the topic with the same von Neumann model of a machine
but then proceeds from the perspective of a hypothetical "typical"
instruction set and a modestly specific architecture (e.g. signed ten-digit
storage).

AFAICS neither envisions representations for characters/text and the
processing thereof.

Both in 1957.  Something in the air :->?

-Original Message-
From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Paul Koning
via cctech
Sent: Sunday, June 20, 2021 5:06 PM
To: Norman Jaffe; General Discussion: On-Topic Posts
Subject: Re: Early Programming Books

> On Jun 20, 2021, at 1:19 PM, Norman Jaffe via cctech
 wrote:
> 
> 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. 

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

Re: Early Programming Books

[ben via cctalk]

On 2021-06-21 1:05 a.m., Van Snyder via cctalk wrote:


When I was teaching compiler classes, I liked Richard J. Le Blanc's
"Crafting a Compiler." I used Waite and Goos once. It was precise but a
bit too terse for the students. The compiler structure I taught was
based upon work of Frank de Remer and Tom Pennello, but their book
"Compiler Construction by Hand and by Tool" never saw print. Frank de
Remer simplified LR with its potentially exponential growth, to SLR and
LALR in his MIT Ph.D. thesis. Yacc (written by Robert Corbett, still a
denizen of the Fortran committees) is a LALR parser generator. I use
the generator written by Al Shannon when he was Charlie Wetherell's
student, now updated, which implements David Pager's algorithm that
generates a parser that is LR where necessary and LALR or SLR or LR(0)
where possible.


But with all this computing science, they have yet to make a clean
meta compiler like Meta II, or Tree meta.

Re: Early Programming Books

[ben via cctalk]

On 2021-06-21 12:06 a.m., Chuck Guzis via cctalk wrote:

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.


I have 'borrowed' copy of the Green dragon book.
The book promotes code generation for a multi register machine. PDP 11,
PDP 10, IBM 360. "(C) Bell Labs 1979 " I think is big hint here.

The machine model I am looking at is a single accumulator design like 
the 6800 or the IBM 1130. A AC,PC,Index and stack. No push or pop, 
subroutine call returns the old pc in the AC.




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.


Is Fortran the newer version of FORTRAN ( I II IV )?



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


There is very little to to bootstrap with today, that uses a small 
amount of memory.I need a cross compiler for my machine like K C

style compiler ,not the latest C+-#@? compiler.
I have no problem with a recursive decent compiler,I just have subtract
divide and mod reversed in places, something I want to avoid as well a
DISPLAY's like in Algol or Pascal.



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.


The machine works on FPGA delopment card, see the bliking lights on the
kitchen table. No hypothetical here.

1) Computer Check
2) Front panel  Check
3) Bootstrap  loader Check
4) Software No Check
Stage 4 is the problem.



For whatever an old man's story is worth...

--Chuck

Thanks.
Ben.

Re: Early Programming Books

[Peter Corlett via cctalk]

On Sun, Jun 20, 2021 at 08:06:26PM -0600, ben via cctalk wrote:
[...]
> My latest gripe, is I still am looking for a algorithm to generate code
> for a single accumulator machine for an arithmetic expression. 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

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.

RE: Early Programming Books

[Paul Birkel via cctalk]

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-boun...@classiccmp.org] On Behalf Of Paul Koning
via cctech
Sent: Sunday, June 20, 2021 4:58 PM
To: Norman Jaffe; cctalk@classiccmp.org
Cc: General Discussion, On-Topic Posts Only
Subject: Re: Early Programming Books

> Begin forwarded message:
> 
> From: Norman Jaffe via cctalk 
> Subject: Re: Early Programming Books
> Date: June 20, 2021 at 10:26:27 AM EDT
> To: "General Discussion, On-Topic Posts Only" 
> Reply-To: Norman Jaffe , "General Discussion: On-Topic and
Off-Topic Posts" 
> 
> 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 

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

RE: Early Programming Books

[Paul Birkel via cctalk]

Thank you Michael, for both the pointer and the scan :-}.

 

From: Michael Mulhern [mailto:mich...@jongleur.co.uk] 
Sent: Sunday, June 20, 2021 11:22 PM
To: Paul Birkel; General Discussion: On-Topic Posts
Subject: Re: Early Programming Books

 

I recently scanned my copy of "Electronic Computers: Principles and 
Applications" by TE. Ivall (1956) and there is a chapter on "Programming 
Digital Computers".  It is more of a general overview, rather than any machine 
specifics.

 

https://archive.org/details/electronic-computers/page/183/mode/2up 

 

The book also covers analogue computers for any interested.

 

//m

RE: Early Programming Books

[Paul Birkel via cctalk]

Sounds very promising, thank you for the tip.

-Original Message-
From: dave.g4...@gmail.com [mailto:dave.g4...@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

RE: Early Programming Books

[Paul Birkel via cctalk]

Thanks Bill.  Presume that you mean “Giant Brains, or Machines that Think” 
(1949)?  Conveniently scanned and online:

 

https://monoskop.org/images/b/bc/Berkeley_Edmund_Callis_Giant_Brains_or_Machines_That_Think.pdf
 

 

From: Bill Degnan [mailto:billdeg...@gmail.com] 
Sent: Sunday, June 20, 2021 3:31 PM
To: Paul Birkel; General Discussion: On-Topic Posts
Subject: Re: Early Programming Books

 

Paul,

I have been compiling a library of such. Ioks here, if you are traveling north 
swing by to review the books on hand.  The one that comes to mind is Thinking 
Machunrs by Berkeley but here on the patio at my parents house I dont know the 
date.  Harvard press put out some early computing books but they may be Mark 
1-specific.  Remind me and I can check when I get to the office.

Bill

Kennettclasic.com

Re: Early Programming Books

[Chuck Guzis via cctalk]

On 6/20/21 11:48 PM, Van Snyder via cctalk wrote:

> You also might like 
> https://www.cs.sjsu.edu/~mak/CMPE152/IBM1401FORTRANCompiler.pdf "Serial
> Compilation and the IBM 1401 FORTRAN Compiler."
> 1401-FO-050 was more than FORTRAN I but less than FORTRAN II.
> The innovation was interesting

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

Re: Early Programming Books

[Van Snyder via cctalk]

On Sun, 2021-06-20 at 23:13 -0700, Chuck Guzis via cctalk wrote:
> 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.

When I was teaching compiler classes, I liked Richard J. Le Blanc's
"Crafting a Compiler." I used Waite and Goos once. It was precise but a
bit too terse for the students. The compiler structure I taught was
based upon work of Frank de Remer and Tom Pennello, but their book
"Compiler Construction by Hand and by Tool" never saw print. Frank de
Remer simplified LR with its potentially exponential growth, to SLR and
LALR in his MIT Ph.D. thesis. Yacc (written by Robert Corbett, still a
denizen of the Fortran committees) is a LALR parser generator. I use
the generator written by Al Shannon when he was Charlie Wetherell's
student, now updated, which implements David Pager's algorithm that
generates a parser that is LR where necessary and LALR or SLR or LR(0)
where possible.

> 
> --Chuck

Re: Early Programming Books

[Van Snyder via cctalk]

On Sun, 2021-06-20 at 23:06 -0700, Chuck Guzis via cctalk wrote:
> 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
> prettygood for the time.  Missing a comma in a computed GOTO?  There
> was anerror message that directly addressed this error.
> Back when I was still in the business of writing compilers, the
> "DragonBook" ("Compilers: Principles, Techniques and Tools", Aho,
> Sethi;Ullman) was the standard reference.   I don't know if it still
> is.  Theearlier book by Saul Rosen is also pretty good.
> FORTRAN (as opposed to Fortran) is somewhat odd lexically when
> comparedwith other languages.  There are no reserved words, there is
> no conceptof whitespace (except in Hollerith constants) and
> combinations ofEQUIVALENCE and COMMON have sent many a compiler
> designer to tipple.

You also might like 
https://www.cs.sjsu.edu/~mak/CMPE152/IBM1401FORTRANCompiler.pdf "Serial
Compilation and the IBM 1401 FORTRAN Compiler."
1401-FO-050 was more than FORTRAN I but less than FORTRAN II.
The innovation was interesting. The first overlay read the program into
core. The next 62 gradually massaged it into executabe form. No
auxiliary storage -- tape or disk -- was used. The compiler would run
from cards (a bit more than one full box) or tape. There's a video of
it running at CHM on https://www.youtube.com/watch?v=uFQ3sajIdaM.
Fortran 2020 is rather different from FORTRAN I. There are still no
reserved words, but blanks are significant so you can't put them within
a variable, constant, keyword, or operator. But a blank is optional
within some keywords, such as ENDIF is allowed instead of END IF. It's
also a modern language. FORTRAN 77 was criticized for not providing
dynamic memory and structured data types. Those were included in
Fortran 90, along with modules,explicit interfaces, significant blanks,
free-form input Fortran 2003 added object-oriented programming,
based on the SIMULA model, C interoperability,  Fortran 2008 added
a much simpler SPMD parallel programming model, called coarrays -- much
easier to use than PVM or MPI.
> But there are lots of ways to skin the proverbial cat.  When I had
> toproduce an extended BASIC compiler for the 8085 using only a
> floppy-diskMDS 800 system, I adopted a technique I learned from an
> old IBM COMTRANcompiler guru.   Lay out the semantics of your
> compiler; lexicalelements, their characteristics, etc. and then think
> of them as tokensfor a hypothetical machine that takes as input
> lexical elements andproduces some sort of code as output.  Initially,
> my exposure to thistechnique was in a COBOL dialect translator--you
> took more or lessstandard COBOL as input and produced bastardized
> COBOL as output.
> You design the instruction set of your hypothetical machine, then
> eitherinterpret it or use those instructions to produce macro
> calls.  ASM80 onISIS II had a relatively weak macro facility, so we
> wrote the macroprocessor in PL/M.  Worked like a charm--in 4 months
> we had a workingcompiler.  I still have the design paper that I wrote
> for it.
> For whatever an old man's story is worth...
> --Chuck

Re: Early Programming Books

[Michael Mulhern via cctalk]

I recently scanned my copy of "Electronic Computers: Principles and
Applications" by TE. Ivall (1956) and there is a chapter on "Programming
Digital Computers".  It is more of a general overview, rather than any
machine specifics.

https://archive.org/details/electronic-computers/page/183/mode/2up

The book also covers analogue computers for any interested.

//m


*Blog: RetroRetrospective – Fun today with yesterday's gear……..
*
*Podcast*: *Retro Computing Roundtable * (Co-Host)


On Sun, 20 Jun 2021 at 18:44, Paul Birkel via cctech 
wrote:

> I know of two early computer (in the stored program sense) programming
> books.
>
>
>
> 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
>
> 1957: Digital Computer Programming (McCracken)
>
>
>
> What others were published prior to the McCracken text?
>
>
>
> Excluded are lecture compendia and symposia proceedings, such as:
>
>
>
> 1946: Moore School Lectures
>
> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
>
> 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
>
> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
>
>
>
> These were principally about designs for, and experience with, new
> hardware.
>
>
>
> I'm curious about texts specifically focused on the act of programming.
> Were there others prior to McCracken?
>
>
>
> paul
>
>
>
>

Re: Early Programming Books

[Brent Hilpert via cctalk]

On 2021-Jun-20, at 7:38 PM, ben via cctech wrote:
> On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:
> 
>> Tried the Shunting Yard algorithm? But watch out, it was invented by a
>> quiche eater...
> 
> The problem needs backtracking to generate correct code. Stack or 
> muilti-register machines don't have this problem with temporaries.
> Ben.

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.

Re: Early Programming Books

[ben via cctalk]

On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:


Tried the Shunting Yard algorithm? But watch out, it was invented by a
quiche eater...


The problem needs backtracking to generate correct code. Stack or 
muilti-register machines don't have this problem with temporaries.

Ben.

Re: Early Programming Books

[Toby Thain via cctalk]

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:
>>> Dave;
>>>
>>> I'm much more curious about programming books that were *not* machine
>>> specific.
>>> That is, about "general principles" of designing/preparing software for
>>> execution.
>>
>> 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
>>> books
>>> 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
>> interested.
>>
>> --Toby
> 
> 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
quiche eater...

> 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
> Ben.
> 
> 
> 

Re: Early Programming Books

[ben via cctalk]

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:

Dave;

I'm much more curious about programming books that were *not* machine
specific.
That is, about "general principles" of designing/preparing software for
execution.


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 books
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
interested.

--Toby


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
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.
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

Ben.

Re: Early Programming Books

[Paul McJones via cctalk]

1955: An Introduction to Automatic Computers (Ned Chapin 
)

I have the second edition — copyright 1963. Chapter 8 is “Elements of 
Programming” with a fully-worked out assembly language example for a 
hypothetical machine.


> Date: Sun, 20 Jun 2021 04:43:58 -0400
> From: "Paul Birkel" mailto:pbir...@gmail.com>>
> 
> I know of two early computer (in the stored program sense) programming
> books.
> 
>1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
> 
>1957: Digital Computer Programming (McCracken)
> 
> What others were published prior to the McCracken text?

Re: Early Programming Books

[Van Snyder via cctalk]

On Sun, 2021-06-20 at 04:43 -0400, Paul Birkel via cctech wrote:
> I know of two early computer (in the stored program sense) programming
> books.

Not about early EARLY programming, but I have some books (manuals) that
are yours if you send me a PDF of a shipping label for a 10"x12" 1lb
2oz envelope (media rate might be less expensive than first class):

   1. 68000 Microprocessor Handbook, Gerry Kane, Osborne / McGraw-Hill (1981) 
ISBN 0-931988-41-1
   2. MC68901 Multi-Function Peripheral, Motorola, ADI-984 (Jan. 1984)
   3. MC68881 Floating-Point Coprocessor as a Peripheral in an MC68000 System, 
Motorola AN947 (1987)
   4. HCMOS Floating-Point Coprocessor: MC68881 Technical Summary, Motorola 
BR265/D Rev.1 (1986)

Van Snyder
van.sny...@sbcglobal.net

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 20, 2021, at 1:19 PM, Norman Jaffe via cctech  
> wrote:
> 
> 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. 

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

Re: Early Programming Books

[Fred Cisin via cctalk]

On Sun, 20 Jun 2021, Bill Degnan via cctech wrote:

Paul,
I have been compiling a library of such. Ioks here, if you are traveling
north swing by to review the books on hand.  The one that comes to mind is
Thinking Machunrs by Berkeley but here on the patio at my parents house I
dont know the date.  Harvard press put out some early computing books but
they may be Mark 1-specific.  Remind me and I can check when I get to the
office.
Bill
Kennettclasic.com


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 ci...@xenosoft.com

RE: Early Programming Books

[Dave Wade G4UGM via cctalk]

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

> -Original Message-
> From: Paul Birkel 
> Sent: 20 June 2021 13:40
> To: dave.g4...@gmail.com; 'General Discussion: On-Topic Posts'
> 
> Subject: RE: Early Programming Books
> 
> Dave;
> 
> I'm much more curious about programming books that were *not* machine
> specific.
> That is, about "general principles" of designing/preparing software for
> execution.
> 
> 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 books
> specifically about programming in ALGOL 58.  I presume that there were
> eventually such books for ALGOL 60.
> 
> Then there's FORTRAN, in which context I first encountered McCracken
> (1961:
> Guide to FORTRAN Programming).
> 
> Obviously my first example was EDSAC-centric.  And yours is specific to
the
> Manchester MK1.
> 
> -Original Message-
> From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com]
> Sent: Sunday, June 20, 2021 6:57 AM
> To: 'Paul Birkel'; 'General Discussion: On-Topic Posts'
> Subject: RE: Early Programming Books
> 
> Paul,
> What about machine specific manuals, so for example the Manchester MK1
> programming manual, the second edition of which is archived here:-
> 
> https://web.archive.org/web/20090526192456/http://www.computer50.org
> /kgill/m
> ark1/progman.html
> 
> In fact I expect that first book refers specifically to EDSAC, so is in
effect
> machine specific. There must have been similar manuals for other machines?
> 
> I know there is a Ferranti Pegasus Programming manual, the copy I have is
> dated 1962 but as the last Pegasus was produced in 1959 there must have
> been earlier editions.
> 
> Dave
> 
> > -Original Message-----
> > From: cctech  On Behalf Of Paul Birkel
> > via cctech
> > Sent: 20 June 2021 09:44
> > To: 'General Discussion: On-Topic Posts' 
> > Subject: Early Programming Books
> >
> > I know of two early computer (in the stored program sense) programming
> > books.
> >
> > 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
> > 1957: Digital Computer Programming (McCracken)
> >
> > What others were published prior to the McCracken text?
> >
> > Excluded are lecture compendia and symposia proceedings, such as:
> >
> > 1946: Moore School Lectures
> > 1947: Proceedings of a Symposium on Large-Scale Digital
> > Calculating
> Machinery
> > 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
> > 1953: Faster Than Thought, A Symposium On Digital Computing
> > Machines
> >
> > These were principally about designs for, and experience with, new
> hardware.
> >
> > I'm curious about texts specifically focused on the act of programming.
> > Were there others prior to McCracken?
> >
> > paul
> 

Re: Early Programming Books

[Bill Degnan via cctalk]

Paul,
I have been compiling a library of such. Ioks here, if you are traveling
north swing by to review the books on hand.  The one that comes to mind is
Thinking Machunrs by Berkeley but here on the patio at my parents house I
dont know the date.  Harvard press put out some early computing books but
they may be Mark 1-specific.  Remind me and I can check when I get to the
office.
Bill
Kennettclasic.com

On Sun, Jun 20, 2021, 4:44 AM Paul Birkel via cctech 
wrote:

> I know of two early computer (in the stored program sense) programming
> books.
>
>
>
> 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
>
> 1957: Digital Computer Programming (McCracken)
>
>
>
> What others were published prior to the McCracken text?
>
>
>
> Excluded are lecture compendia and symposia proceedings, such as:
>
>
>
> 1946: Moore School Lectures
>
> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
>
> 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
>
> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
>
>
>
> These were principally about designs for, and experience with, new
> hardware.
>
>
>
> I'm curious about texts specifically focused on the act of programming.
> Were there others prior to McCracken?
>
>
>
> paul
>
>
>
>

Re: Early Programming Books

[Bill Degnan via cctalk]

Very good question!
Bill

On Sun, Jun 20, 2021, 4:44 AM Paul Birkel via cctech 
wrote:

> I know of two early computer (in the stored program sense) programming
> books.
>
>
>
> 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
>
> 1957: Digital Computer Programming (McCracken)
>
>
>
> What others were published prior to the McCracken text?
>
>
>
> Excluded are lecture compendia and symposia proceedings, such as:
>
>
>
> 1946: Moore School Lectures
>
> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
>
> 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
>
> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
>
>
>
> These were principally about designs for, and experience with, new
> hardware.
>
>
>
> I'm curious about texts specifically focused on the act of programming.
> Were there others prior to McCracken?
>
>
>
> paul
>
>
>
>

Re: Early Programming Books

[Chuck Guzis via cctalk]

Going back to the time around 1960, I'd like to venture the opinion that
most data processing of the time was performed with unit-record
equipment. That is, sorters, reproducing punches, interpreters,
accounting machines, etc., none of which were programmed by "software",
but by wiring plugboards or selecting operation from fixed controls.

Perhaps there were instructional tests in that area.   After all, card
sorters pretty much operate on the same principles.

--Chuck

Re: Early Programming Books

[Cory Heisterkamp via cctalk]

> On Jun 20, 2021, at 12:19 PM, Norman Jaffe via cctech  
> wrote:
> 
> 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"  
> To: "General Discussion, On-Topic Posts Only"  
> 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 

Don’t forget about Rem Rand’s Flow-Matic compiler language for Univac I & II.  
-C
http://www.bitsavers.org/pdf/univac/flow-matic/U1518_FLOW-MATIC_Programming_System_1958.pdf
 
<http://www.bitsavers.org/pdf/univac/flow-matic/U1518_FLOW-MATIC_Programming_System_1958.pdf>

Re: Early Programming Books

[Norman Jaffe via cctalk]

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"  
To: "General Discussion, On-Topic Posts Only"  
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 

Re: Early Programming Books

[Chuck Guzis via cctalk]

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

Re: Early Programming Books

[Gavin Scott via cctalk]

A few years later, but Iverson's A Programming Language (1962) was
written before APL was actually implemented and is all about a
symbolic mathematical notation for expressing operations. From the
preface via Wikipedia:

"Applied mathematics is largely concerned with the design and analysis
of explicit procedures for calculating the exact or approximate values
of various functions. Such explicit procedures are called algorithms
or programs. Because an effective notation for the description of
programs exhibits considerable syntactic structure, it is called a
programming language."

So I would definitely include it in the category of books you're asking about.

On Sun, Jun 20, 2021 at 3:44 AM Paul Birkel via cctech
 wrote:
>
> I know of two early computer (in the stored program sense) programming
> books.
>
>
>
> 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
>
> 1957: Digital Computer Programming (McCracken)
>
>
>
> What others were published prior to the McCracken text?
>
>
>
> Excluded are lecture compendia and symposia proceedings, such as:
>
>
>
> 1946: Moore School Lectures
>
> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
>
> 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
>
> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
>
>
>
> These were principally about designs for, and experience with, new hardware.
>
>
>
> I'm curious about texts specifically focused on the act of programming.
> Were there others prior to McCracken?
>
>
>
> paul
>
>
>

RE: Early Programming Books

[Paul Birkel via cctalk]

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.g4...@gmail.com [mailto:dave.g4...@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.)





> -Original Message-
> From: Paul Birkel 
> Sent: 20 June 2021 13:40
> To: dave.g4...@gmail.com; 'General Discussion: On-Topic Posts'
> 
> Subject: RE: Early Programming Books
> 
> Dave;
> 
> I'm much more curious about programming books that were *not* machine
> specific.
> That is, about "general principles" of designing/preparing software for
> execution.
> 
> 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 books
> specifically about programming in ALGOL 58.  I presume that there were
> eventually such books for ALGOL 60.
> 
> Then there's FORTRAN, in which context I first encountered McCracken
> (1961:
> Guide to FORTRAN Programming).
> 
> Obviously my first example was EDSAC-centric.  And yours is specific to
the
> Manchester MK1.
> 
> -Original Message-
> From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com]
> Sent: Sunday, June 20, 2021 6:57 AM
> To: 'Paul Birkel'; 'General Discussion: On-Topic Posts'
> Subject: RE: Early Programming Books
> 
> Paul,
> What about machine specific manuals, so for example the Manchester MK1
> programming manual, the second edition of which is archived here:-
> 
> https://web.archive.org/web/20090526192456/http://www.computer50.org
> /kgill/m
> ark1/progman.html
> 
> In fact I expect that first book refers specifically to EDSAC, so is in
effect
> machine specific. There must have been similar manuals for other machines?
> 
> I know there is a Ferranti Pegasus Programming manual, the copy I have is
> dated 1962 but as the last Pegasus was produced in 1959 there must have
> been earlier editions.
> 
> Dave
> 
> > -Original Message-----
> > From: cctech  On Behalf Of Paul Birkel
> > via cctech
> > Sent: 20 June 2021 09:44
> > To: 'General Discussion: On-Topic Posts' 
> > Subject: Early Programming Books
> >
> > I know of two early computer (in the stored program sense) programming
> > books.
> >
> > 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
> > 1957: Digital Computer Programming (McCracken)
> >
> > What others were published prior to the McCracken text?
> >
> > Excluded are lecture compendia and symposia proceedings, such as:
> >
> > 1946: Moore School Lectures
> > 1947: Proceedings of a Symposium on Large-Scale Digital
> > Calculating
> Machinery
> > 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
> > 1953: Faster Than Thought, A Symposium On Digital Computing
> > Machines
> >
> > These were principally about designs for, and experience with, new
> hardware.
> >
> > I'm curious about texts specifically focused on the act of programming.
> > Were there others prior to McCracken?
> >
> > paul
> 

Re: Early Programming Books

[Chuck Guzis via cctalk]

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

Re: Early Programming Books

[Chuck Guzis via cctalk]

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

Re: Early Programming Books

[Brent Hilpert via cctalk]

On 2021-Jun-20, at 9:19 PM, ben via cctalk wrote:
> On 2021-06-20 9:01 p.m., Brent Hilpert via cctalk wrote:
>> On 2021-Jun-20, at 7:38 PM, ben via cctech wrote:
>>> On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:
>>> 
 Tried the Shunting Yard algorithm? But watch out, it was invented by a
 quiche eater...
>>> 
>>> The problem needs backtracking to generate correct code. Stack or 
>>> muilti-register machines don't have this problem with temporaries.
>>> Ben.
>> 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.
> 
> Computer science people seem to like to brag about how to parse.

Whatever that means.

> Walking a tree does not solve the tree was built in the wrong order.
 
No. If the tree was built in the "wrong order", then you screwed up in writing 
your parser.
There is no great difficulty in parsing into a tree representation which can be 
walked to resolve your initial issue.

> Parenthesis first implies input string re-scanning and text movement.

Whatever that means.
You don't have to "move text" to accomplish this.

> This what I can't seem to find a good algorithm for.

In summary fashion, I told you how it's done.
If you don't understand state machines and parsing that's your problem.

As it is, you are running into the same issue a thousand minicomputer & 
microproc manufacturers and designers ran into in the 60/70s: building and 
maintaining the support ecosystem for a machine architecture is not trivial.


But I should know better than to bother.



> 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.

Re: Early Programming Books

[ben via cctalk]

On 2021-06-20 9:01 p.m., Brent Hilpert via cctalk wrote:

On 2021-Jun-20, at 7:38 PM, ben via cctech wrote:

On 2021-06-20 8:13 p.m., Toby Thain via cctech wrote:


Tried the Shunting Yard algorithm? But watch out, it was invented by a
quiche eater...


The problem needs backtracking to generate correct code. Stack or 
muilti-register machines don't have this problem with temporaries.
Ben.



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.


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.

Re: Early Programming Books

[Paul Koning via cctalk]

> Begin forwarded message:
> 
> From: Norman Jaffe via cctalk 
> Subject: Re: Early Programming Books
> Date: June 20, 2021 at 10:26:27 AM EDT
> To: "General Discussion, On-Topic Posts Only" 
> Reply-To: Norman Jaffe , "General Discussion: On-Topic and 
> Off-Topic Posts" 
> 
> 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 

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

Re: Early Programming Books

[Paul Koning via cctalk]

> On Jun 20, 2021, at 4:43 AM, Paul Birkel via cctalk  
> wrote:
> 
> I know of two early computer (in the stored program sense) programming
> books.
> 
>1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
> 
>1957: Digital Computer Programming (McCracken)
> 
> What others were published prior to the McCracken text?
> 
> Excluded are lecture compendia and symposia proceedings, such as:
> 
>1946: Moore School Lectures
> 
>1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
> 
>1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
> 
>1953: Faster Than Thought, A Symposium On Digital Computing Machines
> 
> These were principally about designs for, and experience with, new hardware.

There are several Dutch ones that are interesting, available from the on-line 
document collection of the CWI (then MC -- Mathematical Center).   The oldest I 
know is from February 1948, "Principles of electronic calculating machines" 
(report CR3), by A. van Wijngaarden.  Much of it is about computer hardware and 
architecture, but the back part covers programming.  

Next is "Programming the A.R.R.A.", (MR7) also by A. van Wijngaarden, 1951.  
And an interesting one, "Functional description of the ARRA" (MR12), by E. W. 
Dijkstra, 1953.  That's a very early example of a document giving a 
programmer's view of a computer, rather than a EE's view -- so it describes the 
instruction set, I/O mechanisms, library functions available, etc. -- but not 
the details of the implementation.

Along the same lines are "Handbook for the programmer -- FERTA" (in two parts, 
MR17 and MR20), 1955, also by Dijkstra.  

There are a bunch more along the same lines, probably nearly unknown partly 
because they describe one-off lab machines (except for FERTA, which is a copy 
of ARRA that was built by the lab for Fokker aircraft corporation and there was 
used for aerodynamic CAD work).  The fact that they are all in Dutch obviously 
doesn't help...

paul

RE: Early Programming Books

[Paul Birkel via cctalk]

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-boun...@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"  
To: "Paul Birkel" , "General Discussion, On-Topic Posts 
Only" , "dave g4ugm"  
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: 
> Dave; 
> 
> I'm much more curious about programming books that were *not* machine 
> specific. 
> That is, about "general principles" of designing/preparing software for 
> execution. 

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 books 
> 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 
interested. 

--Toby 

> 
> Then there's FORTRAN, in which context I first encountered McCracken (1961: 
> Guide to FORTRAN Programming). 
> 
> Obviously my first example was EDSAC-centric. And yours is specific to the 
> Manchester MK1. 
> 
> -Original Message- 
> From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com] 
> Sent: Sunday, June 20, 2021 6:57 AM 
> To: 'Paul Birkel'; 'General Discussion: On-Topic Posts' 
> Subject: RE: Early Programming Books 
> 
> Paul, 
> What about machine specific manuals, so for example the Manchester MK1 
> programming manual, the second edition of which is archived here:- 
> 
> https://web.archive.org/web/20090526192456/http://www.computer50.org/kgill/m 
> ark1/progman.html 
> 
> In fact I expect that first book refers specifically to EDSAC, so is in 
> effect machine specific. There must have been similar manuals for other 
> machines? 
> 
> I know there is a Ferranti Pegasus Programming manual, the copy I have is 
> dated 1962 but as the last Pegasus was produced in 1959 there must have been 
> earlier editions. 
> 
> Dave 
> 
>> -Original Message- 
>> From: cctech  On Behalf Of Paul Birkel via 
>> cctech 
>> Sent: 20 June 2021 09:44 
>> To: 'General Discussion: On-Topic Posts'  
>> Subject: Early Programming Books 
>> 
>> I know of two early computer (in the stored program sense) programming 
>> books. 
>> 
>> 1951: Preparation of Programs for an Electronic Digital Computer 
> (Wilkes, Wheeler, & Gill) 
>> 1957: Digital Computer Programming (McCracken) 
>> 
>> What others were published prior to the McCracken text? 
>> 
>> Excluded are lecture compendia and symposia proceedings, such as: 
>> 
>> 1946: Moore School Lectures 
>> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating 
> Machinery 
>> 1951: Proceedings of a Second Symposium on Large-Scale Digital 
> Calculating Machinery 
>> 1953: Faster Than Thought, A Symposium On Digital Computing Machines 
>> 
>> These were principally about designs for, and experience with, new 
> hardware. 
>> 
>> I'm curious about texts specifically focused on the act of programming. 
>> Were there others prior to McCracken? 
>> 
>> paul 
> 
> 

RE: Early Programming Books

[Dave Wade G4UGM via cctalk]

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.)





> -Original Message-
> From: Paul Birkel 
> Sent: 20 June 2021 13:40
> To: dave.g4...@gmail.com; 'General Discussion: On-Topic Posts'
> 
> Subject: RE: Early Programming Books
> 
> Dave;
> 
> I'm much more curious about programming books that were *not* machine
> specific.
> That is, about "general principles" of designing/preparing software for
> execution.
> 
> 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 books
> specifically about programming in ALGOL 58.  I presume that there were
> eventually such books for ALGOL 60.
> 
> Then there's FORTRAN, in which context I first encountered McCracken
> (1961:
> Guide to FORTRAN Programming).
> 
> Obviously my first example was EDSAC-centric.  And yours is specific to
the
> Manchester MK1.
> 
> -Original Message-
> From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com]
> Sent: Sunday, June 20, 2021 6:57 AM
> To: 'Paul Birkel'; 'General Discussion: On-Topic Posts'
> Subject: RE: Early Programming Books
> 
> Paul,
> What about machine specific manuals, so for example the Manchester MK1
> programming manual, the second edition of which is archived here:-
> 
> https://web.archive.org/web/20090526192456/http://www.computer50.org
> /kgill/m
> ark1/progman.html
> 
> In fact I expect that first book refers specifically to EDSAC, so is in
effect
> machine specific. There must have been similar manuals for other machines?
> 
> I know there is a Ferranti Pegasus Programming manual, the copy I have is
> dated 1962 but as the last Pegasus was produced in 1959 there must have
> been earlier editions.
> 
> Dave
> 
> > -Original Message-----
> > From: cctech  On Behalf Of Paul Birkel
> > via cctech
> > Sent: 20 June 2021 09:44
> > To: 'General Discussion: On-Topic Posts' 
> > Subject: Early Programming Books
> >
> > I know of two early computer (in the stored program sense) programming
> > books.
> >
> > 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
> > 1957: Digital Computer Programming (McCracken)
> >
> > What others were published prior to the McCracken text?
> >
> > Excluded are lecture compendia and symposia proceedings, such as:
> >
> > 1946: Moore School Lectures
> > 1947: Proceedings of a Symposium on Large-Scale Digital
> > Calculating
> Machinery
> > 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
> > 1953: Faster Than Thought, A Symposium On Digital Computing
> > Machines
> >
> > These were principally about designs for, and experience with, new
> hardware.
> >
> > I'm curious about texts specifically focused on the act of programming.
> > Were there others prior to McCracken?
> >
> > paul
> 

Re: Early Programming Books

[Norman Jaffe via cctalk]

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"  
To: "Paul Birkel" , "General Discussion, On-Topic Posts 
Only" , "dave g4ugm"  
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: 
> Dave; 
> 
> I'm much more curious about programming books that were *not* machine 
> specific. 
> That is, about "general principles" of designing/preparing software for 
> execution. 

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 books 
> 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 
interested. 

--Toby 

> 
> Then there's FORTRAN, in which context I first encountered McCracken (1961: 
> Guide to FORTRAN Programming). 
> 
> Obviously my first example was EDSAC-centric. And yours is specific to the 
> Manchester MK1. 
> 
> -Original Message- 
> From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com] 
> Sent: Sunday, June 20, 2021 6:57 AM 
> To: 'Paul Birkel'; 'General Discussion: On-Topic Posts' 
> Subject: RE: Early Programming Books 
> 
> Paul, 
> What about machine specific manuals, so for example the Manchester MK1 
> programming manual, the second edition of which is archived here:- 
> 
> https://web.archive.org/web/20090526192456/http://www.computer50.org/kgill/m 
> ark1/progman.html 
> 
> In fact I expect that first book refers specifically to EDSAC, so is in 
> effect machine specific. There must have been similar manuals for other 
> machines? 
> 
> I know there is a Ferranti Pegasus Programming manual, the copy I have is 
> dated 1962 but as the last Pegasus was produced in 1959 there must have been 
> earlier editions. 
> 
> Dave 
> 
>> -Original Message- 
>> From: cctech  On Behalf Of Paul Birkel via 
>> cctech 
>> Sent: 20 June 2021 09:44 
>> To: 'General Discussion: On-Topic Posts'  
>> Subject: Early Programming Books 
>> 
>> I know of two early computer (in the stored program sense) programming 
>> books. 
>> 
>> 1951: Preparation of Programs for an Electronic Digital Computer 
> (Wilkes, Wheeler, & Gill) 
>> 1957: Digital Computer Programming (McCracken) 
>> 
>> What others were published prior to the McCracken text? 
>> 
>> Excluded are lecture compendia and symposia proceedings, such as: 
>> 
>> 1946: Moore School Lectures 
>> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating 
> Machinery 
>> 1951: Proceedings of a Second Symposium on Large-Scale Digital 
> Calculating Machinery 
>> 1953: Faster Than Thought, A Symposium On Digital Computing Machines 
>> 
>> These were principally about designs for, and experience with, new 
> hardware. 
>> 
>> I'm curious about texts specifically focused on the act of programming. 
>> Were there others prior to McCracken? 
>> 
>> paul 
> 
> 

Re: Early Programming Books

[Toby Thain via cctalk]

On 2021-06-20 1:39 p.m., Paul Birkel via cctech wrote:
> Dave;
> 
> I'm much more curious about programming books that were *not* machine
> specific.
> That is, about "general principles" of designing/preparing software for
> execution.

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 books
> 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
interested.

--Toby

> 
> Then there's FORTRAN, in which context I first encountered McCracken (1961:
> Guide to FORTRAN Programming).
> 
> Obviously my first example was EDSAC-centric.  And yours is specific to the
> Manchester MK1.
> 
> -Original Message-
> From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com] 
> Sent: Sunday, June 20, 2021 6:57 AM
> To: 'Paul Birkel'; 'General Discussion: On-Topic Posts'
> Subject: RE: Early Programming Books
> 
> Paul,
> What about machine specific manuals, so for example the Manchester MK1
> programming manual, the second edition of which is archived here:-
> 
> https://web.archive.org/web/20090526192456/http://www.computer50.org/kgill/m
> ark1/progman.html 
> 
> In fact I expect that first book refers specifically to EDSAC, so is in
> effect machine specific. There must have been similar manuals for other
> machines?
> 
> I know there is a Ferranti Pegasus Programming manual, the copy I have is
> dated 1962 but as the last Pegasus was produced in 1959 there must have been
> earlier editions.
> 
> Dave
> 
>> -Original Message-
>> From: cctech  On Behalf Of Paul Birkel via
>> cctech
>> Sent: 20 June 2021 09:44
>> To: 'General Discussion: On-Topic Posts' 
>> Subject: Early Programming Books
>>
>> I know of two early computer (in the stored program sense) programming
>> books.
>>
>> 1951: Preparation of Programs for an Electronic Digital Computer
> (Wilkes, Wheeler, & Gill)
>> 1957: Digital Computer Programming (McCracken)
>>
>> What others were published prior to the McCracken text?
>>
>> Excluded are lecture compendia and symposia proceedings, such as:
>>
>> 1946: Moore School Lectures
>> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
>> 1951: Proceedings of a Second Symposium on Large-Scale Digital
> Calculating Machinery
>> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
>>
>> These were principally about designs for, and experience with, new
> hardware.
>>
>> I'm curious about texts specifically focused on the act of programming.
>> Were there others prior to McCracken?
>>
>> paul
> 
> 

RE: Early Programming Books

[Paul Birkel via cctalk]

Dave;

I'm much more curious about programming books that were *not* machine
specific.
That is, about "general principles" of designing/preparing software for
execution.

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 books
specifically about programming in ALGOL 58.  I presume that there were
eventually such books for ALGOL 60.

Then there's FORTRAN, in which context I first encountered McCracken (1961:
Guide to FORTRAN Programming).

Obviously my first example was EDSAC-centric.  And yours is specific to the
Manchester MK1.

-Original Message-
From: dave.g4...@gmail.com [mailto:dave.g4...@gmail.com] 
Sent: Sunday, June 20, 2021 6:57 AM
To: 'Paul Birkel'; 'General Discussion: On-Topic Posts'
Subject: RE: Early Programming Books

Paul,
What about machine specific manuals, so for example the Manchester MK1
programming manual, the second edition of which is archived here:-

https://web.archive.org/web/20090526192456/http://www.computer50.org/kgill/m
ark1/progman.html 

In fact I expect that first book refers specifically to EDSAC, so is in
effect machine specific. There must have been similar manuals for other
machines?

I know there is a Ferranti Pegasus Programming manual, the copy I have is
dated 1962 but as the last Pegasus was produced in 1959 there must have been
earlier editions.

Dave

> -Original Message-
> From: cctech  On Behalf Of Paul Birkel via
> cctech
> Sent: 20 June 2021 09:44
> To: 'General Discussion: On-Topic Posts' 
> Subject: Early Programming Books
> 
> I know of two early computer (in the stored program sense) programming
> books.
> 
> 1951: Preparation of Programs for an Electronic Digital Computer
(Wilkes, Wheeler, & Gill)
> 1957: Digital Computer Programming (McCracken)
> 
> What others were published prior to the McCracken text?
> 
> Excluded are lecture compendia and symposia proceedings, such as:
> 
> 1946: Moore School Lectures
> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
Machinery
> 1951: Proceedings of a Second Symposium on Large-Scale Digital
Calculating Machinery
> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
> 
> These were principally about designs for, and experience with, new
hardware.
> 
> I'm curious about texts specifically focused on the act of programming.
> Were there others prior to McCracken?
> 
> paul

RE: Early Programming Books

[Dave Wade G4UGM via cctalk]

Paul,
What about machine specific manuals, so for example the Manchester MK1
programming manual, the second edition of which is archived here:-

https://web.archive.org/web/20090526192456/http://www.computer50.org/kgill/m
ark1/progman.html

In fact I expect that first book refers specifically to EDSAC, so is in
effect machine specific. There must have been similar manuals for other
machines?
I know there is a Ferranti Pegasus Programming manual, the copy I have is
dated 1962 but as the last Pegasus was produced in 1959 there must have been
earlier editions.

Dave

> -Original Message-
> From: cctech  On Behalf Of Paul Birkel via
> cctech
> Sent: 20 June 2021 09:44
> To: 'General Discussion: On-Topic Posts' 
> Subject: Early Programming Books
> 
> I know of two early computer (in the stored program sense) programming
> books.
> 
> 
> 
> 1951: Preparation of Programs for an Electronic Digital Computer
(Wilkes,
> Wheeler, & Gill)
> 
> 1957: Digital Computer Programming (McCracken)
> 
> 
> 
> What others were published prior to the McCracken text?
> 
> 
> 
> Excluded are lecture compendia and symposia proceedings, such as:
> 
> 
> 
> 1946: Moore School Lectures
> 
> 1947: Proceedings of a Symposium on Large-Scale Digital Calculating
> Machinery
> 
> 1951: Proceedings of a Second Symposium on Large-Scale Digital
Calculating
> Machinery
> 
> 1953: Faster Than Thought, A Symposium On Digital Computing Machines
> 
> 
> 
> These were principally about designs for, and experience with, new
> hardware.
> 
> 
> 
> I'm curious about texts specifically focused on the act of programming.
> Were there others prior to McCracken?
> 
> 
> 
> paul
> 
> 

Early Programming Books

[Paul Birkel via cctalk]

I know of two early computer (in the stored program sense) programming
books.

 

1951: Preparation of Programs for an Electronic Digital Computer
(Wilkes, Wheeler, & Gill)

1957: Digital Computer Programming (McCracken)

 

What others were published prior to the McCracken text?

 

Excluded are lecture compendia and symposia proceedings, such as:

 

1946: Moore School Lectures

1947: Proceedings of a Symposium on Large-Scale Digital Calculating
Machinery

1951: Proceedings of a Second Symposium on Large-Scale Digital
Calculating Machinery

1953: Faster Than Thought, A Symposium On Digital Computing Machines

 

These were principally about designs for, and experience with, new hardware.

 

I'm curious about texts specifically focused on the act of programming.
Were there others prior to McCracken?

 

paul