[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/