[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] Some question about the update

On Sat, Apr 20, 2002 at 03:37:50AM +0200, cedric wrote:
> Hi,
>    I have started to update the manual with the two post that Michael give to 
> me, but for certain case it's not really clear.
> First the FPU. Is it SIMD or not ? (problem with exeption and rouding for 
> example, and perhaps a problem of size). Or is it SIMD hidden into the EU ?
> (Read post from Michael with subject : Re: [f-cpu] Re: Floating-Point? date 
> from Wed, 15 Aug 2001 23:12:27 +0200).
> 	I don't understand the meaning of fexp with a base ? What did that 
> mean ? And why not only a 'ln r2, r1' (logarithm neperien) instead of flog ?

That's what I suggested (or similar, at least). There's no real need
for the third argument. Whether the instructions are base-e (natural
logarithm), base-10 or base-2 doesn't matter much either -- we should
choose a base that's easy to implement.

> 	I have added fcmpl[e] instructions in level-1 floating-point for compare 
> instruction.

I'd rather pick `fcmpe' (equal) and `fcmpl' (less). Remember that a
floating-point number may have more than one representation (that is,
r1 xor r2 may not be zero, but their values are nevertheless the same).
`fcmple' (and its counterpart `cmple'), on the other hand, is redundant
because the expressions

	a < b
	b > a
	!(a >= b)
	!(b <= a)

are all equivalent (provided neither a nor b is a NaN).

> 	Finally, did we add an new f2f instruction for FP conversions (32bits | 
> 64bits -> 32 bits | 64 bits) ?

We should.

> About LNS: what are the rounding method (or mode) ? same as FPU ? And did
> we add 16 bits representation (like nicO suggestion ?) ?
> About memory, I didn't understand the problem with store[f] ? Can you explain 
> it to me ? And did we add a new flag for a special immediate operand (6 bits 
> value + 2 bits left-shift, as Michael suggest ?)

I guess that was operand order... you can leave it as it is.

> 	I did'nt understand why did we specify into the CPU a fixed memory
> hierarchichies (see cachemem). I think that we could say that 0 will be the
> quicker and 7 the slower, or something like that ? And did we add a 'cachecode 
> r1' instruction that will perform a prefetch in I-Cache before a jmp (in a 
> function call for example like in Michael's C++ sample).
> 	And about the storem/loadm, I have update with the new form you give 
> (I have read gcc documentation, and it's exactly the called form it need, so 
> it will be easy to use for a compiler). But I think that I must remove any 
> reference to SRB mechanism, because SRB is done in physical address space 
> (no trap) and the storem/loadm must be done in virtual address space (trap 
> problem). An other point about this instruction, did we add the 2 registers 
> form ?
> 	We now have a unconditionnal move, but is it a alias for 'movez r0, 
> r2, r1' or something else ?

`movez r0, r1, r2' and `move r1, r2' are equivalent (that is, they're
the same instruction).

> In the instruction set I have updated bitop[i]. I think that I must update 
> bitrev with the new syntax : 'r1 = bit_reverse(r2) >> r3'.

That should read `r1 = bit_reverse(r2) >> (size-r3-1)', if I remember
correctly. The other version is affected by the register size (which
is bad).

> An other question 
> is about nop function, actually it's specified as a movez r0, r0, r0 that 
> must be coded as a 0x00000000 in hardware, but must I change it so that it 
> became 'nor r0, r2, r1' or 'xnor r0, r2, r1' ? (I don't understand this 
> change).

I guess you mixed up `nop' and `not'.

Both `nor ...' and `xnor ...' are equivalent to the (non-existing)
`not r2, r1'.  Actually, there are a lot more ways to write `not'.

> 	And I didn't understand the effect of widen new instruction. I don't 
> understand if it will take 2 cycles and only replace two separated 
> instructions or if it does something more.

It should take only 1 cycle (but isn't implemented yet).
Otherwise, we could also use shift/mask operations.

> 	The not instruction did not exist anymore, right ? So it became an 
> alias, but what is the better choice for this alias ?

See above

 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/