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

[whygee@club-internet.fr]

hi,

>De: Michael Riepe
>cedric wrote:
>
>> Well, for shiftli and shiftil, the problem is that for all the instruction we 
>> have first the opcode and then the flags, so when somebody say that we only 
>> need one opcode for left/right shift that move from opcode to flags, so the 
>> logical point of view is to add them to the flags part.
>
>That wasn't necessary, and I will continue to use the old name.
>Whether or not shift[lr] share a single opcode doesn't matter (that
>hasn't been decided anyway - and as long as there is no decision, the
>manual should stay the way it is).

On top of that, i have the intention to write another
version of the shifter. One day.

>> For cor/cand, I asked Yann every day since august to write me a document about 
>> is new instruction combine/mux/logic, but he didn't have egouth time to wrote 
>> the instruction specification, he only give me some sample of how to use it 
>> and that's all.
>It's all in the code... but again, why the new names?
huh good question.
but do i really want an answer ?... (PH34R !)

>> For cload/cstore, I think that because nobody reply on Yann mail :
>>  "Re: [f-cpu] Conditionnal load and store, the return" (Date : 
>> Fri, 30 Aug 2002 01:31:03 +0200), it was accepted.
>
>Wrong. I know that SW people liked it, but it makes the implementation
>too complex.

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 ;-)]

>> But in fact 0.2.7 is unstable, I mean that I put every dead discussion in it 
>> and wait for reaction because, it's the only way to have a decision. In fact 
>> 0.2.7 must not be the manual on which you refer when you write an assembler 
>> or a emulator.
>
>May I suggest that you put the `dead ends' into a separate section?
>Or better, throw them away. A manual shall document what *is*, not what
>might be. If it doesn't match, the manual is wrong by definition.
>
>> So the dead discussion I put in are :
>> 	* New shift/rot
>
>Almost matches the implementation
>
>> 	* New widen
>
>Not implemented yet (but will be).
>
>> 	* New LSU flush
>
>Where's that?
>
>> 	* New madd/msub // I think that's now they will be removed, because normal 
>> add/sub will do it (look at Antoine/Yann mail "Re: [f-cpu] pointer add & 
>> sub").
>
>Another undecided point.

as you both know, i see no point here.
a load to register 0 with postincrement does the same.

>> 	* 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 ...

>> 	* Starting SR_MAP // For it I read all the discussion in the mailing list and 
>> in the manual that contain SR_, so a lot of them are only supposed.
>
>f-cpu_config.vhdl contains a list. If it's not there, it does not
>exist.

or not yet. I think that i have forgotten a lot of them,
but it's difficult to figure them outside of their context.

>> 	* 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 see the combine as a suffix, because it is performed
AFTER the logic operation. Otherwise it is potentially
misleading.

> 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.

> The logic operation <op>
>is performed on whole registers; the size suffix indicates how many bits
>are combined in the second step. The basic operations (just <op>, without
>combining) never have size suffixes. Finally, the mux instruction computes
>
>	r1 = (r1 & ~r3) | (r2 & r3)
>
>(bitwise multiplex). It doesn't have any suffixes.
>
>I hope that was correct, I didn't look at the code for a while. Yann?

right.

>BTW: the old `logic' name is too hard to grok and should be dropped.

yup. i guess that even "nand" is explicit enough.

>> 	* New safeload/safestore
>
>It's not clear how that can be implemented.

are we speaking about the atomic things ?

>> 	* Last proposed/aprouved TLB entry // I think it's Michael proposition
>
>Doesn't matter at the moment.

huh ? i probably missed an episode.

>> 	* New cload/cstore
>
>Another unclear point.
>
>> I still wait on you and Yann complete reaction about this manual to have  
>> something realistic
>
>Unfortunately, I don't have enough time to work, sleep, eat, write VHDL
>and C, and read every manual update or code snapshot that crosses my way.

me too. I'll promise to try on day, though...

maybe now ?

>> (You know it's hard to extract decisions from the 
>> mailing-list, it will be perhaps a good idea to specify a policy to know when 
>> something is approved and must be put in the manual).
>
>When it describes something that is already implemented (in particular,
>the ROP2, ASU, IMU or SHL units), it should be in the manual - and it
>should be correct. These are the pages you can mark green. Once marked,
>the pages must not change again, or they will lose their marks.
>
>Everything else is subject to change. Projected stuff that hasn't been
>implemented yet but is on its way (like the INC/CMP instructions) can be
>marked yellow. The FP stuff also belongs into this category (except fcmp*
>which is complete nonsense), and things like load/store/move/jump.
>
>The rest belongs to the red category. It's mostly pure speculation.
>Something may move up into the yellow category if there is a design
>for it - that is, if somebody can start implementing it.

yup.

> Michael "Tired" Riepe
YG

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