[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] 15 MIPS FC0 emulator
On Sun, Dec 08, 2002 at 08:46:19PM +0000, 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).
> 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?
> 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.
> 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.
> * New cshift
I guess the jury is still out on that.
BTW: `loadcons' also plays a role here.
> * 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.
> * 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, but only .b is currently supported in hardware
(because the latency would increase otherwise). 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?
BTW: the old `logic' name is too hard to grok and should be dropped.
> * New safeload/safestore
It's not clear how that can be implemented.
> * Last proposed/aprouved TLB entry // I think it's Michael proposition
Doesn't matter at the moment.
> * 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.
> (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.
--
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/