The PC gets changed as an integral part of executing every instruction, so the speed-up you'd get from putting that in a fast hardware register could be more important than moving the accumulators into fast hardware. Doing the same for the CC register is also more important than moving the accumulators. Here's my basis for saying that:
- the PC register will be changed for every instruction, so gets accessed much more often (one read, one write per instruction executed)
- the CC register probably gets more accesses than any one accumulator because every conditional jump, loop instruction and arithmetic opcode reads it and some percentage of arithmetic opcodes write to it
- on average each accumulator gets accessed by approx 10% of instructions (less than 12.5% because not all instructions access an accumulator)
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
The 1900 was equally crufty. It also had no stack pointers and no dedicated subroutine call register either: A subroutine call at its most basic looked something like this:
LDA 4 #PARAMBLK [ pointer to arguments starting at PARAM JSR 3 MYSUB
which passed the pointer in accumulator 4 and left the return address in accumulator 3. Or, if arguments were under 24 bits you'd just put them in accumulators, Trivial example:
The 1900 was quite efficient at running COBOL (claimed 6 machine instructions per COBOL Procedure Division statement) but was less good at handling stack based languages like Algol60 or 68. I don't recall seeing even a mention of a Pascal compiler and the first C compiler was barely a gleam in Kernighan & Richie's eyes.
vectors
Neat!
instruction
The nearest to that I've got was the General Purpose MacroGenerator, which came out of Cambridge Uni and could, among many other things, be used as a fairly basic assembler.
And, of course, Lex & YACC which are wonderful once you get your head round them though you can only get C out of it.
However, CoCo/R is an even better: its a bit easier to use because both lexer and parser are parts of one program, so there's only one input syntax definition file to write, it is available written in several languages (C,C++,Java,Pascal, Python,...) generates code for the language it is written in, and if you don't like the template file for its output its trivial to write another.
If you have a need for this type of program, I'd say Coco/R is the one to go for.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
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.
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):
formatting link
It ran the Whetstone benchmark faster than the optimising FORTRAN compiler.
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.
--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Are you sure? When I joined ICL's service bureau in Wellington, NZ in
1968 FORTRAN and ALGOL 60 compilers were there and in use, but all out commercial stuff was written in PLAN3 and it wasn't until a couple of years later that the bureau staff learned COBOL en mass and started using it in place of PLAN. However, I don't know if the reason that we weren't using COBOL in 1968 was because we were behind the times or because ICL wasn't pushing it any earlier.
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
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.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.