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

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

"questions pour un champignon" 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.

tell me if something EVER remains clear, ok ? :-P

> First the FPU. Is it SIMD or not ?
at least it should leave this possibility.
The chip can implement it the way it wants (or not), but it is desirable.

> (problem with exeption and rouding for example, and perhaps a problem of size).
rounding ? You want to make separate rounding policies for specific numbers
of a SIMD packet ???

> Or is it SIMD hidden into the EU ?
i don't see what you mean here. It's certainly done like with integer SIMD.
The register set gives a full-width data to the unit and the unit processes it.

> (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 ?
maybe to avoid confusion with LNS operations.

you seem to have a problem with the base, right ? it is probably because the
algorithm that computes log and exp is specific to a certain base so we can't
specify it directly (a mutliply does the correction before or later).

> I have added fcmpl[e] instructions in level-1 floating-point for compare instruction.
IEEE specifies that FP compares can be done by integer units.
correct me if i have mistaken something.

>         Finally, did we add an new f2f instruction for FP conversions (32bits |
> 64bits -> 32 bits | 64 bits) ?
i don't remember.

> About LNS: what are the rounding method (or mode) ? same as FPU ? And did
> we add 16 bits representation (like nicO suggestion ?) ?

i have not heard about rounding issues with LNS.
Leave that part "highly speculative -> don't bother" now because the legal issues
are not all solved.

> About memory, I didn't understand the problem with store[f] ? Can you explain
> it to me ?
the 'f' flag (as explained more or less in previous posts, such as dealing
with cache replacement issues) means 'flush' : the LSU line that is being accessed
is not needed anymore, so it is not saved in the L1. the behaviour is :
 - if it's a read and the line has no "dirty" bit, the LSU line pointed by the
   pointer register will be overwritten by urgent data.
 - if it's a write, then the line will be written back to the core's outside
   and then freed for immediate use.

> And did we add a new flag for a special immediate operand (6 bits value + 2
> bits left-shift, as Michael suggest ?)
i probably missed this post. i can't keep up with everything.

just in case someone wonders, if an increment is larger than what the immediate field
can contain, there must be more operations : one or more 'loadimm' loads a register
with the increment, and the load/store operation uses the register value to update
the pointer.

>         I did'nt understand why did we specify into the CPU a fixed memory
> hierarchichies (see cachemem).
it was speculative and it's not written in the stone.

> 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).
the cache prefetch is already speculatively performed IIRC.
i don't remember the opcode name, but when you specify a register
with a target, this first computes the address, then checks the
validity and if ok, fetches the code. That's why the prefetch instruction must
be moved far in advance.

>         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).
argh, i don't know if we will even support loadm/storem in the first chip
versions... maybe i shouldn't have spoken about it at all.

> 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 ?
i think that we can't solve the whole problem now. Mark this as : "speculative"

>         We now have a unconditionnal move, but is it a alias for 'movez r0,
> r2, r1' or something else ?
maybe, maybe not. I think that we'll decide if the opcodes alias when the opcode
map will be "compiled" for F-CPU v1.
It can be ok to make separate entries and opcode names, because the opcode values
can be set to identical values later.

> In the instruction set I have updated bitop[i].
IIRC, the original assumptions don't hold anymore, so they also must be marked
as "speculative". Maybe a "real" implementation will "chain" SHL and ROP2 together,
but the critical datapath is already exploded in SHL and bitop can't fit in a single

> I think that I must update
> bitrev with the new syntax : 'r1 = bit_reverse(r2) >> r3'. 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 don't understand either.

But NOP must become a new opcode of its own.
The opcode is not defined yet, but the remaining fields must be zero.
I have the intention of giving a new separate semantics to this "instruction"
because it's used more often than we'd think, mainly for alignment.
So the remaining fields can store hint for the alignment etc...

>         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.
i don't remember this discussions... i should look into my archive...

>         The not instruction did not exist anymore, right ? So it became an
> alias, but what is the better choice for this alias ?
was there a NOT instruction ? as explained in the manual, ROP2 does only 2-operands
operations. There is no specific alias, XORN with register #0 is ok (at first sight).

> At least, for jmpa, it's name is now jmp, right ?
i guess so.

> Can someone explain to me
> the new jmp instruction, I currently didn't understand the manual definition.
what do you miss ?

If the condition is satisfied,
  jmp(a) jumps to the location pointed to by the pointer register (r2 IIRC).
  the value of PC+4 is written to the destination register if the jump takes place,
  this can be R0 but it's used for function calls.

> I think, that a good start for an update, if I miss something or you want to
> add something, add ;-)
i think that the 1st part must be shortened : the inclusion of the aug.1998 document
is more misleading than anything. we'll see that when we meet.

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