Remembering 36-bit DECs 122
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."
All modern x86 Processors are 36 bit, sort of (Score:1)
On Unisys 2200's, some stuff is six-bit FIELDATA. (Score:1)
As with the SIXBIT format you mention, this allows the storage of 6 characters in each 36-bit word, and as the end result of this you see a lot of 12-character length limits (two words) in various system files, packet formats, and so on.
As a sidenote: the major airline I work for still uses 2200's, and the application I work on still stores most of the application data as FIELDATA.
--
-Rich (OS/2, Linux, BeOS, Mac, NT, Win95, Solaris, FreeBSD, and OS2200 user in Bloomington MN)
Memories of Columbia days (Score:1)
DECWAR, SITWAR, VTTREK (Score:1)
My favorite game was VTTrek [mono.org], which was a first-person 3D space fighting game played on a VT-100 terminal. No, there were no bitmap graphics. It used the wonky 8-bit ANSI character graphics combined with ANSI escape sequences for bold, flashing, etc. to make it more animated. And you had to play on a 9600 baud terminal connection, or else you would lag and be blown away by those high-baud bastards.
DECWAR [blkbox.com] was another favorite. It was only 2-D, but was realtime [not turn based] and you could play it on either a CRT terminal [i.e. a monitor] or, you could also play using a line printer terminal [paper]. You could enter lots of cryptic command lines and dump your view every so often if you needed it. Wow, that was fun. Sort of like keyboarders versus mousers in Quake. [Update: that DECWAR page linked to above has a link to a version running on a BSD box. Oh yes...]
sitwar was another fun realtime wargame [maybe it was spelled 'citwar'?]. But I think it required a monitor, so we didn't play it as much [monitors -- or "CRTs" as they were called then -- were in low supply and high demand].
When it came to instant messaging, we used something called "FORUM", which I think was written by my friend Yoram at UofT. Actually, it was closer to IRC, except that there you could see a history of the last N lines. It was great -- you could log in at noon, do a "/lastlog" and the previous 20 lines of conversation, complete with timestamps, would be printed out for you. Good for leaving messages.
Re:Hooray for sarcasm (Score:1)
so, why 36? (Score:1)
Been there, done that: even in late 70's, like 78-79, at least one University in Appalachia had most student computer services as batch jcl FORTRAN as described, altho the 'cool' students would use 300 baud acoustical modems with (snicker) rotary dial phones to 'Wylbur' and something called a 'VAX' - I really didn't care about that stuff (in retrospect, should have) - was more involved in the build your own single board 8085 computer EE class w/ the Tektronics 'in circuit emulator' with the 8" floppy!
Re:byte? 8 bits? (Score:1)
I forget the specifics, 12 bit words? Something unusual.
All hail the COMND JSYS! (Score:1)
God, the effort I went through just to get graphical output. That was in the days when CPU time was accounted for. My advisor dropped me a note in my department mailbox, telling me I had used something like $2300 of CPU time under account "misc" - "I hope there is a good reason for this". Well, there was, I was writing cwplot. The thought of CPU time accounting seems silly now.
But the COMND JSYS was the greatest. It made the command interpreter pretty much self-documenting. When I first encountered Unix, I was extremely annoyed that the "man" command didn't even do that really. It took a year of solid use to finally "get" Unix (and C programming, too), over 5 years after my experience with TOPS-20. tcsh tries to emulate COMND, but essentially fails. How can one go adding documentation for every command on the system? The very thought is ridiculous.
BTW, anyone else remember PCL? You could write clever hacks in that - kind of a scripting language for "exec," the command processor. But you had to run the "exec" in the directory. And PCL docs were something you printed out on the wide line printer and then cut and bound yourself. Had a lot of fun with PCL...
And I still remember a little TECO: "y" would irrevocably erase a buffer in EMACS. Of course, EMACS is permanently wired to my fingers now. I've only had to stop using it when I was stuck with Macs, DOS or Windoze...
My first abortive experience with C was on TOPS-20. A CS guy at WPI had written a compiler for it, and because of the 36 bit word, all the "bytes" were 9 bits! I stuck to Pascal anyway - thought it was the greatest. Didn't learn C until 4 years later.
Thanks for the great article. It explained a lot of little things I never knew, most probably because WPI was cut off from the ARPANET, supposedly because of some transgressions committed before I got there...
Re:so, why 36? (Score:1)
According to a long list of computers [nus.edu.sg], the PDP-7 was an 18-bit machine and the PDP-11 was 16 bits. Not mentioned on the list, the GE 635 had a 36-bit word.
Early history of Unix according to Ritchie [bell-labs.com].
Re:so, why 36? (Score:1)
That'd be the one with the PDP11 core, running V7.
So maybe you were closer to the cool students than you thought.
Hooray for sarcasm (Score:1)
"...plus a set of powerful text manipulation utilities like sed, grep, awk, lex, and yacc, whose functions should be obvious from their names."
Paul Stevenson [surrey.ac.uk]
Re:byte? 8 bits? (Score:1)
Re:byte? 8 bits? (Score:1)
The Cyber 170 series were 64-bit machines, but they had a 60-bit compatibility mode. KRONOS and NOS/BE would use 6/12 code IIRC, and NOS/VE used 8-bit bytes full of ASCII on the same hardware (in native mode).
Re:36 bit? Sounds as kludgy as 53 bit ATM (Score:1)
Re:DECprocessors (no NOT alpha) (Score:1)
Re:SIXBIT anyone? (Score:1)
Basically, squishing 3 characters into 2 (or 24 bits into 16) because the character set did not include lowercase.
It was commonly used to store passwords on RSTS/E
(boy, I remember this stuff like it was yesterday)."
Actually you don't. SIXBIT had six distinct 6-bit bytes per 36-bit word, and could be constructed using the byte operators. RADIX50 uses a 50-character charset and must be packed using arithmetic (multiply, add, multiply, add....)
SIXBIT was used by the TOPS-10 filesystem. RADIX50 was used *somewhere* in TOPS-10 but I misremember where; it was much more widely used in PDP-11 OSes (as you noted). TOPS-20 used ASCII throughout.
Re:User Friendliness (Score:1)
Yes, but in the context of the article, he seemed to think TOPS-20 was user-friendly the first time he used it, and still finds Unix unfriendly after five years (written in '88). Of course, could be nostalgia for TOPS is coloring his glasses, but based on my experience with UNIX, and his description of menu prompts in TOPS, I don't think so.
Re:so, why 36? (Score:1)
No. Unix V1 was done on an PDP-7 18bit computer. somewhere around V2 or V3 they switched to an PDP-11 16bit machine. C only came with V5 on 16bit.
But all these machines were octal, grouping bits in groups of 3. PDP-7 6*3, PDP-11 1+5*3 (and 18bit addresses when using MMU).
Only the VAX (32bit) and microprocessors (4/8/16/32bit) came as hex(ed) machines.
--
Re:so, why 36? (Score:1)
--
Re:Hooray for sarcasm (Score:1)
Re:That's not even that weird (Score:1)
Another thing I learn now: that there are 31-bit s/390 systems.
Thanks for the info!
That's not even that weird (Score:1)
Tops 20 vs Unix (Score:1)
== Doug Moen ==
dsw == delete from switches (Score:1)
From: kent@decwrl.dec.com (Christopher A. Kent)
Newsgroups: alt.folklore.computers
Date: 4 Jan 90 08:44:51 GMT
That's not quite the way I have it. The original dsw stems from the days when computers had front panel switches (dsw = "Delete from switches") and Unix core files were restartable.
To delete a file whose name you couldn't type, you would obtain its i-number (from ls or catting the directory), enter the i-number in the switches, and run dsw. dsw would create a core file that, when run, would delete the offending file.
I'm not sure when dsw changed from this functionality to the precursor of rm -i, but I'm pretty certain that V5 dsw didn't use the front panel switches.
== Doug Moen ==
DECsystem 10 in a museum (Score:1)
Re:Memories of Columbia days (Score:1)
Re:so, why 36? (Score:1)
Re:Memories of Columbia days (Score:1)
Re:Jeez, this brings back memories (Score:1)
And I believe all "TOPS-20" systems used KL-10 processors or successors, if any.
So while it might be true that all TOPS-20 systems had PDP-11 front-end processors, it wasn't the case that all TOPS-10 systems had them.
Back in Those Days (Score:1)
Re:60-bit machine at UT Austin in the mid 80's (Score:1)
Re:DECWAR, SITWAR, VTTREK (Score:1)
Re:The first real MUD was on DEC (?) (Score:1)
Re:36bit architecture (Score:1)
Aha! I had forgotten why 36bit was actually used in the first place: it makes sense again
So why don't we use parity bits in the data path any more? Is this because of self-checking ECC-RAM (for instance), or because of more reliable processors/manufacturing processes?
Re:What's up with this topic? (Score:1)
What's up with this topic? (Score:1)
Boy the way Glenn Miller played... (Score:1)
Guys like us we had it made
Those were the days.
And you knew where you were then
By the lights of the KI-10
Mister we could use an editor like TECO again
Didn't need no ROM bootstrap
Or any of that GUI crap
Gee our old TOPS-10 ran great
Those were the days
Jeez, this brings back memories (Score:1)
The main thing I remember about that job was the disk drives. I don't remember the DEC model number, but we had three, and they were each the size of a washing machine, had the big removable 20-pound 10- or 11-platter disks, and held, each, a whopping 200+ MB! Woohoo! (Now I've got 40 GB in a 3.5" form factor in my new PC at home...God, I love technology.)
I liked that 2060. I got decent at doing basic operator functions--startup, shutdown, queue management, etc. I even wrote school papers using whatever their runoff language was, and printed them on one of the typewriter-style terminals in the offices. It was just a very easy and straightforward system to use. And it sure helped when I got to college two years later and found myself working on a VAX 11/785.
Besides, I've been working with obsolete mainframes ever since, so that 2060 got me started on my career path. :)
Re:Jeez, this brings back memories (Score:1)
I also did 3 years of COBOL programming on a Unisys A15 (later A19) for a major US credit card company. Yes, Unisys A-series use 48-bit words (we used six 8-bit bytes), and they're a monster pain in the ass to program COBOL on. They don't pack and store their numeric data in the same way as IBMs (translation: Everybody Else In The World) do it. Packed fields could actually be fractional bytes--a 7-digit field would be 3.5 bytes--and the next field would start in the middle of that fourth byte. Plus they put the sign on the front of the field, instead of the end. And in general, their OS made me weep for the days of TOPS-20 or VMS. CANDE was the suckiest editor I ever had the displeasure of using, especially after 3 years of ISPF and 3 years of vi.
Sadly, I never got to program on that '2060, just play at being an operator. Oh, and occasionally call the DEC service center in Colorado Springs, when something went haywire. I remember watching some tech there take over our machine through the 1200-baud modem, as his commands echoed over the console. Hey, at 16, I thought that was some cool shit. :)
Didn't those DECSYSTEM-20s have a PDP-11 in there as some sort of front-end processor? I seem to remember my boss telling me there was a PDP-11/43 in there somewhere...like I knew what a PDP-11/43 was at age 16 growing up in rural Virginia. I was too busy checking out the student op's 34Cs. :)
Re:SIXBIT anyone? (Score:1)
SIXBIT and RAD50 were different OK. I was wrong.
RADIX50 was a 40-character set system. The "50" was an octal number
---
Keith Barrett (kgb)
Red Hat HA Team
Re:Jeez, this brings back memories (Score:1)
Remember the cleaning brushes that would come out when the drive spun up?
---
Keith Barrett (kgb)
Red Hat HA Team
Re:DECWAR, SITWAR, VTTREK (Score:1)
I also remember SNAKE and TANK -- two good multi-user VT100 graphic games.
I also remember when ADVENTURE and DUNGEON first came out. Lost 5 months of my life to those games!
---
Keith Barrett (kgb)
Red Hat HA Team
Re:DECprocessors (no NOT alpha) (Score:1)
---
Keith Barrett (kgb)
Red Hat HA Team
Re:The first real MUD was on DEC (?) (Score:1)
visit http://ftp.uk.linux.org/~kgb/Caterham7, then email me
---
Keith Barrett (kgb)
Red Hat HA Team
Memories (Score:1)
---
Keith Barrett (kgb)
Red Hat HA Team
Re:SIXBIT anyone? (Score:1)
Basically, squishing 3 characters into 2 (or 24 bits into 16) because the character set did not include lowercase.
It was commonly used to store passwords on RSTS/E
(boy, I remember this stuff like it was yesterday).
---
Keith Barrett (kgb)
Red Hat HA Team
Re: Front panels (Score:1)
I also have in my trophy collection an RK05 disk, and Altair 680 literature, but I must confess that it's still fun to flip the PDP-11 switches ones in a while
---
Keith Barrett (kgb)
Red Hat HA Team
Re:What's up with this topic? (Score:1)
I guess we'll all have to go back to DEC-20's then, and abandon our "Athlon, Geforce, and latest Redhat."
- Ando
Re:Ah, those were the days... (Score:1)
Oh, that
Thanks for the trip back.
JA Net (Score:1)
Didn't realise it went back as far as early 80s though. I knew of a few dial-in MUDs around 84. I think BT invested in one at some point, but that would have been later. 86, 87? Wonder how much revenue they got from that?
Re:Hooray for sarcasm (Score:1)
60-bit machine at UT Austin in the mid 80's (Score:1)
Re:DECprocessors (no NOT alpha) (Score:1)
But it looks like the fuxxorz didnt even want to boot up. They have some systemtesting with a countdown that stopped at 3, even tried out a MicroVAX with the scsidrives, seems like that MicroVAX used another synch for monitors because i didnt get any display on it. Oh well as another poster said, ill go play with my Athlons & GeForce instead.
DEC-stations cant be used as radiators, they make to much noice.
Re:DECprocessors (no NOT alpha) (Score:1)
If i had a penny for every pound of junk i got home to piss off my GF id be a millionare instead of having a junkyard of old shit. Im really just hoping to be able to run something else then these old geezers like the ones you mention. Im wrapping up things at work here so i dont know the modelname other then it uses DEC-processor and is called DEC station (think it should be around 800Mb harddrive and scsi interface to it) It would be a shame not to atleast compile apache on it and let it be slashdotted over and over by mirroring sites that are popular or should i just throw it of the balkony down on some ricecooker car when it passes?
Feel the power of UNiX, submit to the Daemons
DECprocessors (no NOT alpha) (Score:1)
Havent read the entire article.
--
Having that said, this hardware used to run Ultrix machines and to some extent is today.
But is there any other use today, can DECproccessors be run on any Linux distro or perhaps NetBSD?
Cuz if it cant be run on NetBSD it aint even electronics.
Nah this isnt my
Re:byte? 8 bits? (Score:2)
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.
why 32? (Score:2)
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.
Re:36bit architecture (Score:2)
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 [sequent.com] show.
Re:That's not even that weird (Score:2)
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.)
Re:DECprocessors (no NOT alpha) (Score:2)
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.
Re:DECprocessors (no NOT alpha) (Score:2)
Re:36bit architecture (Score:2)
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.
Re:36bit architecture (Score:2)
Re:why 32? (Score:2)
Some supporting URLs:
- http://www.dg.com/about/html/ibm_360.html
- http://www.cs.uiowa.edu/~jones/assem/notes/05.htm
Re: Front panels (Score:2)
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!)
--
Re:On Unisys 2200's, some stuff is six-bit FIELDAT (Score:2)
Whoa...
I think I'm having an ASCII FORTRAN and FORTRAN V flashback!
--
Re:You're not fooling me! (Score:2)
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.
--
Re:DECprocessors (no NOT alpha) (Score:2)
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.
--
Re: Front panels (Score:2)
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).
--
Re:byte? 8 bits? (Score:2)
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?
--
User Friendliness (Score:2)
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.
Re:so, why 36? (Score:2)
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 [tuxedo.org]'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.
--
Re:Ah, those were the days... (Score:2)
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!
Re:You're not fooling me! (Score:2)
Gods, what a weird OS that was...
Re:Ah, those were the days... (Score:2)
Maybe we should bring them back (Score:2)
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?
Re:DECprocessors (no NOT alpha) (Score:2)
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.
Re:so, why 36? (Score:2)
Re:36 bit? Sounds as kludgy as 53 bit ATM (Score:2)
Re:why 32? (Score:2)
Think about it: if you can encode a 34 bit shift, you have the bits to encode a 63 bit shift. With only 36 bits to shift, you end up with a huge hole in your instruction space. If you use those spare encodings for 'special functions' then you end up with a messy opcode map (not too nice for the microcode).
All in all, it's just nicer if your bit count is a power of two.
`ø,,ø!
Re:byte? 8 bits? (Score:2)
4 bits in a nibble
2 nibbles in a byte
The size of word depends on how big your buss is.
`ø,,ø!
36 Bits: Fortran made them do it (Score:2)
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...
Re:Hooray for sarcasm (Score:2)
SIXBIT anyone? (Score:2)
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!
--
Re:so, why 36? (Score:2)
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!!
Re:What's up with this topic? (Score:2)
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'
Re:36bit architecture (Score:2)
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!
Re:That's not even that weird (Score:2)
Where will it all end?
Re:You're not fooling me! (Score:2)
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
Skr1pt k1dd33z in the '70s! (Score:2)
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.
Ah, those were the days... (Score:2)
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
the driving factor is C/C++ (Score:2)
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.
Re:User Friendliness (Score:2)
Any system one doesn't know well appears "user unfriendly". That's true for mainframes, UNIX machines, Windows, and even the Macintosh.
And to get good at any system requires quite a bit of effort. The only area systems like Macintosh differ in is that they make it easy to get started (good for sales and motivation). Once you are over the initial hump, they are as complex as everything else.
Of course, some systems really do suck, even when you know them well...
Re:36 bit? Sounds as kludgy as 53 bit ATM (Score:2)
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.
Re:User Friendliness (Score:2)
As someone who has used TOPS, I appreciated the hand it held out to new users. But once you got a little below the surface, I found it was the same as any other system: where it was simple it was simple because it was limited, and where it wasn't limited, it was as complex as anything else. I didn't think it was significantly better overall than UNIX.
Re:36bit architecture (Score:2)
byte? 8 bits? (Score:3)
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 . .
You're not fooling me! (Score:3)
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!
What a great read (Score:3)
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.
36bit architecture (Score:5)
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