Re: Portable bitwise operations library (was Re: Portability Considerations)

[Alice Osako]

    Benjamin Kowarsch:

On Tue, 19 Mar 2024 at 12:40, Alice Osako wrote:

I've written what are working ISO-compatible implementations of BIT,
SETBIT, BWNOT, BWAND, BWOR, BWXOR, SHL, and SHR, using only the ISO
primitives, though they are painful kludges which I am frankly
embarrassed by - especially the shifts.

https://github.com/Schol-R-LEA/Modula-2-Portable-Bit-Manipulation/tree/main

There has to be a better solution

Indeed, here is one:

https://github.com/m2sf/m2bsk/blob/master/src/lib/imp/CardBitOps.mod

I just don't understand why you don't want to use the code from my libraries.

    Because I was unaware of them? I can see looking back on the earlier
    posts that you had linked to them, but I had assumed that they were
    specific to the new compiler project and you were using them as
    examples. I hadn't even looked at them until now.

come up with without resorting to either the GCC-specific libraries, or
importing assembly code. Even then, the claim to being 'portable' is
probably questionable at best. The fact that there is a constant which
defines the word width, which would have to be manually modified for the
correct value, makes the question of 'portability' pointless.

There is no need to modify this manually, it can be determined at compile time.

https://github.com/m2sf/m2bsk/blob/master/src/lib/CardBitOps.def

And yes, I did have to resort to using variant record aliasing to write
the two specialized cast utility functions, and worse, to looping on the
bits for the shifts. I am truly uncomfortable with this approach, but
couldn't think of a better one within the constraints of generic ISO code.

There is no need for neither casting nor loops.

    The casting functions were actually unrelated to shift functions,
    being due to the use of the ISO functions for BIT and SETBIT (an
    additional pair of cast utilities were later added to handle
    conversions between CARDINAL and INTEGER for the ASHR function,
    actually). I will have to look at you solutions to see the
    alternatives.

By the way, does the GCC implementation of Modula-2 support inline
assembly, or would I have to wrap the assembly/C code into functions and
import them?

In Modula-2 it is considered best practice to write an interface module in Modula-2 and the implementation in the desired language, such as assembly or C. The mechanism how to tell the compiler that an interface module is intended for a foreign implementation differs from compiler to compiler. Thus far GM2 uses the syntax FOR "C" after the module name in the module header of the interface module. However, Gaius announced that he will change this to the way defined in M2R10 with a pragma <*FFI="C"*> after the module name in the module header of the interface module.

 

    I see.

I am not certain how I would proceed with a version that is compatible
with PIM (any edition); it is probably something that would have to be
done on a per-implementation basis.

If you use my library/code, or if you recreate one of your own following the same approach, it will work on PIM and ISO.

    At this point, I see little reason not so, so yes.