[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] Some question about the update
> > 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
> > 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).
> > 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
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/