Slashdot Mirror

Or an OS inheriting some ideas and design characteristics from Mica, Mica being an OS that inherited some ideas and design characteristics from VMS - not surprisingly, given that Cutler was involved with all three.

For those curious about the machine, here's the manual.

What defines the bit width of an instruction set isn't connected to data bus width, as different implementations of the same instruction can have different data bus widths.

That's news to me. When I doing electronics as a teenager in the 1980's, an 8-bit processor had eight data lines, a 16-bit processor had 16 data lines, and a 32-bit processor had 32 data lines. I recently saw a 64-bit microcontroller that implemented one-half of the data bus (32 bits) as four 8-bit serial ports (four pins). I'm not sure if that's a four-bit or two-bit design.

Again, there's the width of the processor's external bus, the width of the processor's internal signal paths, and the width of the registers and instructions of the instruction set the processor implements. Nothing ties the first two of those to the third of those, as evidenced by various models of the System/360 series (the I/O interface had 8 "bus in" lines, 8 "bus out" lines, and various control lines; the processors had internal signal paths ranging from 8 to 32 bits for integer and address operations; the instruction set had 32-bit general-purpose registers and arithmetic instructions and 24-bit physical addresses), the Motorola 68000 series (the 68000 and 68010 had a 24-bit address bus and a 16-bit data bus, and a 16-bit ALU for data operations; the instruction set had 32-bit registers and arithmetic instructions and 24-bit physical addresses, extended to 31-bit physical addresses with the 68012 and 32-bit physical addresses with the 68020 and subsequent processors, which had 32-bit internal data paths), and the 8086/8088 and 80186/80188 (same processor core in the 86 and 88 variants, just a different external bus; the instruction set had 16-bit registers and arithmetic instructions).

It's about more than just the electronics; it's about the software, and that mainly involves the instruction set, with the external and internal data widths being a performance issue rather than a pure functionality issue.

So, from the 1960's (and maybe earlier) to the present day, you could, for example, have a processor with an 8-bit data bus and 16-bit, 32-bit, or 64-bit registers and arithmetic instructions and 16-bit, 24-bit, 32-bit, and 64-bit physical/virtual addresses.

The 8088 was a processor with an 8-bit data bus and everything else 16-bit; as Intel's manual says, "The 8086 and 8088 are closely related third- generation microprocessors. The 8088 is designed with an 8-bit external data path to memory and I/O, while the 8086 can transfer 16 bits at a time. In almost every other respect the processors are identical; software written for one CPU will execute on the other without alteration." They also note that "The high performance of the 8086 and 8088 is realized by combining a 16-bit internal data path with a pipelined architecture that allows instructions to be prefetched during spare bus cycles.", so both are internally 16-bit implementations of the 16-bit instruction set.

What defines the bit width of an instruction set isn't connected to data bus width, as different implementations of the same instruction can have different data bus widths.

That's news to me. When I doing electronics as a teenager in the 1980's, an 8-bit processor had eight data lines, a 16-bit processor had 16 data lines, and a 32-bit processor had 32 data lines. I recently saw a 64-bit microcontroller that implemented one-half of the data bus (32 bits) as four 8-bit serial ports (four pins). I'm not sure if that's a four-bit or two-bit design.

Again, there's the width of the processor's external bus, the width of the processor's internal signal paths, and the width of the registers and instructions of the instruction set the processor implements. Nothing ties the first two of those to the third of those, as evidenced by various models of the System/360 series (the I/O interface had 8 "bus in" lines, 8 "bus out" lines, and various control lines; the processors had internal signal paths ranging from 8 to 32 bits for integer and address operations; the instruction set had 32-bit general-purpose registers and arithmetic instructions and 24-bit physical addresses), the Motorola 68000 series (the 68000 and 68010 had a 24-bit address bus and a 16-bit data bus, and a 16-bit ALU for data operations; the instruction set had 32-bit registers and arithmetic instructions and 24-bit physical addresses, extended to 31-bit physical addresses with the 68012 and 32-bit physical addresses with the 68020 and subsequent processors, which had 32-bit internal data paths), and the 8086/8088 and 80186/80188 (same processor core in the 86 and 88 variants, just a different external bus; the instruction set had 16-bit registers and arithmetic instructions).

It's about more than just the electronics; it's about the software, and that mainly involves the instruction set, with the external and internal data widths being a performance issue rather than a pure functionality issue.

So, from the 1960's (and maybe earlier) to the present day, you could, for example, have a processor with an 8-bit data bus and 16-bit, 32-bit, or 64-bit registers and arithmetic instructions and 16-bit, 24-bit, 32-bit, and 64-bit physical/virtual addresses.

The 8088 was a processor with an 8-bit data bus and everything else 16-bit; as Intel's manual says, "The 8086 and 8088 are closely related third- generation microprocessors. The 8088 is designed with an 8-bit external data path to memory and I/O, while the 8086 can transfer 16 bits at a time. In almost every other respect the processors are identical; software written for one CPU will execute on the other without alteration." They also note that "The high performance of the 8086 and 8088 is realized by combining a 16-bit internal data path with a pipelined architecture that allows instructions to be prefetched during spare bus cycles.", so both are internally 16-bit implementations of the 16-bit instruction set.

I'm sure you're right, though they have something to do with micokernels. There was Linus interview from a few years back explaining his preference for the monolithic approach, and he explained that modules were introduced to give most of the benefits of the microkernel, without the drawbacks.

I'd have to see that interview to believe that's exactly what he said. In this essay by him, he says

With the 2.0 kernel Linux really grew up a lot. This was the point that we added loadable kernel modules. This obviously improved modularity by making an explicit structure for writing modules. Programmers could work on different modules without risk of interference. I could keep control over what was written into the kernel proper. So once again managing people and managing code led to the same design decision. To keep the number of people working on Linux coordinated, we needed something like kernel modules. But from a design point of view, it was also the right thing to do.

but doesn't at all tie that to microkernels.

Loadable kernel modules in UN*Xes date back at least to SunOS 4.1.3 and AIX 3.0 in the early 1990's. I'm not sure they were introduced to compete with microkernels.

Not the production process so much as the design process. It'd mean starting over from scratch with a whole new architecture, redoing decades of work in hardware and software.

Presumably the hardware and software to which you're referring is the hardware to manufacture the chips and the software used to design them, considering that the asynchronous processor that was "faster (~3x) and consume less energy (~2x)" was an "asynchronous, Pentium-compatible test chip that ran three times as fast, on half the power, as its synchronous equivalent.", so the asynchronous processors themselves don't have to have a shiny new instruction set architecture. (The original PDP-10 KA10 processor was asynchronous - "[the arithmetic processor] operates asynchronously using hardware subroutines, whereby the start of each operation is triggered by the completion of the previous operation rather than by a trigger from a synchronous timing chain" - but the KS10 was a synchronous microcoded machine using AMD 2900 bit-slices.)

Not the production process so much as the design process. It'd mean starting over from scratch with a whole new architecture, redoing decades of work in hardware and software.

Presumably the hardware and software to which you're referring is the hardware to manufacture the chips and the software used to design them, considering that the asynchronous processor that was "faster (~3x) and consume less energy (~2x)" was an "asynchronous, Pentium-compatible test chip that ran three times as fast, on half the power, as its synchronous equivalent.", so the asynchronous processors themselves don't have to have a shiny new instruction set architecture. (The original PDP-10 KA10 processor was asynchronous - "[the arithmetic processor] operates asynchronously using hardware subroutines, whereby the start of each operation is triggered by the completion of the previous operation rather than by a trigger from a synchronous timing chain" - but the KS10 was a synchronous microcoded machine using AMD 2900 bit-slices.)

There's a lot of merit in this story I think, but ultimately it muddies the waters. Certainly, it's claim that government-funded research played a less than key role in the development of internetworking seems to be just plain false.

First of all, the work Xerox did that most resembles the Internet protocols was not Ethernet, but PARC Universal Packet (PUP), which is indeed quite directly comparable to the IP in TCP/IP. Ethernet, while a terrific piece of work, mostly served to facilitate networking within a single site.

The article also says implies that the Government-funded ARPANET wasn't really the precursor of the Internet. I think that's an over-simplification. Arpanet wasn't the very first packet switching network (see the work of Baran and Davies), and it certainly wasn't an Internet (network of networks), but it really was the direct antecedent of the Internet as we know it. Arpanet connected universities and other research establishments. It proved the viability of a packet-switching network with all the application smarts at the periphery of the network. In almost all cases, what had been Arpanet connections among the early sites evolved (sometimes by way of NSFnet) to TCP/IP Internet connections, running essentially the same applications and services. So, in all those ways, Arpanet was a crucial step on the way to our TCP/IP-based Internet, and of course, ARPANET was government funded.

A much less sensationalist but much more balanced history of all this can be found at: http://www.nethistory.info/History%20of%20the%20Internet/origins.html . The record there strongly suggests that Bob Kahn and Vint Cerf were discussing approaches to internetworking (connecting networks) in spring of 1973. Interestingly, the official PARC Research Report on PUP actually cites the Internet work of Cerf and Kahn, specifically their 1974 A Protocol for Packet Network Intercommunication.

So, the government-funded work on internetworking seems to have started before the Xerox work, and the Xerox research time explicitly cited Cerf and Kahn as sources of inspiration for the Xerox work on internetworking. Wouldn't it be nice of the WSJ article made all that clear before everyone started using these over simplifications to prove the futility of government-funded research?

Windows NT and OS/2 are more similar than Windows NT and VMS.

In some ways, yes, but, for example, the lowest-level I/O architecture for NT is rather VMS-like (or perhaps rather Mica-like, although the obvious Mica documents don't describe whether it had the same I/O Request Packet-based model as VMS).

There has never been a source compatibility or easy conversion capability with VMS and RMS.

Cutler wasn't working for DEC any more, so there was no need for that. Internal design concepts, however, were reused.

Some small corrections:

Data General Nova machines were popular at Xerox PARC before the Alto was developed, so one of the various instruction sets that the Alto supported was that of the Nova allowing old software to be easily ported to the new machine. Other than that, there was no relation between Xerox and Data General.

While the Alto and its successors (including the Star and specially the Dorado) were very expensive, there was the Notetaker project that would have had a huge impact if it had been released. Imagine a $3000 machine in 1979 like the future Compaq portable but with a mouse and GUI. Don't pay attention to what the Wikipedia or the Computer History Museum say about the machine, by the way, but look at the original documents instead:

http://bitsavers.org/pdf/xerox/notetaker/

The original plan was to create a Xerox microprocessor compatible with the Alto and use two 8086 for I/O. Imagine how cool that would have been! But the group was forbidden to do their own chips, though there was a division of PARC for doing just that. So the design was changed to three 8086s instead. And as neat as this was, there were plans for a cost reduced Notetaker 2. An executive flew from the east coast specially to kill the project and make sure it really died because the board had decided to keep Xerox outside of the silly microcomputer business. They changed their minds a little later and gave us a Z80 CP/M machine after IBM came out with their PC.

The only good thing about this was that the Notetaker's designer, Douglas Fairbairn, was so upset over the cancellation that he left PARC and founded VLSI Technology Inc. (VTI) which made possible for small companies to design their own chips. Like Acorn and their ARM.

Multics also had hexadecimal access control: read, execute, write, append.

But it didn't have "4 hexadecimal modes", it had ACLs - and, at least according to the 1975 Multics Programmer's Manual Reference Guide, they're read/execute/write/deny-everything for segments and status/modify/append/deny-everything for directories.

very influential programming book...

Hell, I've used languages where the statement separator was a 12-11-0-7-8-9 punch.

Neat. Thanks for the history lesson (via google).

http://www.bitsavers.org/pdf/ibm/27xx/GA27-3005-3-2780_Data_Terminal_Description_Aug71.pdf

all the meaningful combinations are on pages 10-13. EBCDIC had various combinations involving zero to six punches, you'd have to backspace and overpunch for many of them.

My university got rid of the keypunches, readers, verifiers and sorters my sophomore year, 1983; I had used them to help my roommate who was poor typist, he had an intro to computer class of some sort as a requirement for his Business Management degree and had to write some COBOL programs of a few dozen lines. Funny to check his logic he would lay the card in a line on the floor, with "branches" and "loops" looking like spurs on a model railroad.

More importantly, Bitsavers, an archive or historical technical data,is down, and has been down for days. That site would be a major loss; they have copies of rare documents not available elsewhere. Anyone know what's going on there?

I have no idea on the cause for this outage, but Al Kossow, who founded and still runs bitsavers, is also the software curator for the Computer History Museum. Given their purpose, I'd imagine that any problem with bitsavers would be a high priority for them. I found a brief posting he made today on ba.broadcast.moderated, so it's not like he's out of commission or anything. Most likely it's just a technical problem which will eventually be cleared up.

I tried checking the classiccmp mailing list, which would be the most obvious place to discuss any bitsavers outage, but their site is currently down too. *headdesk*

Did anybody check this? As of right now, thepiratebay.org's home page is up.

More importantly, Bitsavers, an archive or historical technical data,is down, and has been down for days. That site would be a major loss; they have copies of rare documents not available elsewhere. Anyone know what's going on there?

According to a 1981 dated Users Guide document.

http://www.bitsavers.org/pdf/cdc/plato/97405900C_PLATO_Users_Guide_Apr81.pdf

``AIDS is an on-line reference manual for authors and instructors, which contains definitions and explanations of most of the PLATO system features.'' [4-5]

Well, DEC's PDP-1 sales literature (such as the PDP-1 Handbook scans available here) seems to always list the display among the optional equipment, though it was probably a popular option. The only standard I/O equipment (not counting the front panel) was the console typewriter and the paper tape reader and punch. Seems reasonable, since I'm sure there were some customers who had no need for a CRT.

However, I overstated things when I said the display "would have added quite a bit to the cost". It only seems to have increased the cost by around 15% or so.

The Xerox Alto did not do what you think it did. Perhaps you have it confused with the Xerox Star which came later.

Download the Alto User Handbook and see for yourself.

The Alto had a command line interface and commands were largely entered through the keyboard.

As I mentioned before, people who claim that the Macintosh was a copy of the Alto VERY obviously do not have a clue as to how the Alto actually worked.

The Alto had more similarities with MS-DOS than with a Mac when it came to things like file manipulation or starting programs. You literally did that stuff with a command line on the Alto.

There was none of that double clicking an icon to start a program. On the Alto, you had to type in the program name from the command line to start it if it was on the local disk, or start a separate network aware command line interface if the program was located on a file server.

There was none of that dragging and dropping file, folder and disk icons to manipulate the file system as was pioneered on the Mac. You had to type out copy commands just like you were running DOS.

The Alto also required an endless stream of keyboard commands to get much of anything done in it's programs. For instance, to open a document in the included Bravo word processor, type G (for get), then type in the path to the file you want to open then it's file name and extension, then hit the Escape key.

Happily, this being the internet you can download a copy of the Xerox PARC Alto Users Handbook and see for yourself how incredibly unlike the Macintosh an Alto really was.

Linux and the BSDs have pretty much made UNIX obsolete.

I don't know about Linux, but BSD definitely contained Unix code from USL, and vice-versa. They settled out of court. Should ever SCO decided to go after BSD, it would open a big can of worms. More details can be found in The Unix Heritage Society and Bitsavers Archives.

I think this is in bit heaven.
http://www.bitsavers.org/pdf/harris/brochures/Harris_Systems_Brochure_Nov81.pdf

regarding a 'History of the UNIX kernel' class, check out http://bitsavers.org/pdf/bellLabs/unix/ it has some interesting documents about the and unix kernel and some of the listings are being used as part of the current effort to resurrect the very early unix (ie v1 etc) also theres always lions commentary to be found on the net at http://www.lemis.com/grog/Documentation/Lions/

This should be helpful to whoever (and surely someone will) wants to build an emulator. This is a PDF of the processor manual from 1985. The processor features sounds awfully advanced for 1985. Pipelining (they call it overlapping instruction execution), instruction caching, memory protection... Sweet! I want one...

Nope. The I/O hardware that the Level/68 system used was an extremely complex independent beast. (Think of SCSI (small computer systems interconnect) on steroids... since, uhh, Multics wasn't a "small computer system," but quite the opposite.) The documentation that survives is widely scattered; the few (insufficient) pieces that have been scanned and can be found on the web are at bitsavers. Much will likely have to be reverse-engineered.

I've been working on an emulator for a number of years. This article very good news, because it will make it easier for other people to get involved. (Note: don't bother trying to play with the emulator, because it is very... non-functional thus far. If you're interested in helping out, please do read everything at multicians.org, start following alt.os.multics, skim through everything on bitsavers, and then drop me a line *grin*).

Most of the technology we enjoy today can only be produced via huge infrastructures made possible by large, advanced, stable societies. This project shows that fundamental computing technology can be reproduced with relative ease on a very small scale with limited resources.

Yeah, well, keep in mind that when you know how to build a simple TTL chip it isn't much harder to develop a good integration technique that can allow you to build more complex circuits. Not knowing enough semiconductor physics and applied chemistry to actually build any kind of integrated circuits is a whole other ball game.

Of course, there are other technologies to build a working digital computer. A great example is here. A bit basic, but, hell, who can say he built a computer out of paper clips :)

It's not a longstanding history. It started in mid-1990s. In the early 1990s, if you bought a 300 MB drive, you got 300*1024^2 = 314,572,800 bytes

I think Jobs saw Smalltalk running on the Star which was introduced in 1981.

Well, you think wrong: From the transcript of "Triumph Of The Nerds Part III":

"Steve Jobs had co-founded Apple Computer in 1976. The first popular personal computer, the Apple 2, was a hit - and made Steve Jobs one of the biggest names of a brand-new industry. At the height of Apple's early success in December 1979, Jobs, then all of 24, had a privileged invitation to visit Xerox Parc.

Steve Jobs

And they showed me really three things. But I was so blinded by the first one I didn't even really see the other two. One of the things they showed me was object orienting programming they showed me that but I didn't even see that. The other one they showed me was a networked computer system...they had over a hundred Alto computers all networked using email etc., etc., I didn't even see that. I was so blinded by the first thing they showed me which was the graphical user interface. I thought it was the best thing I'd ever seen in my life. Now remember it was very flawed, what we saw was incomplete, they'd done a bunch of things wrong. But we didn't know that at the time but still though they had the germ of the idea was there and they'd done it very well and within you know ten minutes it was obvious to me that all computers would work like this some day.

It was a turning-point. Jobs decided that this was the way forward for Apple.

Adele Goldberg

Founder, PARC Place Systems

He came back and I almost said asked, but the truth is, demanded that his entire programming team get a demo of the Smalltalk System and the then head of the science centre asked me to give the demo because Steve specifically asked for me to give the demo and I said no way. I had a big argument with these Xerox executives telling them that they were about to give away the kitchen sink and I said that I would only do it if I were ordered to do it cause then of course it would be their responsibility, and that's what they did."

What Steve and his folks saw looked like this.

Yes, you are absolutely right. But somehow Bill Gates managed to convince people that it was OK to copy the Mac GUI, because "Apple stole it before".

Before Apple, the GUI looked something like this (PDF). No bar with drop-down-menus, no icons for files, instead rather for actions, no desktop metaphor, no trashcan. Maybe Steve and his team got to see an even more low key version.

Of course, back then engineers went from Xerox to Apple and took some ideas with them. I guess they even talked to their ex-colleagues and exchanged ideas. It was before software patents.

Bill Gates on the other Hand saw the Mac because his company was to be an important 3rd party developer for the platform. And he is quoted, when asked by his engineers in which direction Microsofts GUI efforts should go, as saying: "I want the Mac". He then got Ex-Xeros Employees too and the Macs icon designer Susan Kare did artwork for Windows 95.

"... the computer that INVENTED the modern GUI, the Xerox Alto..."

Before Apple, the GUI looked something like this. No bar with drop-down-menus, no icons for files, instead rather for actions, no desktop metaphor, no trashcan.

"...the Alto which gave us the WIMP interface..."

Meh, before Steves team got on it the GUI looked something like this. No bar with drop-down-menus, no icons for files, instead rather for actions, no desktop metaphor, no trashcan ...

Merom is a major revision of Yonah, but is derived from the same code base. In fact, it is still technically a derivative of the P6 family that began with the Pentium Pro 10 years ago.

To those of us old enough to remember, it looks more like part of the family that started with the CDC 6600 over 40 years go. :-) For anybody who cares to look, Design of a Computer: The CDC 6600 (Warning: PDF), describes what may well be the greatest microarchitecture ever. It's by Jim Thornton, who was (to quote Seymour Cray): "personally responsible for most of the detailed design of the Control Data model 6600 system."

Those who look through this book may also note a decided resemblance between the original Pentium and the CDC 6500 (which it also discusses to some degree).

See the PDP-11 Handbook (1979) for instruction timings.

They also made a computer, the PB 250.

The original manual can be found at bitsavers.org.

and if you wanted to use the opcodes for multiplication and division you had to load the lookup tables into 300 digit area from 00100 to 00399. System manual is here I wish I could find the book "Programming the IBM 1620, a hands-on approach", it's what turned me on to computing.