Re: Re: [f-cpu] 15 MIPS FC0 emulator

[Michael Riepe <michael@stud.uni-hannover.de>]

On Mon, Dec 09, 2002 at 05:00:03PM +0100, whygee@club-internet.fr wrote:

[cload/cstore]
> huh i have to find exactly what it is about.
> But i think that conditional load and store is
> not a big problem. The exact semantics and behaviour
> has to be defined but basicly, cload/cstore use the
> same mechanism as conditional moves (for the condition
> part) and the usual load/store (instead that it doesn't
> trap when the condition is false, but the operation
> is aborted anyway). See the trick ? [i wish it works,
> in practice, though ;-)]

If you can make it work - fine. If not - to hell with it!

[madd/msub]
> as you both know, i see no point here.
> a load to register 0 with postincrement does the same.

I agree, as long as you turn off all exceptions and ignore cache
misses(!) for the initial address. Example:

	loadi $-8, r62, r0	// prepare stack pointer for pushing
	storei $-8, r62, r32
	...
	storei $-8, r62, r57
	store r62, r58

If r62 initially points to a cache line boundary, it will cause the
cache to prefetch a line that isn't used at all. Instead, it should
prefetch the line the register will point to *next*. A similar problem
occurs if r62 initially points to a memory area that isn't mapped (TLB
fault), or is badly aligned, or unreadable.

> >> 	* New cshift
> >
> >I guess the jury is still out on that.
> >BTW: `loadcons' also plays a role here.
> 
> i am not sure what it is about, so i won't
> step into that one ...

cshift[lr] was meant to access the upper chunks if registers are wider
than 64 bits. In a 64-bit core, we can make it either clear the
destination register or trigger an invalid opcode exception.

[...]
> >> 	* New cor/cand/mux/logic // Exist in Yann ROP2 code, but are not yet written 
> >> (the copy/paste is really unclear, need to be totally rewritten)
> >
> >Simple. But we used to call them differently:
> >
> >    short   long        new
> >    =============================
> >    <op>a   <op>.and    cand.<op>
> >    <op>o   <op>.or     cor.<op>
> >
> >where <op> is one of: and, or, xor, andn, orn, nand, nor, xnor.  All of
> >them take a size suffix,
> 
> why can't nobody agree ?

I remember that we agreed on the old names - and I implemented both
long and short versions in my assembler (more than a year ago?!)

> i see the combine as a suffix, because it is performed
> AFTER the logic operation. Otherwise it is potentially
> misleading.

Good point.

> > but only .b is currently supported in hardware
> >(because the latency would increase otherwise).
> this will be determined at synthesis time, but it's
> a first good guess that allows to do ASCII string searches
> easily.

As you can see in my other mail, that can also be done without combine.
The resulting code will be only slightly slower, and works for all
chunk sizes.

[ROP2 description]
> >I hope that was correct, I didn't look at the code for a while. Yann?
> 
> right.

*phew* ;)

> >> 	* New safeload/safestore
> >
> >It's not clear how that can be implemented.
> 
> are we speaking about the atomic things ?

I think so.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/