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

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

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

So ok, we will select the base when we will implement this function.

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

I agree, but I what thinking that it was more logic compared to the integer 
instructions. It can probably only be an alias, or a macro, but it's more 
clear.

> > 	Finally, did we add an new f2f instruction for FP conversions (32bits |
> > 64bits -> 32 bits | 64 bits) ?
>
> We should.
and f2f, is it a good name ?

> > 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.
Ok, and for 16 bits LNS number ?

> > 	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).
It's what I understand.

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

> > 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'.
Oups, you are right.

> Both `nor ...' and `xnor ...' are equivalent to the (non-existing)
> `not r2, r1'.  Actually, there are a lot more ways to write `not'.
Ok, but not one we prefer ?

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

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