[f-cpu] Taking decision on the project

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

I don't have time as Michael to go deep regularly inside the manual. But
i don't like so much to change the manual depending on what is
implemented ! That is not the goal of a manual.

(if cstore/cload are conditionnal load/store, it should behave like
cjump but with data instead of code.)

More generaly, take a decision on the vhdl list is very hard. Maybe the
vm bit field has been decide that way. But more often, the thread just
end. We try to implement a system of RFC but that's hard to find people
to do that work. 

Our main document is the Manual, so Cedric find this way to speed up
decision : if nobody are against, it's adopted. During almost 2 year,
the manual did not change !

Maybe "unstable" manual could be deliver ? So we can discuss about it. A
wiki should be very nice to discuss each very particular feature. But we
know how such business always end...

nicO

-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 09/12/02
Objet: 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/
_____________________________________________________________________
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
Règlement : http://www.ifrance.com/_reloc/sign.sms


_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France

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