Benjamin Kowarsch <trijezdci@gmail.com> writes:
>
> Keep in mind that only type BITSET is portable and then only for a
> maximum of 16 bits because Modula-2 implementations typically map type
> BITSET to the underlying machine architecture's standard register
> size. Any code written using BITSET with more than 16 bits will be
> non-portable. Any code written with extended BITSETnn types will be
> non-portable. They are best avoided.
>
[...snip...]
>
> Here too, only CARDINAL, INTEGER and LONGINT are portable types. Any
> use of extended versions of these types will render the code
> non-portable. They, too are best avoided entirely.
yes indeed any types (using the name FOOint) imported from SYSTEM are
potentially non-portable in gm2. In gm2 the front end probes the back
end to see if these datatypes are supported and then creates them.
When I said non-portable, I meant non-portable across compilers and dialects though.
> In our M2BSK bootstrap kit, we address these issues as follows:
>
> (1) Avoid all use of BITSET and BITSETnn
>
> Instead, we developed a portable 96-bit bitset library that we use for sets of tokens, thus called TokenSet.
>
> https://github.com/m2sf/m2bsk/blob/master/src/TokenSet.16bit.def
> https://github.com/m2sf/m2bsk/blob/master/src/TokenSet.32bit.def
> https://github.com/m2sf/m2bsk/blob/master/src/TokenSet.64bit.def
interesting! In gm2 it chooses BITSET = unsigned int for smallsets <
sizeof (int) * 4 elements and otherwise contructs a large set which is
currently a record of multiple word sized sets. I'll be changing this
implementation to use a pointer to an array of bits in the near future
(very similar to how ARRAYs OF type) are implemented.
The accessor functions (for large sets) are contained in SYSTEM.mod
and these are called from gcc/m2/gm2-gcc/m2expr.cc.
gm2 also needed a 96bit token set :-) and here it uses three 32bit word
sets to allow ease of bootstrapping with C/C++. But in due course this
might also be changed (new longset implementation).
For bootstrapping gm2, being a gcc front end, you can obviously always take gcc for granted,
and thus the data types that gcc implements. By contrast, our bootstrap kit is designed to be
platform, compiler and dialect independent. Thus, we cannot rely on the data sizes of types of
any given compiler and we need to have a solution for any possible constellation.
Now if somebody develops an application, they may well make the conscious decision to
write the code such that it will only be compilable with a particular compiler.
However, when it comes to libraries, as appeared to be the case with the OPs use case,
then it is advisable to write portable code, independent of platforms, compilers and dialects.
And when writing portable code, the code should not be cluttered by preprocessor directives
so as to make it difficult for a human reader to figure out what the code is intended to do.
So, that's what I was advocating: (1) to write portable, and (2) to write readable ;-)
rgds
benjamin