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
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to