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

[Cedric BAIL <cedric.bail@free.fr>]

> >> 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... 
 
What did you mean by OMG ? Something linked with DNA ? 
  
> >> 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). 
 
It's why I want this, for prefetch and only prefetch. 
  
> >> 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. 
 
Perhaps, but the load are done, I mean the data are loaded from the 
LSU, so you ask something you didn't need. 
 
> >>>>   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) 
of course ;-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 ?... 
 
Yes, GCC does it (man memcpy for a start). And the meaning of this hint is, 
correct me if I am wrong, don't check coerrency with the other stream than 
myself. 
 
> >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. 
 
To late, as I explained earlier, if we don't say before having any binary, 
for compability reason, we will lose all the interest of this feature. 
For example if you call memcpy, without saying anything about stream 
params, you will never be able to use a stream for read and an other for 
write... 
 
> >>> 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 ? 
 
It's clearly a hack ! 
 
> > 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... 
 
Yes, but we are not doing a MIPS... but something powerfull and clean... 
  
> >> 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 ? 
Yes, but I didn't want a hack ;-) 
 
Cedric 
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/