[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] 15 MIPS FC0 emulator
> > 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).
Ok.
> > 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?
What was the old 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.
Ok, I will remove it.
> > 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.
It's an other solution, I will perhaps start a document like a "TODO
discussion" about all the subject that die and perhaps a link to the last
mail about the subject.
> > 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?
A discussion about stream hint that die...
> > * 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.
Yes, but discussion die...
> > * 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.
Some old part of the manual contain some SR, and mailing-list too, I will put
them in the "TODO discussion" too.
> > * 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?
Cool, somebody write it ;-)
> BTW: the old `logic' name is too hard to grok and should be dropped.
Ok.
> > * New safeload/safestore
> It's not clear how that can be implemented.
I don't know if we must put it in a separated document, because it's a needed
functionnality for an OS on the F-CPU.
> > * Last proposed/aprouved TLB entry // I think it's Michael proposition
> Doesn't matter at the moment.
Direct to "TODO discussion".
> > * New cload/cstore
> Another unclear point.
> > (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.
That the current politic for green mark.
> 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.
Ok.
> 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.
Ok.
Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/