Is it a lost cause?

But writing assembly language code for the ARM is not something a doctor, lawyer, or Indian chief needs to know. Knowing how to use one effectively in his day to day activities is another story.

That was true only of the 1901..1903 processors. More powerful processors had flip flop registers, but still addressable as words 0..8, rather like thePDP 10.

Ah, got it.

Nope. The system standard calling convention (multi-language compatible) looked like this, e.g.:

CALL 3 SUBR LDN 6 ADDRA LDX 6 VALUB

for a by-address parameter, LDN loaded its address for a by-value parameter, LDX loaded its value

It is not a mistake that they follow the CALL!

Inside SUBR, you get the address/value of parameter #n by executing:

OBEY #n-1(3)

this executed the n-th instruction following the CALL, and SUBR found the value it wanted in register 6.

This also worked well for Algol 60 call-by-name, as you would do the OBEY every time the name parameter is accessed. The instruction thus obeyed would call a "thunk".

In fact the world's second Pascal compiler was on the ICL1900, as well as one of the best (which I helped write):

It ran the Whetstone benchmark faster than the optimising FORTRAN compiler.

I'm not disagreeing with you. I am saying that the PC (and other context such as CC and accumulators) were NOT, in practice, stored in memory.

But on a context switch, that is where they were stored.

Exactly. And I suspect the PC was flip flop based in all machines.

(snip)

It was really designed for FORTRAN and COBOL, and stacks were in their infancy in the business environment.

GPM was very, very basic. To do it properly you need something a bit more powerful (not, NOT m4!).

'Son of GPM' has to be ML/I - which is still around (I confess a close association):

ML/I was developed 50 years ago and is still in use!

And these days, the GNU versions: Flex and Bison.

But those are not intending computer scientists, they are consumers

Depends what you mean by memory, which is I thought the whole point of the discussion. Registers *are* memory. Fast local memory. Before LSI it would likely as not been static RAM. Even a D type register is 'memory'.

The evolution of single chip processors, initially with onboard RAM for registers, later with onboard ROM for microcode, and latterly with onboard cache to shadow offboard DRAM is a story that can be read many ways.

We're in agreement. I thought you were saying that, when a program image became the active process accumulators were copied to hardware registers and saved back to the image when control was switched to another program image but you weren't certain whether the PC and CC registers were transferred with them. All I'm adding is that, if only some of theset (accumulators, PC and CC) were transferred, then it would be better to move PC and CC rather than the accumulators. If I've understood Denis correctly, that's more or less exactly the Sigma did, leaving the register bank as part of the program image unless it was an expanded machine with multiple hardware register banks.

Are you sure? When I joined ICL's service bureau in Wellington, NZ in

I know. I once implemented it in Algol 60 (because I had BCPL source and that was close enough to Algol to be a good choice). It worked OK, but wasn't exactly easy to use!

Never saw that.

Yes, I've used them too, but think Coco/R is a better choice.

That rings bells, and corrects my foggy memories in PLAN opcodes and syntax, so thanks. IIRC the last time I wrote PLAN was in 1976 on a 2903. The PLAN compiler was borrowed from ICL's NYC service bureau and patched to stop it halting 'WE' when run on a 2903. I was on an ICL contract job at the time.

Yes, I remember seeing that construct - and writing to it when we needed the call PLAN stuff from COBOL, but I don't remember using it in all-PLAN programs.

I didn't know that and never saw the Pascal compiler.

Try it....I am probably the world expert now!

You're splitting hairs. Let's use the terminology 'memory' for the large, immediately accessible memory that, in those days, was either core or (if you were lucky) MOS or similar.

Registers are in the CPU and a LOT faster. Just because the registers were associated with locations in that slower memory, doesn't mean they were actually stored in it (except at a context switch, perhaps). That's my point.

The advantage of making the memory system 'lie' and allow access to the registers as 'memory' is quite useful, though. I've seen tight loops copied to such registers and then executed.

Also the FreeBSD port maintainer I see.

PLAN is an Assembler. The ICL 1900's lack of a compare instruction suggest it was designed for FORTRAN II.

The machines aimed at doing real-time processing in addition to timeshating, batch etc. Except for the 360/44 IBM never (afaik) pursued this market for System/360 (computers from 1710 thru 1800 and System/7 were aimed there) Sigmas had multiple register banks so that you could have one dedicated to the OS, one for background, and still dedicate some to real-time tasks.

I never played much with the "meta" features of Meta-symbol. Off-topic I discovered that SDS originated Meta-symbol on 9-Series machines.

Correct -and that (plus a bit of FIND-2) is what we wrote commercial systems in at that time. These ranged from payrolls and accounts through a magazine wholesaler's delivery, billing and stock management system.

Why do you say that? The various conditional jump and looping instructions did all I needed them to do.

(digs out PLAN programming card from March 1965)

TXU (026) and TXL (027) look like comparison instructions to me.