On Sun 26. Mar 2023 at 23:43, Jeff Law <jeffreyalaw@gmail.com> wrote:

>
>
> On 3/22/23 09:47, Christoph Müllner wrote:
>
> >
> > Hi Tsukasa,
> >
> > There seems to be a misunderstanding of the spec.
> > The second operand of the fli should be the constant itself ("Value"
> > column of the specification) in C-like syntax.
> > E.g.:
> >    fli.h ft1, -1.0 # encoding rs1=0
> >    fli.h ft1, min # encoding rs1=1
> >    fli.h ft1, 0.0000152587890625 # encoding rs1=2
> >    ...
> >    fli.h ft1, 16 # encoding rs1=25
> >    ...
> >    fli.h ft1, nan # encoding rs1=31
> >
> > So we have 3 strings ("min", "inf", "nan") and 29 constants.
> Ouch.  So we've got to parse & match the actual constant.  I worked on a
> processor with similar capabilities, but we defined the assembly syntax
> to use the table index for the constant rather than the constant itself.


> I'd strongly suggest supporting the %a/%A hex notation for the
> constants.  It's unambiguous and less error prone.  I think Kito made a
> similar suggestion downthread.


That had been my initial reaction as well, when discussing the expected
assembly syntax with Andrew (the specification was not explicit enough to
me, as the table index will also be a decimal constant).  However, after
giving it a little thought, matching the FP-constant dies offer its own set
of advantages:
(a) it makes it clear to assembly writers and (more importantly) readers
what numeric value is intended; if we use the table index only, the typical
use will have a comment with the value next to it
(b) it is a clear improvement over today (where either the
hex-representation will be in the constant pool or a load-imm sequence will
be used).

Accepting both notations (possibly prefixing the index with #) sounds
reasonable. For disassembly, the fp-constant is preferable … sane for
compiler output (unless we want to emit a comment for verbose-asm).

The extra effort to handle the FP constants in the assembler certainly
seems worth the improved readability of the assembly.

When I read through the basics of Zfa I was a bit disappointed.  99% of
> the time the fli is going to feed one or more FP arithmetic
> instructions.


As the ship for fp-immediates in fp-arith has sailed (at least in the 32
bit encoding space), this fli-construction will at least offer
opportunities for fast result forwarding/bypass or for instruction fusion.

It'd be more efficient to be able to access those FP
> constants in the FP arithmetic instruction itself.  I guess that ship
> has sailed.
>
> Jeff
>