Re: GNU Lightning 2.2.1 release

[Paulo César Pereira de Andrade]

Em sex., 24 de fev. de 2023 às 16:37, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> [...]
>
> Answer to myself:
>
> > I would maybe benefit from having "mask extract" and "mask insert"
> > functions similar to EXT/INS on MIPS.
>
> A mask extract is just
>   jit_rshi_u(rd, rs, ctz(mask));
>   jit_andi(rd, rd, mask);

  I am thinking about:

jit_ext(jit_gpr_t result, jit_gpr_t input, jit_word_t base, jit_word_t len);

  Result is len bits from (zero based offset) base, from the input, sign
extended.

jit_ext_u(result, input, base, len);

  Same as jit_ext, but the result is zero extended.

jit_dep(result, value, base, len);

  Masks value in the bitmask of len bits, and inserts it in the result, at
bit offset base.

  Basically an interface to access bitfields.

  Most backends have some facility to implement it. Only hppa I believe
has support for variable base argument of extract/deposit but this is not
much useful for Lightning, as the idea is to create a simple way to map
C bit fields to Lightning.

> The backends with "mask extract" opcodes (e.g. MIPS r2) could maybe
> just detect this pattern.

  I was also thinking about adding something like:

jit_nandr(r0, r1, r2)
jit_nandi(r0, r1, i0)
jit_norr(r0, r1, r2)
jit_nori(r0, r1, i0)
jit_xnor(r0, r1, r2)
jit_xnori(r0, r1, i0)

  Some backends have NOR (at least mips) or NAND (at least arm*). I
believe they do not have a version with an immediate argument. The
fallback would be:
nand O1 O2 = ~(O1 & O2)
nor O1 O2 = ~(O1 | O2)
xnor O1 O2 = ~(O1 ^ O2)

  But this has low priority, as the fallbacks are trivial, these should
be uncommon uses and very few backends have instructions for it.
These would be more useful for Boolean operations. Maybe adding
some basic pattern for Boolean operations on truth values, for, example
to have the truth value table:

input    and   or    xor   nand  nor   xnor (or xand)
0 0    0     0     0     1     1     1
0 1    0     1     1     1     0     0
1 0    0     1     1     1     0     0
1 1    1     1     0     0     0     1

and have some extra interface for comparisons and branches.

  There is also rotate through carry, but it is not very useful,
and addc/addx is already good enough. Some extra operations
in a register pair, would be better, for example:

qlshr r0, r1, r2, r3

to shift r2 left by r3 bits, store the result in r0, and put overflow
bits in r1.

the equivalent qrshr (and qrshr_u) would put the "underflow" bits in r1.

  Some backends have facilities for such abstraction.

> Cheers,
> -Paul

Thanks!
Paulo