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

Re: [f-cpu] Error with the fractional flag


Michael Riepe wrote:
> On Sat, Jan 05, 2002 at 03:54:10AM +0100, Yann Guidon wrote:
> [...]
> > > > while reading through the ASU code, i read that
> > > > there is no "time" for a 1-bit most-shift
> > > > (which would be useful for fractional operations).
> > > Since fractional operands are in sign-magnitude (rather than 2's
> > > complement) form, we'll need more pre- and postprocessing than a single
> > > shift.
> > <grumble>the definition i have is not sign-magnitude...</grumble>
> > what, then ?
> I referred to Reto Zimmermann's definition, where it is (Lecture notes on
> Computer Arithmetic: Principles, Architectures, and VLSI Design; page 19).
> More precisely, the number represented is
>         x = (-1)^S * 2^(E-bias)
> with S being the most significant ("sign") bit and E being the rest of
> the chunk (bias depends on chunk size). If you multiply two of these,
> you get
>         x1 * x2
>         = (-1)^S1 * 2^(E1-bias) * (-1)^S2 * 2^(E2-bias)
>         = (-1)^S1 * (-1)^S2 * 2^(E1+E2-2*bias)
>         = (-1)^(S1 xor S2) * 2^((E1+E2-bias)-bias)
> The components of the result,
>         S = S1 xor S2
>         E = E1 + E2 - bias
> can't be calculated with a single ASU operation, no matter how you
> tune it :(

The advantage of ADi's definition is that there is no such problem.
the multiply's result is simply shifted left.

> > <slip><slip><slip><slip><slip>....
> >
> > My Analog Devices DSP manual says :
> > "Q16 is a special case of fractional number where all the bits lie to the
> > left of the radix point."
> >
> > <reading further>
> > OOOPS ! I understand where i was mistaken...
> >
> > it says : "In addition and substraction, both operands must be in the same
> > format (signed or unsigned, radix point in the same location) and the result
> > format is the same as the input format. Additions and substrations are
> > performed the same way whether the inputs are signed or unsigned".
> >
> > I think i have mistaken with the multiply where 1Q15 * 1Q15 makes 2Q30,
> > so we have to shift the duplicate sign bit out. This means that only the
> > IDU and IMU have a fractional mode bit in the instruction ...
> >
> > All my excuses ... there is no modification required in the ASU for
> > supporting fractional mode. So we can drop the fractional flag. sorry.
> Applying the IMU/IDU to LNS numbers doesn't make much sense anyway.
> What's that supposed to do, mathematically? For exponentiation, you
> need one LNS and one conventional (integer or fractional) operand.

i don't remember and i have to search the archives, but multiply and
divide has a meaning in LNS world. However, dues to some EU program's
idiosynchrasies, the people who made the 32-bit LNS unit will refuse
to open-source it, so i don't think they'll GPL it. However it could
be possible to rewrite it from scratch, with the help from their
papers (i have the full description of the LNS +/- unit) but i guess
they could have some patents pending.

That's the problem with so-called state-funded research :
(in France, EU and even US) they give money to universities to
do the tough work and it is then monopolized by a company.

I currently leave the LNS side apart but i don't want to abandon
it. We might need the extra bits later, or find a good LNS solution.

> > > If addsub is required to perform both operations simultaneously, we'll
> > > need to duplicate the unit anyway. On the other hand, there probably
> > > are many programs that perform lots of ADD operations but no SUB
> > > (address calculations, for example). Therefore, I'd rather keep the
> > > ASU as-is and add an ADD-only unit.
> > This is not consistent with the fact that no operation triggers
> > 2 adds per cycle... And the ASU is pipelined.
> In FC0, yes :)
what do you mean ?

> > however i would still like an ASU with the duplicated
> > (mirored) units, one being specialized for add and the other
> > for sub. It leaves some headroom in the timing and is DSP-friendly :-)
> And it's future-proof :)

if i had to implement a dual-issue FC0 it would have dual LSU,
dual ASU and dual ROP2 (at least). There would be 1 IMU and 1 IDU
but the first mentioned units are often critical. From my experience
with MMX, a single SHL can lead to problems, too.

OTOH it is probably easier to duplicate the FC0 core ;-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/