3 ms·

In the early 90s I worked on a project that used the i860, two of them in fact. It was a terminal to display 3D graphics via the PEX protocol (https://en.wikipe

In the early 90s I worked on a project that used the i860, two of them in fact. It was a terminal to display 3D graphics via the PEX protocol (https://en.wikipedia.org/wiki/PHIGS https://en.wikipedia.org/wiki/PHIGS) One of the things I recall about the i860 is the interrupt handler was a disaster. It was possible for it to take an interrupt in a state where one couldn't just reload the state and resume. Essentially the interrupt handler would have to inspect state for the problematic condition, then simulate the instruction stream until it got back to a state which could be restored to the CPU. I was a hardware designer on the project so I didn't actually touch that code myself, but one of the software guys passed that on. I apologize to the i860 team if the story is overblown. Double checking this lore, wikipedia says a context switch took a minimum of 62 cycles and a maximum of 2000 cycles. https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860

iasay 4y ago
It's about right. I was involved in a project to get rid of an i860 design (aerospace) and replace it with a PPC design. No one had anything nice to say about 7 years of keeping an i860 design alive.
jacquesm 4y ago
Oh that sounds like a hardware bug to me, was that the intended behavior?
- jecel 4y ago
  The i860 introduced many new ideas, some that worked well and were copied and others that turned out to be unfortunate. Using wide datapaths in a single instruction/multiple data (SIMD) scheme for graphics got copied by Sparc and then the x86 and others, for example. A selling point was the floating point performance of a Cray 1, far above what other microprocessors could do. Pipelining was a key to this and, taking the RISC philosophy seriously, it was exposed to the software. The compiler had to schedule the instructions so that they didn't try to use a result from a previous instruction until the clock it finally came out of the pipeline. The problem of an interrupt is that the pipeline is full of unfinished calculations. If you know you are going to return to the same task, you just freeze the pipeline, don't using floating point inside the interrupt and then restart everything when you return you restart everything. If you are going to switch to a different task instead (Unix) then this is a really bad design. The kernel will have to manually flush the floating point pipeline to somewhere, then manually restore the pipeline for the new task and then return to it. The sequence to flush and restore the pipeline is really tricky and slow. Is it intended? In a way, yes. High performance was the highest priority for this project. If you are switching your processor among a bunch of tasks then you really don't care about performance that much, do you? Running Unix on a supercomputer should be possible, but it doesn't have to be good. As long as when you focus on a single program it goes amazingly fast.
  - jacquesm 4y ago
    Thank you for the explanation Jecel, that makes it look as though it was always destined to be in the 'coprocessor' domain. How is the Smalltalk-to-hardware project coming along?
    - jecel 4y ago
      I would say it was intended as the main processor for supercomputers. I did a design like that (though it ended up actually built with old 68020s we already had in stock to save money) and there were many others. Intel itself had some interesting machines. But Intel realized that asking customers to jump from x86 to an incompatible architecture (either the i860 or i960) was too risky - they could just as well jump to a competitor's architecture instead. So they repositioned their RISCs as coprocessors. It is amazing that they forgot this not too many years later with the Itanium. My Smalltalk processor project is going very well, though obviously this is not the place for details.

iasay 4y ago

It's about right. I was involved in a project to get rid of an i860 design (aerospace) and replace it with a PPC design. No one had anything nice to say about 7 years of keeping an i860 design alive.

jacquesm 4y ago

Oh that sounds like a hardware bug to me, was that the intended behavior?

jecel 4y ago
The i860 introduced many new ideas, some that worked well and were copied and others that turned out to be unfortunate. Using wide datapaths in a single instruction/multiple data (SIMD) scheme for graphics got copied by Sparc and then the x86 and others, for example. A selling point was the floating point performance of a Cray 1, far above what other microprocessors could do. Pipelining was a key to this and, taking the RISC philosophy seriously, it was exposed to the software. The compiler had to schedule the instructions so that they didn't try to use a result from a previous instruction until the clock it finally came out of the pipeline. The problem of an interrupt is that the pipeline is full of unfinished calculations. If you know you are going to return to the same task, you just freeze the pipeline, don't using floating point inside the interrupt and then restart everything when you return you restart everything. If you are going to switch to a different task instead (Unix) then this is a really bad design. The kernel will have to manually flush the floating point pipeline to somewhere, then manually restore the pipeline for the new task and then return to it. The sequence to flush and restore the pipeline is really tricky and slow. Is it intended? In a way, yes. High performance was the highest priority for this project. If you are switching your processor among a bunch of tasks then you really don't care about performance that much, do you? Running Unix on a supercomputer should be possible, but it doesn't have to be good. As long as when you focus on a single program it goes amazingly fast.
- jacquesm 4y ago
  Thank you for the explanation Jecel, that makes it look as though it was always destined to be in the 'coprocessor' domain. How is the Smalltalk-to-hardware project coming along?
  - jecel 4y ago
    I would say it was intended as the main processor for supercomputers. I did a design like that (though it ended up actually built with old 68020s we already had in stock to save money) and there were many others. Intel itself had some interesting machines. But Intel realized that asking customers to jump from x86 to an incompatible architecture (either the i860 or i960) was too risky - they could just as well jump to a competitor's architecture instead. So they repositioned their RISCs as coprocessors. It is amazing that they forgot this not too many years later with the Itanium. My Smalltalk processor project is going very well, though obviously this is not the place for details.