[fpc-devel] ROL/ROR with Carry

[Karoly Balogh]

Hi,

On Mon, 11 Jan 2021, Sven Barth via fpc-devel wrote:

> So the idea is to add support for ROL/ROR with Carry support as the
> current Rol*/Ror* functions don't support that. Florian then said that
> he's open to suggestions under some restrictions. Considering that the
> current Rol*/Ror* intrinsics aren't available for all platforms as
> intrinsics either, but as functions then, this could be done to support
> CPUs without suitable Carry support as well. And the code snippet that
> jamie showed would be a nice base:
>
> === code begin ===
>
> Function ROLByteWithCarry(Const AByte:Byte; Var ACarry:Boolean):Byte;Inline;
> var
>    LocalIn:Boolean;
>   Begin
>    LocalIN := Acarry;
>    ACarry := ShortInt(Abyte) < 0;
>    Result := (AByte shl 1);
>    IF LocalIn then Result := Result or 1;
>   End;

We can name it rolx/rorx... I don't think such a long name is a good idea,
because such construct will be used a lot in longer formulas?

Btw, as the code, what's wrong with:

begin
  result:=(abyte shl 1) or ord(acarry);
  acarry:=shortint(abyte) < 0;
end;

No local var, no branches...

The problem is with this ROL-with-carry as library function approach, that
it tries to mimic internal working of some CPU, so it inherently leads to
less efficient code, because it's very difficult to actually map this into
a CPU instruction... Even when we provide an instrinsic for it, because
how on earth you populate the carry flag first based on that boolean
coming from that argument? So I feel people will try to use this for
"smart" algos and optimization, while it's totally counterproductive in a
high level language.

It's much better to write such code as <value * 2> + previous carry then
clamp it, then let the compiler optimize it, rather than trying to mess
with a rorx/rolx function.

I think whoever wants such a ching is just better off extending their byte
to a word, doing the shift/rotate, and masking the carry off as needed.

My 2 cents.

Charlie