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