From: Brett Davis on
In article
jacko <jackokring(a)> wrote:
> On Jun 19, 8:06�am, Brett Davis <gg...(a)> wrote:
> > In article <2010Jun17.172...(a)>,
> > �an...(a) (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.

And an interesting if off topic Itanic paper.

From: Paul A. Clayton on
On Jun 19, 3:50 pm, Brett Davis <gg...(a)> wrote:
> 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
In article
MitchAlsup <MitchAlsup(a)> wrote:
> On Jun 18, 12:17�am, Andy 'Krazy' Glew <ag-n...(a)>
> 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
On Sat, 19 Jun 2010 21:29:17 +0100, nmm1 wrote:

> In article <1jkcsdg.28nffa169emgN%nospam(a)>,
> =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= <nospam(a)> wrote:
>>Andy 'Krazy' Glew <ag-news(a)> 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.


From: Andy 'Krazy' Glew on
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.