[fpc-devel] ROL/ROR with Carry

[Sven Barth]

Am 11.01.2021 um 19:53 schrieb Karoly Balogh via fpc-devel:
> 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...

That code is nice as well. I had thought of a similar one since I had 
written my mail.

> 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.

If it can't be implemented more efficiently than the library function 
(e.g. yours) already does it for a specific target, then it could just 
as well use that. After all we don't provide intrinsic ROL/ROR for every 
target either.

> 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.
Sadly the user who had an interest in this had redacted their example 
code from the forum after their feature request didn't go through thus I 
can't tell you what they had done with the carry...

Regards,
Sven