Author: Robert Hyatt
Date: 12:47:36 10/26/01
Go up one level in this thread
On October 26, 2001 at 12:43:41, Eugene Nalimov wrote: >Bob, here you are wrong. System 360 used separate sets of integer and FP >registers. And I believe that before PCs came in it was "mainstream" by any >definition. You are right on 360... Not on Vax. Sparc. Xerox sigmas. CDCs. Crays. Etc... All of those have a set of general-purpose registers that can do either. And even the 360 didn't have a "floating point unit" in it. It executed floating point instructions right in line with all the other non-FP instructions, they just used the FP registers. Still not like the Intel box, and the internal data paths were the same since there was one "pipe" if we go so far as to call the 360 a pipelined machine.. which is a real stretch. > >On more modern architectures -- MC68k, PPC, MIPS, Alpha, ARM, etc. etc. all use >2 different set of registers -- integer and FP (of course low-end models can >have no FP unit, in this case they have not only FP registers, but also FP >instructions as well). > >Eugene > I think the trend of separate registers comes from the trend to super-scalar designs. Toss the FP instructions "over there" and don't mix them up in the integer pipes. wasn't always done like that of course... >On October 25, 2001 at 23:15:10, Robert Hyatt wrote: > >>On October 25, 2001 at 20:21:37, Tom Kerrigan wrote: >> >>>On October 25, 2001 at 18:08:07, Robert Hyatt wrote: >>> >>>>On October 25, 2001 at 13:45:05, Tom Kerrigan wrote: >>>> >>>>>On October 25, 2001 at 11:53:09, Robert Hyatt wrote: >>>>> >>>>>>For 64 bit development since mid-60's, the driving force has been a push for >>>>>>more precision in FP (64 bits) and _faster_ execution (because all 32 bit >>>>>>computers from the 60's had double-precision (64 bit FP) but it was too slow.) >>>>> >>>>>As I said in another post, FP has very little to do with the bitiness of a chip. >>>>>Everybody agrees that x86s are 32-bit, but the P4 has 128-bit wide SIMD >>>>>registers and double precision FP ALUs. >>>> >>>>That doesn't matter. _how_ do you gate the FP values around _inside_ the >>>>cpu? On 64 bit datapaths or multiplexed on 32 bit datapaths? >>> >>>64 bit busses, obviously. If you have a 64 bit reg file (well, 128 in SSE2's >>>case) and an FP ALU, cache interface, and main memory interface that are just as >>>wide or wider, why in the world would you go to the extra work of muxing 32 bit >>>values across the busses in between them? >> >>Simple. Many architectures don't have special FP registers at all. The general >>registers do either, depending on the opcode chosen. In fact, I don't know >>of any mainstream machine that does it the way Intel does, although I don't >>claim to know how they all work... >> >> >>> >>>Like I said, FP is separate from int, enough that they were usually put on >>>different chips until recently, and there's no reason why the busses on the FP >>>side of things have to be as narrow as on the int side. >>> >> >>Actually this is only true for Intel. IBM big iron, Vaxes, Sparcs, etc all >>use general-purpose registers that can hold ints or FP values. The opcodes >>control what is done to the data... >> >>Different size busses do cause problems. In the case of Intel, the CPU >>transfers 64 bits to/from memory. FP operations can starve scalar pipe >>operations for data, and vice-versa... >> >> >>>A chip with all this 64 bit stuff can still be 32 bit because the int unit still >>>drives the chip--does all the branching, addressing, blah blah blah. >>> >>>-Tom >> >>Maybe. Or maybe there is no separation between FP and int instructions at >>all. That is really an intel-approach. Until the PC, machines didn't really >>have any sort of FP processor. All the instructions passed thru one pipe >>using one set of registers that contained both int and fp (and address for >>that matter) data...
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.