RISC load-store verses x86 Add from memory.
|
From: Brett Davis on 19 Jun 2010 17:16 In article <f7b6ece5-a1f7-4ebe-b7f3-c44e55b00dba(a)d8g2000yqf.googlegroups.com>, jacko <jackokring(a)gmail.com> wrote: > On Jun 19, 8:06�am, Brett Davis <gg...(a)yahoo.com> wrote: > > In article <2010Jun17.172...(a)mips.complang.tuwien.ac.at>, > > �an...(a)mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > > We are back to my original question, is Add from Memory RISCier than RISC > > for a hugely OoO design? > > > > (The real win is less than 50%, far less, you have to be starved for issue slots.) > > The power savings is real, and important. > > Yes. I wonder in my NiBZ design if adding extra cycles in the > instruction will significantly reduce area/power? The shadow registers > take up some space, and the 3 in 1 decoder takes up time, making to > memory speed lower. reducing Fmax. Maybe a single extra cycle could do > both these. Freeing up space for something else of use. > > Cheers Jacko. Here is some info on a half cycle bypassed ALU, so you can do dependent operations on a two issue design. http://www.chip-architect.com/news/2000_10_13_Willamette_MPF.html And an interesting if off topic Itanic paper. http://sysdoc.doors.ch/HP/jssc_fetzer.pdf Brett
From: Paul A. Clayton on 19 Jun 2010 17:27 On Jun 19, 3:50 pm, Brett Davis <gg...(a)yahoo.com> wrote: [snip] > PowerPC has some nice kitchen sink features that have multiple uses. > But I always thought of SPARC as just RISC with a registers windows mistake. > > What RISC CPU features does LISP need besides lots of registers? SPARC provided a 'tagged word' (30-bit value, 2 LSb as tag). Addition could generate an overflow trap if either source's tag was non-zero. Loads and stores could generate alignment exceptions based on the tag. (This was apparently not extended to 64-bit.) Paul A. Clayton just a technophile
From: Brett Davis on 19 Jun 2010 18:27 In article <ac56ee8b-beb0-47fb-a3eb-b6ef415cd92a(a)k39g2000yqd.googlegroups.com>, MitchAlsup <MitchAlsup(a)aol.com> wrote: > On Jun 18, 12:17�am, Andy 'Krazy' Glew <ag-n...(a)patten-glew.net> > wrote: > > All other things being equal, I would rather build a RISC, perhaps > > a 16-bit a+=b RISC as described above. > > > > But all other things are not equal. �Out-of-order is a big leveller. � > > Although, if you wanted to have lots of simple > > cores, you might want to give up x86. > All things being equal, I would like the "Instruction set Wars" to die > so the designers can get on with improving the underlying > architectures. I will take the other side of that argument. ;) Were it not for the "Instruction set Wars" x86 would not have MMX/SSE, without which x86 would have lost competitiveness against Alti-Vec designs. No amount of "improving the underlying architecture" is going to be able to compete with a good vector design. New breakthrough instruction set designs are coming, whether you want them or not, and x86 will do its best to Borg the important bits. Tis real life, evolve or die. RISC died, lacked the ability to evolve, hubris that they knew all the instructions that you would ever need. ;)
From: Andrew Reilly on 19 Jun 2010 22:12 On Sat, 19 Jun 2010 21:29:17 +0100, nmm1 wrote: > In article <1jkcsdg.28nffa169emgN%nospam(a)ab-katrinedal.dk>, > =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= <nospam(a)ab-katrinedal.dk> wrote: >>Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: >> >>> Unfortunately, there are several different types of integer overflow. >>> E.g. the overflow conditions for each of the following are different >>> >>> unsigned + unsigned >>> signed + signed >>> signed + unsigned >> >>Are you talking about D or some other language that is not C? > > He doesn't need to. They're all different in C. No, the last one doesn't exist (as a different kind of add) in C: it's an implicit type conversion (to unsigned, usually, because apparently it's more important to preserve the positive range than the negative) followed by an unsigned add. On most processors that have condition codes (including the ia32 and amd64) there is only one underlying add instruction: the overflowness of the result can (nominally) be detected by checking the flags register afterwards. The reference to C is interesting, because I've recently had the experience of encountering a C compiler that actively thwarted the usual idiom for signed overflow detection. That is something like: where x and y are int: if (y >= 0) { if (x + y < x) signed_overflow(); } else { if (x + y > x) signed_underflow(); } The compiler in question (can't remember whether it was a recent gcc or one of the ARM compilers) came up with this beauty: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false Apparently wording in the C standard lets them do that. The "best" alternative I've found so far is to use extra arithmetic precision. Quite a small value of "best". When even addition requires the use of in- line assembly to produce useful results, the language is dead. This is the same sort of epic compiler fail as eliding (x<<16)>>16 (once a common idiom to sign-extend 16-bit integers) on the grounds that the standard doesn't require anything in particular to happen when signed integers are shifted. Cheers, -- Andrew
From: Andy 'Krazy' Glew on 20 Jun 2010 00:59
On 6/19/2010 5:23 AM, nedbrek wrote: > The advantage CISC has is that the uop sequence looks like: > ld tmp = [r2] > add r1 += tmp > > Since tmp is not an architected register, it does not have to be preserved > for an interrupt, or seen past the use in add (it is known dead). Thus, it > can exist strictly in the bypass network (it is not allocated a rename > register, it is not visible to later instructions [does not participate in > renaming], and has no architected effects at retirement). Anecdote: at Intel Mike Haertel and I thought that AMD K7 was taking advantage of this, to get an effectively larger instruction window. Intel was not. When we moved to AMD, we learned that they were not. Perhaps now they are. |