[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [f-cpu] Memory add/sub




hi there,

>De: Cedric BAIL
>> hello, 
>  
>> i really wonder what this thing is really about... 
>> anyway. 
>;-) 
:-/

>> Michael Riepe wrote: 
>>> On Sun, Sep 01, 2002 at 03:30:53PM +0200, Cedric BAIL wrote: 
>>>>   If we want to correctly manage a stack with pop/push operation, we 
>>>> need a add/sub operator that preserve the LSU information bit. 
>> really ? 
>yes 
OMG...

>> push/pop is just one use of pointer updates, and the existing 
>> post-increment (with register or immediate modifier) has 
>> already been discussed, right ? 
>Yes, and you perhaps forgot that the solution need a add/sub
> before doing a pop after the last push.
or a push without pointer update.

>>>> I propose something 
>>>> like that : madd[0-7] and msub[0-7].
so you think about a simple a+b=>c instruction ?
then the existing one will do the trick, maybe with
1 or 2 cycles of penalty (and no prefetch).

>>>> I don't know if we need size for 
>>>> this operation or endian, I think not. Stream information is needed 
>>>> if we want to implement them by simply multipling the number of LSU. 
>> do you mean that you want to add or substract up to 7 bytes from a 
>> pointer ? 
>euh... I was speacking about stream in the instruction
> (all load/store have it). You know the cray like feature ;-) 
[remark : it's not Cray per se. Cray had left Cray Research
for more than 10 years when the T3D appeared.]

>> the existing post-increment does this already, and you get a load or 
>> store for free. If you want to hust update the pointer, "load" R0 so the 
>> result is cancelled. "Think RISC". Or should i say : project yourself in an 
>> over-simplified world. 
>I say no, it doesn't update the pointer before memory operation. And in 
>a lot of case we need that (compiler need it when they manipulate object 
>or in certain case the stack because of big jump). 

if the result of the load is cancelled, then the pointer
update is not subject to order problems, and it does just
what you want at no cost.

>>>>   In the same idea I think we need to affect some stream, for 
>>>> example 0 for unknow stream and 7 for stack. What did you think 
>>>> about that ? 
>> allocating stream now would reduce our scalability in the future : 
>> we still have a lot of other means to do specific things : we can add 
>> some instructions for example. 
>I think that not a good solution.
and i think the contrary (not a surprise, right ? ;-D)

> But what append if you compiler 
>can detect that stack and malloc are not the same stream and want to allocate 
>them. It can't because he will use external librairie that will always use 
>the default stream 0. So he will never be able to use them ! 
this flag is a "hint" and its semantics is not well defined yet.
it's ok to separate streams but what if there is a collision
in your library ? or if the semantics is interpreted differently
from software to software ? and do you know ANY compiler that
does that anyway ?...

>So if we don't say any thing about stream now before any application 
>are written, we can remove this feature I think. And I don't see why 
>adding instructions or delaying the problem will solve it. 
we have a lot of time to populate the stream hint flags :
the architecture is meant to last for decades, and you already
want to reduce vitale extension possibilities.

>>> I already outlined the need for such a `pointer add' instruction last 
>>> year. Programs that deal with structures (or classes/objects) will 
>>> need it quite often. 
>> then just do a "load" to this pointer, put the result in R0 
>> and update the pointer with the register or immediate value you want. 
>??? What are you doing ???
consider that as a "side effect". Otherwise, why would
we take care about making a "zero" register ? do you know
that in hardware, it's a pain to do ?

> You prefer to do a memory operation 
>instead of only updating a pointer ? In fact you use a hack to do 
>something like madd/msub, but that isn't clean ! Think RISC, don't 
>forget ;-) 
OMG....
Then look at a MIPS CPU and how it is used.
for example, comparison is just another form of
substraction. and it's only the simplest example.
why add a new scheduling complexity when the
same operation is already done by another instruction ?
Take some course about RISC, i mean, 1990-era
when silicon was not so large...

>> Is a specific instruction really needed ? 
>Yes, and absolutely yes ! Or you must specially handle load/store
>to R0, you prefer to complexify a complex instruction instead of 
>adding a simpler instruction... 

tell me : what was the previous side effect of doing a load to
R0 ? IIRC it did a prefetch. isn't it what you want to do ?

>Cedric
YG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/