rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) (05/06/91)
I have often heard the HP snake machines described as "not superscalar" whereas the IBM RS/6000 are generally described as "superscalar." What is it in the architectures of these two machines that supports this distinction? What are the consequences for the kinds of codes that will run efficiently (particularly in terms of floating point performance)? (P.S. could somebody email me a definition of "little endian" vs. "big endian" ? Are RS6000's, Suns and Macintoshes "big endian"? What about i860? Is it a property of the chip, or of the OS?)
prener@watson.ibm.com (Dan Prener) (05/08/91)
In article <1991May6.152803.5886@midway.uchicago.edu>, rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: |> I have often heard the HP snake machines described as "not superscalar" |> whereas the IBM RS/6000 are generally described as "superscalar." |> What is it in the architectures of these two machines that supports |> this distinction? What are the consequences for the kinds of codes |> that will run efficiently (particularly in terms of floating point |> performance)? |> |> (P.S. could somebody email me a definition of "little endian" vs. |> "big endian" ? Are RS6000's, Suns and Macintoshes "big endian"? |> What about i860? Is it a property of the chip, or of the OS?) Although one could concoct counterexamples, as normally used today "superscalar" and "superpipelined" describe machine implementations, not architectures. ------------------------------ A brief characterization of "little/big endian" is the following. Suppose your machine computes the (hex) integer 0x12345678 in a 32 bit register. And suppose it then stores the contents of that register into bytes zero through three in memory. If the byte at memory location zero contains 0x12, it is a big-endian machine. If the byte at location zero contains 0x78, it is a little-endian machine. As usual this is oversimplified. The full truth is more complicated and considerably uglier. -- Dan Prener (prener @ watson.ibm.com)
martin@adpplz.UUCP (Martin Golding) (05/11/91)
In comp.arch you write: >P.S. could somebody email me a definition of "little endian" vs. >"big endian" ? (I tried email, and got bounced, and this was too much fun just to waste.) Careful, you're into religious mysteries here. The terms refer to the (holy) significance of bytes within larger structures (eg, words). If you have the address of say, a 32 bit word (addressed byte plus the bytes at the next three incrementing addresses) little endian means that the addressed byte is the least significant, big endian means the addressed byte is the most significant. Big endian is also referred to as "byte normal", and little endian "byte perverse" ;-) There's a subtle trick, that Motorola missed when it designed the 68000, that Real Computers have their bytes and bits in the _same_ order. The 68020 uses two different bit numbering schemes, byte perverse for the (68000 compatible) simple bit instructions and byte normal for the (68020 only) bitfield instructions, that may span bytes and words. >Are RS6000's, Suns and Macintoshes "big endian"? yes. Also HP's Precision Architecture. >What about i860? I'm not certain, but Intel does cling to their heretical ways with fanatical fervor, so the i860 is almost certainly byte perverse. >Is it a property of the chip, or of the OS? It is usually a property of the chip, BUT it can be a property of the chip that it is a property of the OS. In particular, the (Advanced Micro Devices) 29000 and the (Motorola) 88000 can be set to use either. The Motorola version of the Unix system on the 88k is byte normal. If you're interested in long and fiery discussions full of sound and fury signifying nothing, I can present the arguments for both the nonsense and correct sides of the question. BTW to save the valuable time of the people who post useful things here please email flames (?and I'll post a summary??) Martin Golding | sync, sync, sync, sank ... sunk: Dod #0236 | He who steals my code steals trash. A poor old decrepit Pick programmer. Sympathize at: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
daryl@hpcupt3.cup.hp.com (Daryl Odnert) (05/11/91)
> I have often heard the HP snake machines described as "not superscalar" > whereas the IBM RS/6000 are generally described as "superscalar." > What is it in the architectures of these two machines that supports > this distinction? First, one must be careful to distinguish between "architecture" and "implementation". "Architecture" is what the complier or assembly code writer must adhere to for correct execution of a program. "Implementation" is a particular instantiation of an architecture. There is nothing in the PA-RISC architecture which prevents a superscalar implementation from being built. However, the processor in the Snakes workstations issues only one instruction per clock cycle to either the CPU or the FPU and therefore it is not considered a superscalar implementation. If my understanding of the IBM architecture is correct, there is nothing which *requires* an RS/6000 implementation to be superscalar. > What are the consequences for the kinds of codes > that will run efficiently (particularly in terms of floating point > performance)? Consider the following equation: CPU Seconds Instructions Avg Cycles Seconds ----------- = ------------ * ----------- * --------- Application Application Instruction Cycle The main consequence (or objective) of a superscalar implementation is to significantly reduce the average cycles-per-instruction. This tends to work quite well on floating-point applications. Thus, the RS/6000 is able to achieve a floating-point SPEC ratio of >50 with a 20 MHz processor, while the HP Series 700 achieves a floating-point SPEC ratio of >70 with a 50 MHz processor. So, the IBM machine achieves about 2.5 floating-point SPECmarks per MHz, while the HP machine achieves about 1.4. Daryl Odnert daryl@hpclopt.cup.hp.com Hewlett-Packard California Language Lab
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (05/11/91)
In article <729@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: >In comp.arch you write: >>P.S. could somebody email me a definition of "little endian" vs. >>"big endian" ? > > >Careful, you're into religious mysteries here. There is nothing religious about it. It is simply a fact. The terms refer to the >(holy) significance of bytes within larger structures (eg, words). >If you have the address of say, a 32 bit word (addressed byte plus >the bytes at the next three incrementing addresses) little endian >means that the addressed byte is the least significant, big endian >means the addressed byte is the most significant. That is correct. >Big endian is also >referred to as "byte normal", and little endian "byte perverse" ;-) > NO!!! You have it reversed! See, there, you can get flamed too. It is easy to understand: if you have, in C, union { unsigned char c; unsigned int i; unsigned long l; } x; and the value of x.i is <= 255, then on a little endian machine, so is the value of x.c and x.l. Not so on big endian. On the other hand, ordered byte string compare instructions work properly on longs and ints on big endian but not little endian. So, without the flames, it is a tossup. Of course, about 85% of the computers in the world are little endian. Also, it is possible to design word oriented computers that simply HAVE no endianness. Doug MCDonald
sl@wimsey.bc.ca (Stuart Lynne) (05/11/91)
In article <1991May11.012649.24340@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > >In article <729@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: >>In comp.arch you write: >>>P.S. could somebody email me a definition of "little endian" vs. >>>"big endian" ? >> >> >>Careful, you're into religious mysteries here. > >There is nothing religious about it. It is simply a fact. I think it might be time to repost Danny Cohen's "ON HOLY WARS AND A PLEA FOR PEACE". It is an excellent although perhaps a bit dated overview of the subject. (It was written in 1980.) I've got a copy curtesy of John Gilmore's posting in November 1986. I think I've seen it posted at least once since but at least a year or two back. -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca