Re: [f-cpu] 15 MIPS FC0 emulator

[cedric <cedric.bail@free.fr>]

> > before making it fast, what about making it acurate ?
> > what about the problem with signed saturations ?

> Before anything can be made accurate, we got to fix the manual.  I looked
> at 0.2.7 today, and it seems to move away from reality more and more...

> In particular, the description of the double shift operations is still
> wrong. Instruction names have changed without notice (when did we decide
> to rename `shiftli' to `shiftil', and who introduced `cor' and `cand'?),
> and there are instructions that we never agreed on (e.g. cload/cstore).
> To cut a long story short: it's all a big mess.

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.
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.
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.
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.

So the dead discussion I put in are :
	* New shift/rot
	* New widen
	* New LSU flush
	* 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").
	* New cshift
	* 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.
	* 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)
	* New safeload/safestore
	* Last proposed/aprouved TLB entry // I think it's Michael proposition
	* New cload/cstore

I still wait on you and Yann complete reaction about this manual to have  
something realistic (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).
I have added the color at the top of each page to help people see where change 
occur in the manual (Normally important changes are marked as "Subject to 
change" like logic/cor/cand, and updated instructions are marked as 
"Updated", each of them need to be checked).

> We also badly need to clean things up. I found an ancient bug today -
> one that has been there before I joined the project. Look at the examples
> for `byterev': the lower part of the result is the byte-reversed least
> significant chunk of the operand - and the upper part is *copied*?
> That's impossible. With the old `partial write' semantics, it should
> remain unchanged, and with the current semantics, it should be zero.

Well I think that currently a lot of sample need to be checked, but I don't 
have time to do it.

Cedric


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