i860 SPEC-fp92/95?

Additional operating system/hardware discussion (Windows, Linux, *BSD and others)
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
Arie van Schutterhoef
Posts: 149
Joined: Sat May 07, 2005 9:58 am
Location: Over the Rainbow
Contact:

i860 SPEC-fp92/95?

Unread postby Arie van Schutterhoef » Tue Sep 25, 2007 12:43 pm

In ancient times Intel came up with their i860 RISC-processor, that was being used in those day for floating point calculations. Benchmarks were done in SPEC-fp92 and later in SPEC-fp95. It's quite easy to find these results for other processors, but apparently not for the i860. Also bad compilers didn't do it very good, as far as I have able to ascertain. Still curious about what it really was capable of.

AvS

User avatar
R-ten-K
Posts: 1889
Joined: Mon Nov 15, 2004 10:36 pm
Location: Nor Cal

Re: i860 SPEC-fp92/95?

Unread postby R-ten-K » Tue Sep 25, 2007 1:05 pm

The 860 predates those benchmarks, so I doubt there are/were many systems to able to run them since it was never really that widespread as a general purpose processor.

The peak was supposed to be 2 Mflop per Mhz, but it seems that most compilers were able to achieve less than half. 33Mhz parts were quoted at 66MFlop peak, but the best compiled results (as per linkpak) were around 28.6 Mflops.

Dunno if that helps. It was an interesting architecture none the less...
"Was it a dream where you see yourself standing in sort of sun-god robes on a
pyramid with thousand naked women screaming and throwing little pickles at you?"

kramlq
Donor
Donor
Posts: 991
Joined: Tue Sep 20, 2005 5:10 pm
Location: IRL

Re: i860 SPEC-fp92/95?

Unread postby kramlq » Tue Sep 25, 2007 3:59 pm

R-ten-K wrote:The peak was supposed to be 2 Mflop per Mhz, but it seems that most compilers were able to achieve less than half. 33Mhz parts were quoted at 66MFlop peak, but the best compiled results (as per linkpak) were around 28.6 Mflops.


Yes, in a book I read about the development of Windows NT (called Showstopper), it said the i860 was the original RISC target platform (NT = N Ten = the codename for i860), but they dropped it in favour of MIPS because the i860 compilers were terrible and the chip had many bugs.

User avatar
porter
Posts: 2917
Joined: Wed Nov 01, 2006 10:37 pm
Location: NZ

Re: i860 SPEC-fp92/95?

Unread postby porter » Tue Sep 25, 2007 5:51 pm

My favourite none-starter is the iAPX 432. I remember reading the data-sheets and how this was going to be the next big thing.....

The 68000 was so much simpler in comparison.
Land of the Long White Cloud and no Software Patents.

User avatar
R-ten-K
Posts: 1889
Joined: Mon Nov 15, 2004 10:36 pm
Location: Nor Cal

Re: i860 SPEC-fp92/95?

Unread postby R-ten-K » Tue Sep 25, 2007 6:02 pm

The 860 seems to have named 2 M$ products, the original N-ten codename was the base for Windows-NT, a version of the microarchitecture was released as the i860XP... NT, XP, coincidence? I think not, just kidding.

I think that most 80860s ended up being used as co-processors. For kernels coded by hand you could get some decent performance, it also had a few SIMD-like integer instructions which could access the wide FP registers. For a while a lot of vendors used the 860 as a base for 3D and DSP accelerators. I think the Reality Engines (1 & 2) were based around the 860. I had a NeXTDimension at some point, and that too was based on the 860. In fact I recalled that it implemented some of the renderman ops (NeXTStep used to come bundled with renderman) in HW. The chip seemed to be the basis for a lot of cool tech from the early 90s, so it always has had some sort of mystique. Too bad I gave my nextcube eons ago :-(.

I think there were a couple of vendors that released general purpose 860 systems, although I remember for a while in the late 80s seeing adverts for 486 motherboards with 860 sockets.

There was a refined version of the microarchitecture with better superscalar scheduler and some out-of-order capabilities to mitigate the performance problems due to the compiler issues. The vanilla 860 exposed the pipeline waaaay too much to the programmer since it expected the compiler to take care of a lot of the dependencies so the compiler had to be very good regarding instruction ordering. It also had a pseudo VLIW mode in which it would execute in parallel 3-instruction bundles (INT+FPADD+FPMULT), so it could also transfer the superscalar scheduling onto the compiler/programmer. In some sense the architecture was the epitome of RISC since it transferred a lot of HW complexity to the software. However, compiler technology seems to have always been at least 1 to 2 generations behind HW.

The refined architecture in-order was coupled with a x86 decoder and served as the basis for the Pentium. I was told that the Pentium was supposed to be the nail int he coffin for the x86 with the 860 family picking up the slack from then on. Ironically the 860-based Pentium performed well enough to be the nail in the coffin for the 860.
Last edited by R-ten-K on Tue Sep 25, 2007 6:04 pm, edited 1 time in total.
"Was it a dream where you see yourself standing in sort of sun-god robes on a
pyramid with thousand naked women screaming and throwing little pickles at you?"

User avatar
R-ten-K
Posts: 1889
Joined: Mon Nov 15, 2004 10:36 pm
Location: Nor Cal

Re: i860 SPEC-fp92/95?

Unread postby R-ten-K » Tue Sep 25, 2007 6:04 pm

porter wrote:My favourite none-starter is the iAPX 432. I remember reading the data-sheets and how this was going to be the next big thing.....

The 68000 was so much simpler in comparison.


A lot of the 432 ended up in parts of the 960 :-)

The 860 was the anti-432, so I guess it left *that* bad of a taste in Intel's mouth.
"Was it a dream where you see yourself standing in sort of sun-god robes on a
pyramid with thousand naked women screaming and throwing little pickles at you?"

kramlq
Donor
Donor
Posts: 991
Joined: Tue Sep 20, 2005 5:10 pm
Location: IRL

Re: i860 SPEC-fp92/95?

Unread postby kramlq » Tue Sep 25, 2007 7:21 pm

R-ten-K wrote:There was a refined version of the microarchitecture with better superscalar scheduler and some out-of-order capabilities to mitigate the performance problems due to the compiler issues. The vanilla 860 exposed the pipeline waaaay too much to the programmer since it expected the compiler to take care of a lot of the dependencies so the compiler had to be very good regarding instruction ordering. It also had a pseudo VLIW mode in which it would execute in parallel 3-instruction bundles (INT+FPADD+FPMULT), so it could also transfer the superscalar scheduling onto the compiler/programmer. In some sense the architecture was the epitome of RISC since it transferred a lot of HW complexity to the software. However, compiler technology seems to have always been at least 1 to 2 generations behind HW.

The Motorola 88000 was also supposedly a bit of a nightmare due to the pipeline being too visible at software level. Imprecise exceptions :shock: The OS writer was left to clear up the mess when handling an exception.

And parts of the above paragraph are also relevant for the Itanium, which similarly failed miserably in usurping the mighty IA-32.

When will these CPU folk learn :)

User avatar
R-ten-K
Posts: 1889
Joined: Mon Nov 15, 2004 10:36 pm
Location: Nor Cal

Re: i860 SPEC-fp92/95?

Unread postby R-ten-K » Tue Sep 25, 2007 11:52 pm

It is not the fault of the CPU guys that the software people can not "hack" it :-) (Pun intended).
"Was it a dream where you see yourself standing in sort of sun-god robes on a
pyramid with thousand naked women screaming and throwing little pickles at you?"

kramlq
Donor
Donor
Posts: 991
Joined: Tue Sep 20, 2005 5:10 pm
Location: IRL

Re: i860 SPEC-fp92/95?

Unread postby kramlq » Wed Sep 26, 2007 5:44 am

R-ten-K wrote:It is not the fault of the CPU guys that the software people can not "hack" it :-) (Pun intended).

We go into software because we don't want to deal with hardware at such an intricate level :)

The end result of an overly complicated chip that results in overly complicated compilers and OSes is that nobody buys it.
All that hard work and cleverness by the CPU guys goes to waste because they didn't know how to do a decent OS or compiler interface. Another example: Why isn't SPARC favoured by the embedded OS community.... register windows. And years later the Itanium guys decide, hey, lets throw in a register stack engine to this already overcomplicated chip**

** though admittedly they make it easier to work than a SPARC with by giving some nice instructions.

User avatar
R-ten-K
Posts: 1889
Joined: Mon Nov 15, 2004 10:36 pm
Location: Nor Cal

Re: i860 SPEC-fp92/95?

Unread postby R-ten-K » Wed Sep 26, 2007 8:25 am

Register windows are relatively transparent to the programmer, since it only takes a couple of extra instructions to manage them. And depending on how you design your stack you can ignore them altogether.

Register windows are interesting because they were something that software people came up with. They were supposed to make life easier for the compiler people as it afforded a set of global registers for functions to access. They are however a real pain in the ass to implement in HW, and they make out-of-order scheduling a nightmare.
"Was it a dream where you see yourself standing in sort of sun-god robes on a
pyramid with thousand naked women screaming and throwing little pickles at you?"

kramlq
Donor
Donor
Posts: 991
Joined: Tue Sep 20, 2005 5:10 pm
Location: IRL

Re: i860 SPEC-fp92/95?

Unread postby kramlq » Wed Sep 26, 2007 11:07 am

R-ten-K wrote:Register windows are relatively transparent to the programmer, since it only takes a couple of extra instructions to manage them. And depending on how you design your stack you can ignore them altogether.

Register windows are interesting because they were something that software people came up with. They were supposed to make life easier for the compiler people as it afforded a set of global registers for functions to access. They are however a real pain in the ass to implement in HW, and they make out-of-order scheduling a nightmare.

I think it was compiler people who came up with the idea of caching the call stack in hardware, and the CPU guys then tried it in some of the initial RISC designs.

IMHO, they are nowhere near transparent enough to justify the hassle from a software point of view:
- Register Window overflow/underflow means traps caused just by making/returning from procedure calls when nesting gets deep (which does happen - e.g. recursion, or C++ with lots of tiny wrapper functions that couldn't be optimised). Traps can be expensive both in terms of execution time and cache displacement.
- Introducing special cases to check for during critical paths like trap entry/exit. For example, checking if a trap handler is executing in the invalid window, and if it is, taking care not to clobber any registers in the current window that are also physically shared with the next window, checking the stack is resident, etc.
- SPARC would reset on detection of a nested trap (if PSR.ET still set), so you have to be very careful of things like possible page faults due to pageable/non wired stacks, or call nesting levels in the kernel (particularly when sharing the windows with user space).
- Threading libraries implemented at user level having to trap into the kernel to manipulate the register window index because it was only accessible in kernel mode. Kind of defeats some of the goals of "lightweight" user space threading. (This was fixed in SPARC v9)
- Sharing a Register Window stack between user and kernel mode means possible security issues, so any windows used have while in the kernel have to be blanked. More register windows used means more registers to clear, on a critical path.
- Slower context switching because you potentially had to save a huge register file (as many as approx 500 registers on SPARCv8) onto the stack, and restore the register file of the new thread. That is (potentially) a lot of save and restore instructions, and a lot of data flooding the cache.

User avatar
porter
Posts: 2917
Joined: Wed Nov 01, 2006 10:37 pm
Location: NZ

Re: i860 SPEC-fp92/95?

Unread postby porter » Wed Sep 26, 2007 2:02 pm

kramlq wrote:
R-ten-K wrote:... windows... nightmare.
....windows... expensive


So you don't like Windows? :)
Land of the Long White Cloud and no Software Patents.

kramlq
Donor
Donor
Posts: 991
Joined: Tue Sep 20, 2005 5:10 pm
Location: IRL

Re: i860 SPEC-fp92/95?

Unread postby kramlq » Wed Sep 26, 2007 5:04 pm

porter wrote:
kramlq wrote:
R-ten-K wrote:... windows... nightmare.
....windows... expensive


So you don't like Windows? :)


:mrgreen:

Actually, I think I am one of the few on here who actually does like Windows :shock:
As a kernel it is quite a good design compared with many others. Above the kernel - not so good.

BTW, with such a talent for quote editing and spin, you really should be working for a British tabloid, or Fox News :lol:

User avatar
R-ten-K
Posts: 1889
Joined: Mon Nov 15, 2004 10:36 pm
Location: Nor Cal

Re: i860 SPEC-fp92/95?

Unread postby R-ten-K » Thu Sep 27, 2007 7:35 pm

As far as register "windows" is concerned, it always struck me as a clear example of "What the #$#@ were they thinking?" I always get a chuckle when people complain about x86 for being so "ugly" and with a straight face say RISC like SPARC is sooo much better/beautiful. The only good side effect of the idea has been that actually it is a nice concept for fine grained (thread level not process level) SMT, as you can easily share results among threads through the global portions of the register window.

Incidentally, the group I worked for during grad school is about to release an open sourced SPARC, it should be fun to play with on an FPGA. One of these days, if I win the lottery or I get a sabbatical, I want to implement an Amiga-like chipset on FPGAs and have a nice open source CPU. Maybe play with AROS or other OS that is not YAU (Yet Another Unix). And maybe if I have time I will also implement my own language. I want to be able to build a whole computing system from the processor, to the programming model, to the OS from scratch. And do it just like I always wanted to do whenever I cursed a design at 5 am during the days of yore. Then I can die happy...
"Was it a dream where you see yourself standing in sort of sun-god robes on a
pyramid with thousand naked women screaming and throwing little pickles at you?"


Return to “Miscellaneous Operating Systems/Hardware”

Who is online

Users browsing this forum: Bing [Bot] and 1 guest