lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) (07/20/88)
In article <2317@pt.cs.cmu.edu> lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes: > >The idea of storing a return address into the front word of a subroutine >was widespread. It would be nice to think that this rank stupidity died out >long ago, but in fact the HP 2100 series worked that way. (I believe it >went off the market in the 1980's.) I had the "pleasure" to maintain such a system during my previous existence as an engineer, in the early eghties. Our system had a whopping 96K 16-bit words primary memory and two disk drives of 5Mwords and 20Mwords, respectively. It was purchased sometimes in the late seventies for a sum I would guess was well above $20,000. (The system was used!) The software for this machine was, well, medieval. Some of the (mis)features of its operating system, RT-IVB, were: * It did have time-sharing, but the memory was statically partitioned and the only way to change the partitioning was to generate a new copy of the operating system! * Max address space for a program 64K. No virtual memory, so if you needed more then explicit segmentation with code overloading was the only way to go. * Dumb terminal drivers that didn't recognize ^S & ^Q, not to mention the nifty block transfer protocols their own 264x series terminals were capable of (which, amongst other things, made these terminals' function keys useless). * A contiguous-storage oriented file system that frequently lead to disk space fragmentation problems. Whenever that happened you had to switch to single-user mode and run a disk compaction program... * Much, much more, but I have occupied enough bandwidth with this already. I do have to mention, though, the listings of reported bugs that came every three months or so. A not too unusual comment after a bug report was: "this bug will not be fixed"! I guess HP didn't put in too much manpower into supporting this system. I also guess that they were right in not doing so... When I write this, using GNU emacs under Xwindows on a $4000 sun 3/50, I realize that things have gone the right way since my engineering days. Bjorn Lisper
kluft@hpcupt1.HP.COM (Ian Kluft) (07/21/88)
First a note: this is not a flame. (I don't flame if I can avoid it.) This message is additional information on the subject from a different point of view. The HP2100 became the HP1000 probably at least 10 years ago. The E- and F- series 1000's retained model numbers starting with 21, such as 21MX. I worked last Summer in HP1000 software support and got to see how the support works. I also took a class on Micorprogramming at CSU Chico this past Spring in which we used an HP1000E 21MX (of 1978 vintage). Anyway, the HP2100 software still runs on the 1000 as-is. But the 1000 was redesigned into the A-series in the mid 80's in order to maintain a lead in the real-time systems market. I'm not trying to be defensive of a system that, at the time, earned the comments Bjorn gave. It just sounded like he wanted to see improvement. Below are some places where what he wanted has been done. lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes: > * It did have time-sharing, but the memory was statically partitioned and > the only way to change the partitioning was to generate a new copy of the > operating system! > > * Max address space for a program 64K. No virtual memory, so if you needed > more then explicit segmentation with code overloading was the only way to > go. RTE-A (Real Time Executive, A-series) has multitasking, multiuser, and virtual memory. Yes, things have changed. > * Dumb terminal drivers that didn't recognize ^S & ^Q, not to mention the > nifty block transfer protocols their own 264x series terminals were > capable of (which, amongst other things, made these terminals' function > keys useless). My project last Summer was to work on additional docs for the multiplexer (8-port serial board). The dumb-terminal drivers are only included now for backward compatibility. The newer drivers have enough features that my "supplementary" documentation grew to 70 pages (including illustrations). > * A contiguous-storage oriented file system that frequently lead to > disk space fragmentation problems. Whenever that happened you had to > switch to single-user mode and run a disk compaction program... That sounds pretty familiar. I remember the disk compaction program but I didn't have fragmentation problems. I can't say for sure what, if anything, has changed in this area. They've made it look more like Unix in this respect. It has a heirarchical file system with a Unix-style shell. (If you're used to Unix, though, don't expect it to be identical. It's nice compared to the old FMGR but Unix gurus would be disappointed.) > [...] A not too unusual comment after a bug report was: "this > bug will not be fixed"! I guess HP didn't put in too much manpower into > supporting this system. I also guess that they were right in not doing so... I can think of a few circumstances where they might not want to fix something that will take forever to repair when a workaround is available. The main point here is that those people do care (I know, I worked with them) - they just have finite resourses, like the rest of us. However, they do have adequate manpower for most problems. ------------------------------------------------------------------ Ian Kluft RAS Lab UUCP: hplabs!hprasor!kluft HP Systems Technology Division ARPA: kluft@hpda.hp.com Cupertino, CA ------------------------------------------------------------------
hartman@hpcupt1.HP.COM (Doug Hartman) (07/28/88)
Re: 2100 architecture.
While recent descendents of this machine have stacks, reentrant
code, virtual memory, etc., there are some interesting trivia notes
about this machine.
Most people used Fortran or assembly (the Algol compiler notwithstanding;
it has acquired Pascal and ADA (!?) by now...), so they didn't notice
the lack of a stack too much. The Fortran compiler used to rely
on the fact that self modifying code was "cool". For example, a
typical two word instruction to load a 32 bit floating point
number looked like so:
octal address (in words) instruction word
2000 DLD (=105400 or something...)
2001 <fifteen bit address + indirect>
As a compiler, you have a couple of choices. You can
compute the address of an array element in a register, then use
the fact that the A register is address zero and the B register is
address 1 to get DLD A,I in assembly.
Or, you can put the address in a variable: STA PTR
DLD PTR,I
If you want to re-use the result of the address computation.
But this takes one more memory cycle than if the instruction
contained the direct address. The solution is obvious: STA *+2
DLD <anything>
This puts the address to load right in the instruction stream.
Makes pipelining fun...not that the machine was pipelined.
Other trivia notes: having only two registers tended to simplify the
procedure call convention and interrupt state save...:-). The register
set was not symmetric--you could only use the A register for the
boolean operations. No subtract, but you could XOR to anywhere on
the current page or page zero, possibly indirect, in one instruction...
The Fortran compiler didn't use the B register at all for the first
ten years of so. Teaching it about B improved performance about 3%,
mostly because the compiler didn't save any register allocation
information across statements. To set X and Y to zero you
would get CLA
STA X
CLA <just to be sure...>
STA Y
It would only get to B in certain "complex" expressions.
Later versions of the machine were heavily microcoded. Things like
move words (which saved the count of words moved in the instruction
stream in order to restart after interrupt), compare bytes, load
from 32 bit virtual address, up through extreme CISC-isms such as
DPOLY, which computed the Chebychev polynomial expansion given a
table of coefficents, a double precision vector instruction set
including "one instruction" pivot operations, and support for all of
the transcendantal instructions used by the Whetstone benchmark.
I wonder if anybody ever coded the hyperbolic tangent instruction
in assembly?
The machine held off interrupts for one cycle following a JMP indirect
to let you get out of the operating system "cleanly". Of course this
also let you loop forever with the right two JMP instructions. But
since the machine had infinite levels of indirect resolution, you could
get the same effect by doing a JMP *+1,I
DEF *,I
The multiply instructions assumed the B register held the most significant
bits. The 32 bit integer instructions assumed the A register did. THe
code generators produced a lot of SWP instructions, which was of course
implemented as a double rotate right (or was it left?) 16 bits. Not
super fast.
Try this at home: the "multiply+16" opcode (101370, if memory serves)
jumped into a microcode jump table at some point. Unfortunately, the
microcoder was seriously out of room at that point, so he or she had
decided to use part of the jump table as code to handle the machine's
front panel. This on the (obsolete) F series machines. Executing a
multiply+16 opcode put you into the front panel, where you were of
course uninterruptable.
Those were the days, back when instruction sets were designed by people
that were learning by doing. Fortunately HP's more recent products
such as the Precision Architecture (notice I didn't say Spectrum :-)
machines are much, MUCH better designs. One of the most effective
instruction sets I've run across from any manufacturer, and I didn't
even work on it, so I'm a little more objective than it would seem.
Lots of good stuff to help make things go fast for both individual
programs as well as system performance, without using much hardware.
Joe Bob says check it out.
Doug "those were the days" Hartman
at "Spectrums R Us" in scenic Cupertinobaum@Apple.COM (Allen J. Baum) (07/30/88)
[] >In article <6310011@hpcupt1.HP.COM> hartman@hpcupt1.HP.COM (Doug Hartman) writes: > >Re: 2100 architecture. >...also let you loop forever with the right two JMP instructions. But >since the machine had infinite levels of indirect resolution, you could >get the same effect by doing a JMP *+1,I > DEF *,I Actually, the microcoded 2100's had a hack to fault if you went 4 levels deep into indirection >Fortunately HP's more recent products >such as the Precision Architecture (notice I didn't say Spectrum :-) Sorry, I still call it Spectrum. -- {decwrl,hplabs,ihnp4}!nsc!apple!baum (408)973-3385