The complex history of the Intel i960 RISC processor
righto.com
righto.com
Nevertheless, there is an important point about 80960 that is not discussed at all. There still exists a legacy of 80960 that is incorporated in all modern Intel and AMD CPUs, which consists of the XADD (normally LOCK XADD) instruction.
Before 1980, the instruction sets of the CPUs included 3 kinds of atomic read-modify-write instructions (I mean dedicated atomic instructions, not just locked variants of some standard instruction with a memory operand): test-and-set (introduced by UNIVAC 1108 in 1965; e.g. Motorola MC68000 had TAS), swap (introduced by Edsger W. Dijkstra in 1971-10; e.g. Intel 8086 had it under the mnemonic LOCK XCHG) or compare-and-swap (both compare-and-swap and compare-double-and-swap were added to IBM System/370 in 1973; Motorola MC68020 added similar instructions in 1984).
The next innovation in atomic instructions happened in 1981, when Allan Gottlieb and Clyde P. Kruskal proposed the fetch-and-add operation for the NYU Ultracomputer project.
For the next few years, the fetch-and-add operation remained available just in that academic project, but then somebody decided to implement it in 80960.
Fetch-and-add was first documented publicly by Intel in early 1988, in the BiiN description, under the mnemonic ATADD (atomic add). The ATADD instruction was also supported by 80960MC and 80960KB, which were launched later in 1988.
One year later after 80960, on 1989-04-10, Intel launched the 80486 CPU, whose most important ISA enhancements over 80386 were extra atomic instructions, i.e. fetch-and-add from 80960 (LOCK XADD) and compare-and-swap from IBM and Motorola (LOCK CMPXCHG).
Since 80486, all Intel and AMD CPUs include the fetch-and-add instruction inherited from 80960 (whose origin was in the NYU Ultracomputer).
I had no idea that my Discrete Structures professor from undergrad had such a storied CV! Kruskal was one of my favorite professors. One thing that sticks in my mind about him was what he said when he got to the Honor Code section of the syllabus while going over it on the first day of class. Instead of giving us the customary speech (humorous, menacing, or otherwise) about catching students cheating in the past and their academic records being ruined he simply said "I trust you all implicitly to do the right thing" and moved on. He was a great teacher and was similarly engaging for the rest of the semester.
In the early and mid-90s, Intel was pushing their Intelligent I/O initiative (aka I2O with a subscript '2'). This had a split-driver model, the bottom half of which ran on an i960. It had no performance advantage and IHVs suspected it was an Intel plan to sell 960s and take away their secret-sauce advantages.
I2O didn't provide much advantage on 1-4 processor systems but provided much of the underpinnings for the NGIO and InfiniBand I/O model.
I suspect that some people at Intel really wanted to have IBM System/360 mainframe style I/O channels. There was the 8089 I/O coprocessor for the 8086. The iAPX 432 had a I/O coprocessor (43203) that worked with another microprocessor to act as an I/O channel. And then there was I2O, using an i960 as an I/O processor.
https://lwn.net/1998/1008/a/rms-udi.html https://lwn.net/Articles/102772/ https://lwn.net/Articles/104420/
I seem to remember HP/Boise was using a lot of the CA parts for use in printers. They had one of our emulators, and I remember that we once got a report of the emulator probe tip having caught fire (!) due a short or some such.
I enjoyed working with the CA part. I also worked with the 80960MX part. Now, that was an odd processor!
* That is, I don't remember where where I first heard it, probably a usenet post somewhere
The Macintosh at the time had the same M68000 CPU, only running at only 8 MHz and with 128 KB of RAM (or 512 KB for the Fat Mac) which was shared with screen RAM.
They ran a Unix kernel and had a very good networking stack. I believe they coded early to the emerging new TCP flow control models.
With all the interest in retro computing these days, I wish I had kept more stuff from the 80's and 90's. Here's all I have left, an i960CA-16 chip from a development board that I had replaced with an i960CF and a manual.
https://www.w6rz.net/IQ80960RXK5_2.iso
105,078,784 bytes.
No shortage of PLDs and dual port ram on there. And not one but two CL4040 encoders from C-Cube.
What was the reason for having both a i960 lacking a FPU along a probably much more powerful TMS320? Was PCI in general a weak point of the dsp chip and a strong point of the 960?
The TMS320 chip was the audio encoder and was only capable of MPEG-1 Layer 2 coding.
The i960 was primarily used for bitstream multiplexing, either Transport Stream or Program Stream. The idea was to offload the host so that you could have many encoders in a cheap PC (with a big power supply).
There has been some interest recently in the F-22 Common Integrated Processor using the i960MX, as the USAF wishes to retire older F-22 Block 20 Aircraft.
Apparently, newer F-22 Blocks use FPGAs to provide a functional soft core of the i960MX, without having to locate long obsolete chip sources for legacy avionics designed in the 80s
It was upgraded from the HAC-32 (Hughes system with the i960 MX) to PowerPC around 2002. See page I-12 of https://studylib.net/doc/11020640/navy-training-system-plan-......
How big is the die in the picture?
Ada was not originally an object-oriented language, though it eventually became so. But the 432 project predated Ada and pivoted to that language when it came out. Intel had to adapt Ada to work with objects (it was pretty close already).
An advantage of the 33 bit scheme to protect capabilities is that you can push them on the stack where they will get mixed with normal data and then pop them later such that everything still works. In the 432 style you would need two separate stacks or awkwardly work around not being able to push/pop capabilities.
The "AND NOT" instruction is interesting for using a mask to clear bits. which is why it is called "BIC" on the ARM.
While the 186 and 286 were flawed for making IBM PC compatible machines, for what they had been designed for they did a pretty good job.
PDP-11 (1970) has BIC (dst & ~src) and BIS (dst | src) as its only boolean operations with full addressing modes, plus XOR in reg<-mem form only. VAX (1977) also has only BIC, BIS, and XOR.
I remember evaluating the CA for a smaller router and found it a perfectly reasonable part/pricing especially when compared with the other options (some weird AMD 29k variant and the local reps of the Transputer cult who never accepted the non-arrival of the T9000).
This was a decidedly low budget solution, even at the time. There were also commercial offerings from vendors like Cisco and Livingston that provided a terminal server in a dedicated appliance form factor.
edit the breakout boxes look like this: https://149707953.v2.pressablecdn.com/wp-content/uploads/imp...
Personally, I'm using a Commodore A2232 seven port serial board in my Amiga 4000, which has its own 65CE02 CPU to offload work from the main CPU.
DECserver was a popular one back in the day.
https://en.wikipedia.org/wiki/DECserver
These days it might be more economical to just have something like a Raspberry Pi attached at each terminal. Then the connections to your network could all be wireless.
The rest of the university had general-purpose terminal rooms that used port concentrators. These had a rudimentary CLI that enabled the user to specify a resource to connect to, so it was sort of a circuit-switch deal. Among the resources were VAXen running BSD, VMS machines, and Annex boxes which could be used for TCP/IP connections across campus, or to the outside world. These Annex boxes were also frontends for dial-up users coming in over modems.
Eighty terminals on a single PC might have been more difficult, but by that time the computers were already networked, so it would have been cheaper to just use two PCs than to use some kind of terminal aggregator.
Usually the RS232 was just on the terminal side. Somewhere along the path it got converted to twisted pair.
All the twisted pair serial lines congregated in the server room at a punch-down box. Eighteen year old me wasn't allowed to mess with anything past that point, but from what I can remember those lines were concentrated by a multiplexer (mux) and sent on to the minicomputer.
I can't give any details about them, because well, I was a kid, and the details of what they were talking about were beyond me...
We moved to terminal servers pretty quick. These were dedicated devices that converted serial to IP (Livingston Portmasters, Xylogics Annex, Telebit Netblazers are the ones I remember working with.)
I am curious about this detail. Was this due to production line convenience, an early example of binning, or probably something else entirely?
The SB was the next version, which used the old die layout with 16-bit bus circuitry wrapped around the outside. There wasn't any Sx version that used memory management or objects, so binning doesn't explain the unnecessary circuitry here. The SB was followed by the SA, which finally threw away the unused circuitry. The layout moved a few functional blocks around, so they did some work, but for the most part the die remained the same.
My guess is that chip design was difficult and fairly manual at the time, so it was very hard and time-consuming to make different versions. By the time of the Hx and Jx versions in the mid-1990s, I think layout was much more automated. Looking at the die photos, I don't see structural consistency from one die to the next. It looks like they pushed the button and got something completely different each time.
Added basic support for i960 in ghidra. Didn't have use myself, but some of the Sega model 2 seemed interested. To some degree I think they used it for some of the House of the Dead remake
As far as the NSA, I haven't come across any mention of the NSA using the chip, but I guess that doesn't say much :-) The chip was popular with the military and it seems like to would be good for NSA-style applications (processing large quantities of data). The i960 has bit instructions that would be useful for the NSA such as scan for the most-significant set bit in a word, although I don't think it has population-count which the NSA likes.