Re: [f-cpu] F-CPU vs. Itanium

[Yann Guidon <whygee@f-cpu.org>]

hi !

Michael Riepe wrote:
> On Sun, Apr 21, 2002 at 11:39:39AM +0200, Martin Devera wrote:
> [...]
> > maybe I misused the term disambiguation - I understand that code
> > above will go just well. But often you can do this:
> > loada   r3, r4  ; start loading of r4, add r3 to disambig. mem (DM)
> > loadimm  1, r1
> > store   r2, r1  ; if r2 is in DM remove it
> > verify  r3, r4  ; if r3 is not in DM behave as load (instead as nop)
> > add r2, r4, r2
> >
> > So that loada will have a time to get the data during loadimm.
> > IMHO this code should be faster (only one cycle in this particular
> > case).
> 
> Speculative loads can probably be implemented in a similar manner as
> the load-linked/conditional-store instructions we've been talking about
> recently. When `loada' is executed, mark the corresponding bytes in the
> cache, and reset the markers whenever an instruction modifies the loaded
> data. If the markers aren't all set (or the cache line was flushed),
> the `verify' instruction will trap, jump to a piece of fixup code, or
> simply re-load the modified bytes. The drawback of this approach is that
> it doesn't work well if the same bytes are loaded more than once, or if
> the loaded register is overwritten. I'm not sure how the Itanium handles
> that case, however.
> 
> The other (probably more expensive) solution is a table that maps register
> numbers to (virtual or physical) addresses. When a register is loaded,
> make a new entry in the table; when the loaded data is modified or the
> register is clobbered, remove or invalidate the entry.

that's what the LSU does :-) [more or less, in a certain sense]

> > But you can do it only if you are sure [r3] is not later changed
> > by store. And you never know (at compile time) that two pointer's
> > might be the same (if they are the same type).
> 
> That's why ISO C99 adds the `restrict' pointer qualifier. E.g. you write
> 
>         void copy(char *restrict dest, const char *restrict src, size_t len) {
>                 ...
>         }
> 
> and the compiler will assume that source and destination do not overlap.
> That is, it does not need to disambiguate those pointers. Of course
> programmers have to be more careful -- calls like
> 
>         copy(array, array + 1, 10);
> 
> will produce unspecified results.
> 

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/