29 Oct
2018
29 Oct
'18
9:56 a.m.
the i860 found at least a little niche on graphics
boards, so somehow
not a complete failure ;-)
I'd be mildly surprised if Intel ever made enough from selling i860s
as GPUs to cover the cost of developing and marketing them. At the
time, Intel was pushing them as their RISC processor, and put a lot
into the program. Going to take over the world and all that. Maybe
not a 'complete' failure...just mostly.
From: Chuck Guzis <cclist at sydex.com>
On 10/26/18 6:10 AM, Gordon Henderson via cctalk
wrote:
It wasn't fun for the whole 2 weeks. And the i860 is Yet Another
example of Intel claiming their compilers were going to be so smart
that all the architectural complexity/warts will never be noticed.
Wrong, and they didn't learn and said the same thing about Itanium.
The interrupt stall issue that Gordon pointed out was so bad they were
basically relegated to single-task software in the end.
KJ
However it was a royal PITA to code for although
a 32-bit CPU, it would
read memory 64 bits at a time (actually 128 IIRC to satisfy the cache),
with half that 64-bit word being an instruction for the integer unit and
half for the floating point unit, so you effectively had to build a
floating point pipeline by hand coded instructions, so 8 (I think)
instructions to load the pipeline, then each subsequent instruction
would feed another value into the pipe, then another 8 at the end to
empty it. Great for big matrix operations, rubbish for a single add of 2
FP numbers.
My impression of the i860 was that it might have been fun for about 2
weeks for which to code assembly, but after that, you'd really start
looking hard for an HLL to do the dirty work for you. While there's a
sense of accomplishment over looking at a page of painfully
hand-optimized code that manages to keep everything busy with no
"bubbles", you begin to wonder if there isn't a better way to spend your
life. 
29 Oct
29 Oct
11:12 a.m.
I know i960 is a very different beast, but was there ever any high level
OSs that ran on it? Or was it pidgin-holed as a high speed embedded
processor for storage controllers and NICs?
I picked up a cache of i960 CPUs a couple years ago and they speak to me
in tongues every time I pass by the shelf.
-Alan
On 2018-10-29 12:56, Ken Seefried via cctalk wrote:
the i860 found
at least a little niche on graphics boards, so somehow
not a complete failure ;-)
I'd be mildly surprised if Intel ever made enough from selling i860s
as GPUs to cover the cost of developing and marketing them. At the
time, Intel was pushing them as their RISC processor, and put a lot
into the program. Going to take over the world and all that. Maybe
not a 'complete' failure...just mostly.
From: Chuck Guzis <cclist at sydex.com>
On 10/26/18 6:10 AM, Gordon Henderson via cctalk
wrote:
It wasn't fun for the whole 2 weeks. And the i860 is Yet Another
example of Intel claiming their compilers were going to be so smart
that all the architectural complexity/warts will never be noticed.
Wrong, and they didn't learn and said the same thing about Itanium.
The interrupt stall issue that Gordon pointed out was so bad they were
basically relegated to single-task software in the end.
KJ However it was a royal PITA to code for although
a 32-bit CPU, it
would
read memory 64 bits at a time (actually 128 IIRC to satisfy the
cache),
with half that 64-bit word being an instruction for the integer unit
and
half for the floating point unit, so you effectively had to build a
floating point pipeline by hand coded instructions, so 8 (I think)
instructions to load the pipeline, then each subsequent instruction
would feed another value into the pipe, then another 8 at the end to
empty it. Great for big matrix operations, rubbish for a single add
of 2
FP numbers.
My impression of the i860 was that it might have been fun for about 2
weeks for which to code assembly, but after that, you'd really start
looking hard for an HLL to do the dirty work for you. While there's a
sense of accomplishment over looking at a page of painfully
hand-optimized code that manages to keep everything busy with no
"bubbles", you begin to wonder if there isn't a better way to spend
your
life. 
12:32 p.m.
They were used in some X terminals, so there were at least high level enough operating
systems to support an X11 server.
-- Chris
On Oct 29, 2018, at 11:12 AM, alan--- via cctalk
<cctalk at classiccmp.org> wrote:
I know i960 is a very different beast, but was there ever any high level OSs that ran on
it? Or was it pidgin-holed as a high speed embedded processor for storage controllers and
NICs?
I picked up a cache of i960 CPUs a couple years ago and they speak to me in tongues every
time I pass by the shelf.
-Alan
On 2018-10-29 12:56, Ken Seefried via cctalk wrote:
>> the i860 found at least a little niche on graphics boards, so somehow
>> not a complete failure ;-)
> I'd be mildly surprised if Intel ever made enough from selling i860s
> as GPUs to cover the cost of developing and marketing them. At the
> time, Intel was pushing them as their RISC processor, and put a lot
> into the program. Going to take over the world and all that. Maybe
> not a 'complete' failure...just mostly.
> From: Chuck Guzis <cclist at sydex.com>
>> On 10/26/18 6:10 AM, Gordon Henderson via cctalk wrote:
>>> However it was a royal PITA to code for although a 32-bit CPU, it would
>>> read memory 64 bits at a time (actually 128 IIRC to satisfy the cache),
>>> with half that 64-bit word being an instruction for the integer unit and
>>> half for the floating point unit, so you effectively had to build a
>>> floating point pipeline by hand coded instructions, so 8 (I think)
>>> instructions to load the pipeline, then each subsequent instruction
>>> would feed another value into the pipe, then another 8 at the end to
>>> empty it. Great for big matrix operations, rubbish for a single add of 2
>>> FP numbers.
>> My impression of the i860 was that it might have been fun for about 2
>> weeks for which to code assembly, but after that, you'd really start
>> looking hard for an HLL to do the dirty work for you. While there's a
>> sense of accomplishment over looking at a page of painfully
>> hand-optimized code that manages to keep everything busy with no
>> "bubbles", you begin to wonder if there isn't a better way to spend
your
>> life.
> It wasn't fun for the whole 2 weeks. And the i860 is Yet Another
> example of Intel claiming their compilers were going to be so smart
> that all the architectural complexity/warts will never be noticed.
> Wrong, and they didn't learn and said the same thing about Itanium.
> The interrupt stall issue that Gordon pointed out was so bad they were
> basically relegated to single-task software in the end.
> KJ
2:12 p.m.
On Mon, Oct 29, 2018 at 12:13 PM alan--- via cctalk <cctalk at classiccmp.org>
wrote:
I know i960 is a very different beast, but was there
ever any high level
OSs that ran on it?
It was originally the BiiN processor, and ran the Osiris operating system.
However, few if any were sold, and it disappeared without a trace, leading
to BiiN being retronym'd "Billions invested in Nothing".
The i960 was how Intel repositioned it to try to salvage as much as
possible. Most i960 variants either don't have the tag bit hardware and
object-oriented "microcode" that was used for BiiN; it is only officially
present in the i960MX, but might also be in the i960MC. I think only the MX
and MC have an MMU.
It should be possible to port {Unix,xBSD,Linux} to the i960MC, but I don't
think anyone has.
2:20 p.m.
On Oct 29, 2018, at 5:12 PM, Eric Smith via cctalk
<cctalk at classiccmp.org> wrote:
The i960 was how Intel repositioned it to try to salvage as much as
possible. Most i960 variants either don't have the tag bit hardware and
object-oriented "microcode" that was used for BiiN; it is only officially
present in the i960MX, but might also be in the i960MC. I think only the MX
and MC have an MMU.
I used an i960 at Chipcom. At this point, the only thing I remember is a very awful I/O
architecture. It felt a bit like the seriously broken architecture of the 82586 Ethernet
chip. (Yes, it's possible to design a queue based I/O architecture that is correct;
Dijkstra did so in the Electrologica X8. But Intel was clearly clueless about making
distributed algorithms work.)
paul
8:43 p.m.
I'm aware of some airborne (avionics) computers that used i960s. There
were Mil-spec versions available.
I believe the i960 really only found a niche in embedded applications.
If I recall correctly, the i960 became available at about the same time
as the 80386 but was less expensive. At the time, you couldn't afford
to put a 80386 in an embedded application because Intel was getting
artificially high prices due to PC-based pricing.
Intel later tried to address the embedded market pricing issues by
releasing the 80376 and later the 80386EX. Both those products were
munged so they couldn't run DOS and that kept their pricing model intact.
The i960 did have a user mode and supervisor mode - so it could have
supported a 'real' OS.
Rob.
On 10/29/2018 11:12 AM, alan--- via cctalk wrote:
I know i960 is a very different beast, but was there ever any high level
OSs that ran on it?? Or was it pidgin-holed as a high speed embedded
processor for storage controllers and NICs?
I picked up a cache of i960 CPUs a couple years ago and they speak to me
in tongues every time I pass by the shelf.
-Alan
On 2018-10-29 12:56, Ken Seefried via cctalk wrote:
the i860
found at least a little niche on graphics boards, so somehow
not a complete failure ;-)
I'd be mildly surprised if Intel ever made enough from selling i860s
as GPUs to cover the cost of developing and marketing them.? At the
time, Intel was pushing them as their RISC processor, and put a lot
into the program.? Going to take over the world and all that.? Maybe
not a 'complete' failure...just mostly.
From: Chuck Guzis <cclist at sydex.com>
On 10/26/18 6:10 AM, Gordon Henderson via cctalk
wrote:
It wasn't fun for the whole 2 weeks.? And the i860 is Yet Another
example of Intel claiming their compilers were going to be so smart
that all the architectural complexity/warts will never be noticed.
Wrong, and they didn't learn and said the same thing about Itanium.
The interrupt stall issue that Gordon pointed out was so bad they were
basically relegated to single-task software in the end.
KJ However it was a royal PITA to code for although
a 32-bit CPU, it would
read memory 64 bits at a time (actually 128 IIRC to satisfy the cache),
with half that 64-bit word being an instruction for the integer unit
and
half for the floating point unit, so you effectively had to build a
floating point pipeline by hand coded instructions, so 8 (I think)
instructions to load the pipeline, then each subsequent instruction
would feed another value into the pipe, then another 8 at the end to
empty it. Great for big matrix operations, rubbish for a single add
of 2
FP numbers.
My impression of the i860 was that it might have been fun for about 2
weeks for which to code assembly, but after that, you'd really start
looking hard for an HLL to do the dirty work for you.? While there's a
sense of accomplishment over looking at a page of painfully
hand-optimized code that manages to keep everything busy with no
"bubbles", you begin to wonder if there isn't a better way to spend your
life. 
31 Oct
31 Oct
2:27 p.m.
The i860 did find some use in the radio astronomy world.
Here's an excerpt from the 1998 annual report for the Arecibo Observatory...
--------------
Telescope pointing and realtime data acquisition are controlled using a
network of VMEbus single-board computers running the VxWorks operating
system kernel. Custom-built data acquisition devices (??backends??) include
(1) a general purpose A/D system capable of sampling four analog channels
at up to 10-MHz rates with programmable resolutions of 1 to 12 bits per
sample per channel, (2) an ~interim! 50-MHz, 4096-lag Spectral Line
Correlator with programmable bandwidth from 195 kHz to 50 MHz, (3) a 50-MHz
Radar Decoder, ~4! a 100-MHz Spectral Line Correlator being developed, (5)
a 10-MHz bandwidth Pulsar Search/Timing Machine with up to 256 channels,
and (6) a wideband continuum/polarimetry instrument being developed. An S2
VLBI system is also available. Additional realtime signal processing
capability is provided by four Skybolt i860-based VMEbus single-board
computers with 240 MFLOPS peak combined capacity.
--------------
Remember when 240 MFLOPS was a lot?
I also seem to recall that the SERENDIP III SETI spectrometer used i860 and
Austek A41102 FFT processors. I'm pretty sure SERENDIP IV used i960 and
Xylinx FPGAs to do the FFTs. I'll look at the boards tomorrow.
On Mon, Oct 29, 2018 at 9:56 AM Ken Seefried via cctalk <
cctalk at classiccmp.org> wrote:
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
the i860 found
at least a little niche on graphics boards, so somehow
not a complete failure ;-)
I'd be mildly surprised if Intel ever made enough from selling i860s
as GPUs to cover the cost of developing and marketing them. At the
time, Intel was pushing them as their RISC processor, and put a lot
into the program. Going to take over the world and all that. Maybe
not a 'complete' failure...just mostly.
From: Chuck Guzis <cclist at sydex.com>
On 10/26/18 6:10 AM, Gordon Henderson via cctalk
wrote:
It wasn't fun for the whole 2 weeks. And the i860 is Yet Another
example of Intel claiming their compilers were going to be so smart
that all the architectural complexity/warts will never be noticed.
Wrong, and they didn't learn and said the same thing about Itanium.
The interrupt stall issue that Gordon pointed out was so bad they were
basically relegated to single-task software in the end.
KJ
However it was a royal PITA to code for although
a 32-bit CPU, it would
read memory 64 bits at a time (actually 128 IIRC to satisfy the cache),
with half that 64-bit word being an instruction for the integer unit and
half for the floating point unit, so you effectively had to build a
floating point pipeline by hand coded instructions, so 8 (I think)
instructions to load the pipeline, then each subsequent instruction
would feed another value into the pipe, then another 8 at the end to
empty it. Great for big matrix operations, rubbish for a single add of 2
FP numbers.
My impression of the i860 was that it might have been fun for about 2
weeks for which to code assembly, but after that, you'd really start
looking hard for an HLL to do the dirty work for you. While there's a
sense of accomplishment over looking at a page of painfully
hand-optimized code that manages to keep everything busy with no
"bubbles", you begin to wonder if there isn't a better way to spend your
life.
2:29 p.m.
A Google search on Skybolt i860 produces interesting results.
On Wed, Oct 31, 2018 at 2:27 PM Eric Korpela <korpela at ssl.berkeley.edu>
wrote:
The i860 did find some use in the radio astronomy
world.
Here's an excerpt from the 1998 annual report for the Arecibo
Observatory...
--------------
Telescope pointing and realtime data acquisition are controlled using a
network of VMEbus single-board computers running the VxWorks operating
system kernel. Custom-built data acquisition devices (??backends??) include
(1) a general purpose A/D system capable of sampling four analog channels
at up to 10-MHz rates with programmable resolutions of 1 to 12 bits per
sample per channel, (2) an ~interim! 50-MHz, 4096-lag Spectral Line
Correlator with programmable bandwidth from 195 kHz to 50 MHz, (3) a 50-MHz
Radar Decoder, ~4! a 100-MHz Spectral Line Correlator being developed, (5)
a 10-MHz bandwidth Pulsar Search/Timing Machine with up to 256 channels,
and (6) a wideband continuum/polarimetry instrument being developed. An S2
VLBI system is also available. Additional realtime signal processing
capability is provided by four Skybolt i860-based VMEbus single-board
computers with 240 MFLOPS peak combined capacity.
--------------
Remember when 240 MFLOPS was a lot?
I also seem to recall that the SERENDIP III SETI spectrometer used i860
and Austek A41102 FFT processors. I'm pretty sure SERENDIP IV used i960
and Xylinx FPGAs to do the FFTs. I'll look at the boards tomorrow.
On Mon, Oct 29, 2018 at 9:56 AM Ken Seefried via cctalk <
cctalk at classiccmp.org> wrote:
It wasn't fun for the whole 2 weeks. And the i860 is Yet Another
example of Intel claiming their compilers were going to be so smart
that all the architectural complexity/warts will never be noticed.
Wrong, and they didn't learn and said the same thing about Itanium.
The interrupt stall issue that Gordon pointed out was so bad they were
basically relegated to single-task software in the end.
KJ
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
the i860
found at least a little niche on graphics boards, so somehow
not a complete failure ;-)
I'd be mildly surprised if Intel ever made enough from selling i860s
as GPUs to cover the cost of developing and marketing them. At the
time, Intel was pushing them as their RISC processor, and put a lot
into the program. Going to take over the world and all that. Maybe
not a 'complete' failure...just mostly.
From: Chuck Guzis <cclist at sydex.com>
On 10/26/18 6:10 AM, Gordon Henderson via cctalk
wrote:
> However it was a royal PITA to code for although a 32-bit CPU, it would
> read memory 64 bits at a time (actually 128 IIRC to satisfy the cache),
> with half that 64-bit word being an instruction for the integer unit
and
> half for the floating point unit, so you
effectively had to build a
> floating point pipeline by hand coded instructions, so 8 (I think)
> instructions to load the pipeline, then each subsequent instruction
> would feed another value into the pipe, then another 8 at the end to
> empty it. Great for big matrix operations, rubbish for a single add of
2
FP
numbers.
My impression of the i860 was that it might have been fun for about 2
weeks for which to code assembly, but after that, you'd really start
looking hard for an HLL to do the dirty work for you. While there's a
sense of accomplishment over looking at a page of painfully
hand-optimized code that manages to keep everything busy with no
"bubbles", you begin to wonder if there isn't a better way to spend your
life. 
2 Nov
2 Nov
12:15 p.m.
ons 2018-10-31 klockan 14:27 -0700 skrev Eric Korpela via cctalk:
The i860 did find some use in the radio astronomy
world.
Here's an excerpt from the 1998 annual report for the Arecibo
Observatory...
--------------
Telescope pointing and realtime data acquisition are controlled using
a
network of VMEbus single-board computers running the VxWorks
operating
system kernel. Custom-built data acquisition devices (??backends??)
include
(1) a general purpose A/D system capable of sampling four analog
channels
at up to 10-MHz rates with programmable resolutions of 1 to 12 bits
per
sample per channel, (2) an ~interim! 50-MHz, 4096-lag Spectral Line
Correlator with programmable bandwidth from 195 kHz to 50 MHz, (3) a
50-MHz
Radar Decoder, ~4! a 100-MHz Spectral Line Correlator being
developed, (5)
a 10-MHz bandwidth Pulsar Search/Timing Machine with up to 256
channels,
and (6) a wideband continuum/polarimetry instrument being developed.
An S2
VLBI system is also available. Additional realtime signal processing
capability is provided by four Skybolt i860-based VMEbus single-board
computers with 240 MFLOPS peak combined capacity.
--------------
Remember when 240 MFLOPS was a lot?
Was the 1983-84 year multibus sky floating point card the first
offering from Sky Computers ?
Did anyone use those in an embedded and online floating-point realtime
type of setting ? Or was they only used for off-line number-crunching ?
Hrrm, i now know that SKY computers had a dual-port memory system for
DEC LSI-11 computers (good if you have for example a really fast
accessory) so the FFP wasnt the first thing for them.
4:43 p.m.
Was the 1983-84 year multibus sky floating point card the first
offering from Sky Computers ?
Did anyone use those in an embedded and online floating-point realtime
type of setting ? Or was they only used for off-line number-crunching ?
Sky made the math coprocessor in early multibus and VME Sun 2 systems as
well. I'm not aware of any embedded use of Sky FFPs
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
4:56 p.m.
On Wed, Oct 31, 2018 at 2:27 PM Eric Korpela <korpela at ssl.berkeley.edu>
wrote:
I also seem to recall that the SERENDIP III SETI spectrometer used i860
and Austek A41102 FFT processors. I'm pretty sure SERENDIP IV used i960
and Xylinx FPGAs to do the FFTs. I'll look at the boards tomorrow.
I was wrong on both counts. SERENDIP III didn't have a CPU on the board,
but had a state machine on one of the FPGAs to control storage into and
retrieval from the memory. And SERENDIP IV did use the A41102 FFT
processors. Apparently, SERENDIP V.v was the first that did its FFTs in
the FPGA. Since then (SERENDIP VI) we've moved to GPUs, but that's less
than 10 years old so I shouldn't even mention it.
Here's the obligatory board porn. (Yes, SERENDIP III was wire wrap).
https://purcell.ssl.berkeley.edu/~korpela/gif/SERENDIPIII.jpg (that's the
whole thing)
https://purcell.ssl.berkeley.edu/~korpela/gif/SERENDIPIV.jpg (that's 1 of
20 boards)
2203
days inactive
2207
days old
10 comments
8 participants
participants (8)
-
alan＠alanlee.org -
cmhanson＠eschatologist.net -
korpela＠ssl.berkeley.edu -
paulkoning＠comcast.net -
radioengr＠gmail.com -
seefriek＠gmail.com -
spacewar＠gmail.com -
stefan.skoglund＠agj.net