Slashdot Mirror
Remembering 36-bit DECs
rjinbanff writes: "Very interesting read that details a number of historical events in Computing history (Kermit, EMACS, etc). Self-described as: "A nontechnical reminiscence written in 1988 (on the occasion of unplugging Columbia University's last DECSYSTEM-20) for a Digital Press book that was to commemorate DEC's 36-bit machines with a series of articles, but was never published."
Minor edits, notes, glossary, links, and HTML formatting added in January, 2001."
The most common byte size on the '10 was 7 bits, allowing you to store 5 bytes in a 36 bit word, with a bit to spare. One of the popular text editors on TOPS-10, SOS, used this extra bit as a "line number indicator", meaning that words with the extra bit set was in fact the start of a new line of text, and contained the line number.
File names on TOPS-10 was stored in SIXBIT format, a 6 bit wide character set that made it possible to store a 6 character file name in a 36 bit word.
Another common byte size was 9 bits. If you placed a terminal in Packed Image Mode (aka PIM, resembling Unix "raw" mode) and read from it, you received 9 bit bytes, where seven bits were data and the last two bits were status information.
Nothing stopped you from creating byte pointers of other widths, and I recall writing programs with 1, 18 and 36 bit wide byte pointers.
There's nothing special about an 8 bit byte; that's a more recent concept than these dec mainfraims. Why 32? It leaves 4 bits left over after putting 4 characters in it? 64 only wastes 1 bit after holding 9, but it's a bigger word than you need for common integer or floating point data.
The 8 bits we use (why not 7???) seems to come from the 4 bit processors (4004, 4040) of the 70's. 4 bits was enough to hold a bcd digit. 8 let you hold two at once. After that, we've just doubled what we started with a couple of times.
Oh, and many of those older processors could use bytes of various sizes. I think the dec's were among the 36 bit machines that had a command to set the byte size from anywhere from 1 to 36 bits. It all depended upon what yoyu were doing with the data.
Well, your common or garden variety PC desktop or "server" (in most cases, a desktop PC with more drive bays, if you buy it from someone like Gateway) certainly isn't. But that's a function of the whole system, not the CPU, as Sequent show.
No, those were 32-bit CPUs (in the sense of having 32-bit general registers), like all IBM S/3x0's; they just happened to have 31-bit virtual addresses, unlike earlier S/3x0's, which had 24-bit virtual addresses even though they had 32-bit registers. (At least on the ones with 24-bit addressing, the uppermost 8 bits of the address were ignored - just like the original 68000; the 31-bit S/3x0's had a mode bit so they could run applications in 24-bit mode, in case somebody'd stuffed extra data into the upper 8 bits of pointers, relying on them being ignored. I think similar problems cropped up when Apple went from the 68000 to the 68020 in Macs.)
I'd been under the impression that DEC had {bought,licensed,whatever} TENEX and turned it into TOPS-20, i.e. the reason TOPS-20 looked quite like TENEX was that it pretty much was TENEX.
They only ran into trouble because (apparently) they wanted to use some or all of their C compiler as a back end.
Chapter 13 of the Ada LRM (Representation Specifications) allows an Ada programmer to define layouts of data types and structures down to the bit level if desired (typically when writing device drivers), but it is explicitly warned that such code is non-portable.
The reason these early machines were 18/36 bits derives from a bit of historical accident: a lot of the early machines used for scientific computation had "at least 10 digits" as a requirement. 10 decimal digits translate to 34 bits. Add a sign bit and you have 35 bits. The EDVAC (successor to the ENIAC) actually used 35 bits, 2's complement, but it turns out that having an odd number of bits on a machine that supported halfword operations was an unbelievable pain, so machines quickly added one more bit to get to an even 36.
Oh, I'm certain of that. You tended not to believe those stories until you experienced one first-hand.
I guess it depends on the situation. We had an 11/34a installed in a truck out in California. One of the guys from the team flew out there to man it for some flight data collection seesions we were running with NASA. He somehow clobbered the boot block of the RL02 pack. Luckily we had a version of the 34a that had the programmer's front panel (Field Service really hated to work on customerss systems who didn't have that keypad). I had to read the bootstrap code to him over the phone and have him key it in about an hour before the flight tests were to begin. Then I had to overnight him instructions on how to rebuild the boot block. Actually, it was pretty nifty that you could even do that. I cannot imagine doing that on a PC, though I suppose with a DOS boot disk with DEBUG.COM you could accomplish the same thing. (Uh, oh. I think I just added another thing to my weekend to-do list!)
--
CUR ALLOC 20195.....5804M
Whoa...
I think I'm having an ASCII FORTRAN and FORTRAN V flashback!
--
CUR ALLOC 20195.....5804M
Nah. TOPS-20 wasn't so weird. Now Sperry's EXEC operating system. It had so many barriers to getting anything done that it nearly drove me nuts. I was so happy when I could move my software onto an RSX11 system.
--
CUR ALLOC 20195.....5804M
I met a guy at DECUS years ago who was running a PDP-11/45(?) (essentially an 11/70 w/o cache) in his basement. Like the 11/70, I believe these needed three-phase power to run. I suppose you could rework all the power supplies to avoid the hassle of three-phase but that doesn't do much about the current draw. This guy's electric bill must have been something! The UNIBUS and MASSBUS PDPs could be serious power hogs.
You could have run RSX quite nicely on a Q-bus PDP-11 that wouldn't have emptied out your bank account. I actually considered it but I couldn't scrounge up a 9-track tape drive to do the OS load. And a good thing, too! The tape drive would have really run up the electric bill.
--
CUR ALLOC 20195.....5804M
Gee... I thought I was the only one.
I have hanging on the wall in the den:
The 11/70 parts came from a system we got used from NASA Goddard back in the mid '80s and used as spare parts to keep our aging ``production'' 11/70 running. The crashed disk platter was particularly memorable. The heads didn't just crash into the disk; they were torn off the arm which proceeded to scrape all the data off the center of the platter along with a significant amount of aluminum. I don't think anyone who was there will ever forget the sound. Today's disk failures are nothing in comparison.
There seems to be no end to what bizaare stuff computer folks hang onto (and display like trophies on the wall).
--
CUR ALLOC 20195.....5804M
It hasn't always meant 8 bits. And there was nothing special about 8 bits--certainly not the size of a character.
But if a byte isn't 8 bits then 2 bits isn't a quarter of a byte. Then there's not a funny correlation between a quarter of a byte and a quarter of a dollar. What type of world would that be?
--
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
early versions of UNIX had an even more elusive name for this command: dsw, an abbreviation for "do swedanya", Russian for goodbye, transliterated into Polish or perhaps German; this is not the only place where the censor has been at work... Current "standard" versions of UNIX do not have a "help" command, but in earlier releases, a help command was provided which declared simply, "UNIX helps those who help themselves"
plus a set of powerful text manipulation utilities like sed, grep, awk, lex, and yacc, whose functions should be obvious from their names.
I find it sort of ironic to read this coming from people who worked on mainframes, etc. (real iron men) Sure, Unix has come a ways from 1988, but for all those hard-core super-31337 CLI hackers, I think this is some evidence that even to people working with card-reading machines, and programming their own mainframe system utilities in assembly, that Unix was still user-unfriendly.
It's 10 PM. Do you know if you're un-American?
If you read some RFCs, for example you will see that IP datagrams consist not of bytes, but octets, and words are defined, not assumed, to be 32-bits.
Look at the Jargon file. You'll see byte's proper definition as "A unit of memory or data equal to the amount used to represent one character; on modern architectures this is usually 8 bits, but may be 9 on 36-bit machines. Some older architectures used `byte' for quantities of 6 or 7 bits,"
Have you ever wondered why C uses octal? Or why Unix (and therefore chmod(1)) takes octal numbers for permissions? It's because C and Unix were initially developed on 36-bit DEC machines. A 36-bit word has four 9-bit bytes, each represented by three octal digits.
Honestly.
--
This is not my sandwich.
Of course, todays 31337 h4Xx0R5 don't even know what a .ARC file is!
Back in my day, we had to walk 15 miles through a raging snowstorm to extract our archives. Uphill! Both ways! And we were glad to do it, too! We didn't have no fancy ZIP programs neither! But we didn't complain, oh no!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Remember, SIMTEL20 was a DECsystem-20, running TOPS-20.
Gods, what a weird OS that was...
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Yeah, but it ain't the same as finding SIMTEL20.ARPA, and having to know to set TENEX...
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
I'm fond of retrocomputing. I'll admit that up front. I'm getting old enough to be nostalgic about things like COMND JSYS and a UNIX shell that doesn't have shell variables.
But then a thought struck me. I worked at The RAND Corporation during the days when it still had a technology program (they assassinated it in favor of policy analysis). They had a DECSYSTEM 2060, used primarily for INTERLISP work. The 36-bit architecture never caught fire at RAND the way it did elsewhere. At ISI in Marina del Rey, for example, they had the world's most photogenic machine room: it had a view over the marina that was to die for, and they also had about ten PDP-10s lined up facing each other. They sold a lot of access to movie companies who needed a really sexy machine room, I hear.
Now, RAND did a lot of solid research on that 2060. That work was moved to Xerox Dolphins, which weren't nearly as fast, and on which INTERLISP ran much more slowly than it did on the 2060. Eventually that work petered out. There was an effort to port INTERLISP to the VAX, including writing new VAX microcode, but that effort was never completed (this wasn't at RAND, btw).
With the change in machine architecture, from PDP-10 to SPARC and PC, came a shift in research focus. Actually, at RAND, which was the first commercial UNIX licensee, those efforts were carried out in parallel. It was astonishing to note that there was essentially zip in the way of cross-fertilization between RAND's 36-bit world and RAND's PDP-11 and Sun worlds. There was an intelligent assistant AI type thing built on the UNIX system, RITA, the RAND Intelligent Terminal Agent, but that was only because that work was done before the 2060 arrived, I'm pretty sure.
So the question is, now that the 36-bit world is available again in emulation (sort of, if a decent PDP-10/20 emulator ever sees the light of day), could computer science benefit from any of that old work picking up again? I mean, the address space limits are essentially gone. I'm not certain but I'll bet that on a decently fast PC, the emulators would allow programs to run rather faster than they did on a 2060. INTERLISP suddenly becomes viable again.
Is there any point to doing this? Is any of the work that was starved off by the death of that architecture worth reviving?
The only DEC machines NetBSD will work on are VAX'es, MIPS'es, Alpha's, and Intel's. Ultrix only ran on VAX'es and MIPS'es. Neither works on any of the 16 bit or 36 bit DEC machines.
What you have to understand is that the culture of the 36 bit machines was very mainframe, and nobody who is interested in them is interested in anything to do with Unix.
The whole point of collecting exotic hardware is to be able to run exotic software (i.e. anything BESIDES Unix - especially a mass-consumed, homogenized Unix like NetBSD).
Also, the machines are extremely large, expensive, and costly to operate; there are very, very few installations of these machines by hobbyists (and few/none elsewhere), thereby severely limiting the potential audience for it.
Well, a lot of the 36 bit machines were 6x6bit, so you would fit 6 characters into one word (DEC had a 6 bit ASCII type endoding system). Some of these OS'es had six character filename limits (i.e., so it could fit in one word). There are still some vestiges of this around today (e.g., DECnet still has a 6 character hostname limit), which I'm not sure if they're related to 36-bitness.
Think "DEC". Think "Boston". Think "MIT". Think "AI". Think "Lisp". Think "lists". Think "cons cell". Think "car" and "cdr". The 20 had instructions for manipulating 18-bit halfwords. Each 18-bit half-word could store an address. Thus, each 36-bit full-world could store a cons cell. And yes, I still have a copy of my SYSDPY.INI file.
4 bits in a nibble
2 nibbles in a byte
The size of word depends on how big your buss is.
`ø,,ø!
Free Software: Like love, it grows best when given away.
IBM adopted 32 bits with the System 360, this was great for Univac which sold many tons of 1107 /1108 machines into the Fortran
market..
Nobody cared about characters ..
the purpose of computers was numbers....
For many years (maybe still) a Linker option on Unisys 1100/ 2200-series programs is "AFCM" which stands for "Arithmetic Floating Point Compatibility Mode" and which guaranteed bit-for-bit compatibility numeric results with the long-extinct 7094...
Well, lex is relatively obvious, but the others...
on a 36bit word, you could fit exactly 6 'semi-ascii' characters if they were constrained to the limitations of SIXBIT. yes, SIXBIT is a character coding scheme invented by DEC that allows only (surprise!) 6-bits per character.
no upper/lower case - one case fits all.
abridged punctuation set as well.
but imagine the waste of having only 5 pure ascii characters (7-bit) in a 36bit word! hey, conserve that extra bit; there are hungry computer programmers in [insert remote underprivileged country here] that would give their eye-teeth for that extra bit you just wasted!
--
--
"It is now safe to switch off your computer."
word size char size chars/word architecture Company
16 bits 8 bits 2 Mini/Micro Intel,Moto,DEC,DG
24 bits 6 bits 8 PDP?? DEC
24 bits xxxxxx ? DSPs TI,Moto
36 bits 6 bits 6 1100 Univac/Sperry/Unisys
36 bits 6 bits 6 GCOS 8 GE/Honeywell/Bull
36 bits 9 bits 4 1100/2200 Sperry/ Unisys
36 bits 9 bits 4 GCOS 8 Honeywell/Bull
48 bits 6 bits 8 A/B series Burroughs/Unisys
48 bits 8 bits 6 A/B series Burroughs/Unisys
60 bits 6 bits 10 6000 CDC
60 bits 7 bits 8 6000 CDC
God I must have some work to do!!
What do you want then?
I think the poster is referring to the fact that computer technology to most young people nowadays means PC-class computers (or at best a Sparc platform) in their house or on their office desk. They rarely have access to large TPM environments.
The days at wonderlust at a piece of "big iron" are long fading, though I get to play with an E10k sometimes (but it's live, so I can't 'tinker'
A bit of detective work on google found the following info from trying to implement Ada on the 2200 36-bit architecture:
We are working with Unisys on an Ada 95 implementation for the 2200 series machines. Those machines are 36-bit, 1's complement machines.
Originally, we did not think there was a problem here. After all, the C compiler supports a full 36-bit unsigned type. We would just copy that implementation. However, on further inspection, that turns out not to be so easy. The C compiler had major problems with the unsigned type. Ultimately, two versions of the C compiler were built, one to pass the C validation tests, and one to actually use. To pass the C validation tests, Unisys built a compiler which emulated 2's complement math for this machine! That was done by doing all operations as 72 bit operations, and then reducing the result. Obviously, they did not want to use that implementation for production use.
In summary, if you read the Ada article it seems there are a whole lot of issues with a 36-bit machine, like having to do everything at 72-bit so you can divide by 8 again!
At this rate it's no wonder Emacs turned out so bl**dy complicated!
... and Ahmdal are still making them!! Amdahl will continue manufacturing its existing 31-bit S/390-compatible systems until March 2002 and will continue to provide service and technical support until 2007
;-)
Where will it all end?
Your parents perhaps, but Grandma?
All this happened less than 20 years ago. I'm in my early 40's, but my whole career started in high school with DEC 20's with punch cards and PDP-11's with RSTS and papertape (110 baud modems), then RSX & RT11, VAX/VMS, Alphas, and finally intel (which was a technology step backward at that time, especially with windows). The pace of computer technology is incredibly fast. 20 years ago, half a meg of disk and 64k of memory was a lot.
Languages move fast too. First interpreted BASIC (I skipped COBOL because I started on DEC systems), then compiled BASIC, FORTRAN, C, then C++/smalltalk/java/perl/whatever ... Every 4-5 years you have to learn a new language.
Expect that everything you are writing will be obsolete within 10 years, and that something will come to rival Linux within 20.
Also expect that 10 years into your career, you'll be encountering younger people that believe what occured before them was bogus, and that what they are doing is totally new & different :-)
---
Keith Barrett (kgb)
Red Hat HA Team
---
Keith Barrett (kgb)
Proof that skr1pt k1dd33z are far from a new phenomenon. When I was in high school in the early '80s, I was among the group of hacker kids at my school, but the ones at nearby schools had much more ph33r p0w3r. Of course there was no internet back then, so information was hard to find, and you only had one or two local time-share systems to work with. And this was back when you had to know what the hell you were doing just to log on even when you were supposed to be on a given system. The Internet has significantly lowered the bar on what it takes to be a kiddie.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
I actually logged into the system mentioned in this article, presumably right before it was unplugged, since it was in the 87-88 timeframe.
/mine mine mine/, not some university's!
Anyone remember SIMTEL20, which you can still find references to quite a few places on the net? That was a DECSYSTEM 20 at the White Sands Missile Range, and the home of many seriously cool archives.
My only personal experience with hardware of this era (actually older that that) was the DEC PDP-8e that we had for some time at our high school in Omaha. It had, I believe, 2K of core memory, quite a few DECtape units (mentioned in this article), and a 512K drum drive that was the size of a refrigerator and spun at an insanely high rate. We were told you didn't want to be in the room if the bearings ever went out.
The very cool thing about that system was power recovery. If the power ever failed (or someone pulled the plug, which we did once) the system could see it coming and quickly dump all the registers into core memory. Since core is non-volatile, things would pick up right where they left off when the power was restored. The ultimate UPS!
After that, I went on to work as an operator on a VAX 11/780 and 8650, doing standalone backups on the weekend graveyard shift, among other things. It was always fun to see what I could get out of students who only needed a few more minutes of CPU time to finish their assignments before I shut the system down. I got quite a few good takeout meals out of that deal.
Still and all, although it was a great time, I have to say that I'll take my nice portable laptop with Linux on it over any iron that big any day of the week. It's
That's an artifact of languages like C/C++, which provide 8bit byte addressability and use 8bit bytes extensively for string processing. In many other programming languages, you would hardly notice: they provide abstract string types, automatic packing and unpacking of arrays, and other features.
It's also an artifact of ASCII, in which characters are 8 bits. In fact, 36 bits is nicely divisible by 6, often used as the character size on mainframes.
It is kind of ironic how much the C/C++ programming language has driven the development of hardware. That sad thing is that now that the hardware has adapted so much to C/C++, many nice features that aren't in C/C++ are a lot harder to implement.
Incidentally, 36 bit or 68 bit architectures need not be a big problem for C/C++: you could treat them like byte addressable 32 bit and 64 bit architectures and use the extra 4 bits as type tags. That would actually make compiling languages like Java, Python, Lisp, and others a lot easier.
In the future, you are probably going to see a lot more people treating 64 bit machines as "32 bit machines with a few extra bits in each word", for just that reason.
68bit wouldn't really make sense, since there should be one parity bit for every byte. 64 / 8 = 8 bytes, so 72bit would make more sense than 68.
You're using a very recent notion of "byte" . . .
.)
It hasn't always meant 8 bits. And there was nothing special about 8 bits--certainly not the size of a character.
With an ascii character set, the dec's put 7 characters/word, with one left over (which I think was used to indicate the last character in certain circumstances.
The data, though, was 36 bits, not 32+parity. Besides, if you want to do that, I think the correct number is 38, not 36, to allow 1 bit correction and 2 bit detection.
OK, OK. that's not the real reason for 36 bits. Remember how cars used to have real spare tires instead of the toy spare? Computers were like that, too. If you burned out bit 7 of the processor, you had some spares to use . . .
(really not as facetious as it sounds. Core memory used to come with spare rows & columns . .
Oh, ok I only counted 87 definitions in the glossary. I guess it has to be 100 before it's "technical".
"The most important contribution of the DEC-20 to networking was its support for the ARPANET protocols, first NCP and later TCP/IP. For many years, DEC was the only major computer vendor to support these protocols, which were mostly developed on DEC 36-bit machines under TENEX, TOPS-10, and TOPS-20 (and later on VAXes for Berkeley UNIX). "
Ok so us geeks understand this, but come on!
I think I'll print this out for my Grandma to read!
I thought the epilogue hit it right on: "Meanwhile, many of us who lived through that era retain our old habits, still using text-based applications such as EMACS and MM (or its successor, Pine) rather than their fashionable GUI replacements, but on UNIX platforms (Solaris, Linux, etc) instead of PDP-10s. Each time a new PC virus plunges the entire organization into chaos and panic, we barely notice. There is something to be said for the old ways."
So true.
Another thing. THough today we have massive amounts of software available, its somehow less satisfying it seems. Sure, you can deploy a major system, joining lots of software packages together and perhaps even modifying them some to do the job, but how exciting it must have been to be part of the group blazing the trail of timesharing user access, email, TCP/IP via Arpanet, and more. How satisfying it must have been.
Finally, I still shake my head is disbelief how fast things have changed. Back in 88, PCs were available, but not widespread, mostly due to lack of network access. I remember thinking how cool it was to have a BITNET address and being able to communicate with folks around the world. TCP/IP was made available to us around 1990. But to think that was only 10 years ago! In 88 I had a 4 or 8MHz XT (can't recall) and graduated with a 33MHz 386 just as 486s were hitting the market. Now, 8 years later I'm reading Slashdot on this web thing using a Pentium III laptop running @ 700MHz, connected to the internet via wireless networking to my DSL internet connection. 8 years ago we were psyched to have 9600 baud serial modems in each dorm room connected to the campus network.
Mind boggling.
Top Most Bizarre/Disturbing Error Messages
Unisys still use a 36 bit architecture in their 2200 mainframe class machines.... caused no end of grief to the new graduates at the last place I worked, on a UK banking system *grin*
/. accusing them of smoking crack!
Interestingly enough, these machines still power most of the airline reservation and core banking systems in a significant part of the world.
If someone came up with a 68bit (for instance) architecture nowadays we'd all be on