[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [f-cpu] 15 MIPS FC0 emulator
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/