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

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

Le Samedi 20 Avril 2002 10:48, Yann Guidon a écrit :
> "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.

If I understand, the SIMD capability of the FPU is optional like the FPU 
himself. That mean that we have more than 3 level of implemented FPU ?

> > (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 ???
No, I mean what append when we need to trap only because one of the chunk.

> > 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.
Ok, it reply to my question.

> > (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.
ok, what about fln ?

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

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

> >         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.
but in pdf ;-)

> > 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.
I don't see this instruction, but the prefetch instruction (you mean cachemem) 
do is work in D-Cache and not I-Cache, or I miss something.

> >         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.
I have an idea on howto to implement it, I will explain it "au first jeudi".

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

> >         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.
Ok, It means that all alias remark into the manual must be removed ?

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

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

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

> > 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.
I agree, but I am currently working on the instruction set.

A+
  Cedric


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