Shorter:
you need a transformation:
every non zero 32 bit value -> x'01'
zero (32 bit) -> x'00'
LPR x,x ... LCR x,x ... SRL x,31
does it.
Kind regards
Bernd
Am 20.04.2022 um 00:59 schrieb Bernd Oppolzer:
ccpm and carrybit are probably ints or unsigned ints,
because of the L and N instructions, which read them.
so, the & (bitwise AND) operation yields a nonzero result, if there is
a one bit
in the same bit position in both operands. This nonzero result must be
transferred
to a one byte value X'01', using some clever register operations.
And: yes, IMO the coding here tries to avoid branches and compares.
The solution LPR ... LCR ... SRL looks OK for me.
LPR keeps a nonzero result, but with a positive sign,
LCR does the same, but enforces a negative sign,
and SRL moves the sign to the rightmost bit position.
In contrast, a zero result of the N operation would stay zero
throughout the LPR / LCR sequence, and the SRL would move
a zero bit in the rightmost bit position.
The final STC moves the rightmost 8 bits to the bool variable;
bool (no C standard type) is probably a typedef which means char.
I hope, I understood the coding correctly.
Kind regards
Bernd
Am 19.04.2022 um 15:06 schrieb Ian Worthington:
Noticed today that the GCC C compiler generated an unexpected
sequence of instructions for an AND and TEST:
**** bool overflow = (ccpm & carrybit) != 0; // check if carry
bit set
109 .loc 1 189 0
110 0078 5810B25C l %r1,604(%r11) # D.7949, ccpm
111 007c 5410B26C n %r1,620(%r11) # D.7949, carrybit
112 0080 1011 lpr %r1,%r1 # tmp54, D.7949
113 0082 1311 lcr %r1,%r1 # tmp55, tmp54
114 0084 8810001F srl %r1,31 # tmp56,
115 0088 4210B25B stc %r1,603(%r11) # tmp56, overflow
I can only guess this is to avoid the cost of a branch? Or is there
some other advantage in this?
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
