[M3devel] [modula3/cm3] Packed set literal generation issue (#21)

[Rodney M. Bates]

On 09/26/2017 06:03 AM, JC Chu wrote:
>> If you use low-level techniques, there are going to be a lot more things to address in source code to make things independent of word size and endianness.
>
> I suppose you’re also going to have to deal with native byte sizes and addressing unit sizes...
>
> Also, what did you mean when you previously mentioned “more complicated variations to adapt to different endianness”?
>

For extreme examples, look in m3-libs/ordsets/ordsets/src/OrdSets.mg, particularly SetSpecialRead.
Here, the code has to take into account the word size and endianness of both the machine
it is executing on and of the machine that wrote the pickle, in addition to properties of
the somewhat complex dynamic set data structure.

Or look in m3-libs/libm3/pickle/src/ver2/Pickle2.m3, PickleStubs.m3, and especially
ConvertPacking.m3.

Or m3-libs/libunicode/src/UnsafeUniCodec.m3


> — JC
>
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop]
> Sent: Tuesday, September 26, 2017 0:15
> To: JC Chu <jcchu at acm.org>; rodney.m.bates at acm.org
> Cc: m3devel at elegosoft.com
> Subject: Re: [modula3/cm3] Packed set literal generation issue (#21)
>
>
>
> On 09/25/2017 06:25 AM, JC Chu wrote:
>>> I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT.  They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling.
>>
>> I was really more concerned about the bit layout of sets: just which bit of SET OF [0..31] {0} should be 1?  We know it’s supposed to be whichever bit that represents the first element of ARRAY [0..31] OF BITS 1 FOR BOOLEAN, but the language definition doesn’t tell us that, either.
>>
>> So in the end I guess sets are just sets, suitable when you want a nice syntax and don’t have to care about the representation.
>
> Yes, Most of Modula3's builtin types are more abstract in a few ways than in many
> languages.
>
>> Bit sets as used in other languages are really words, whose bits can be inspected and manipulated by using Word.Extract and Word.Insert, respectively.
>
> But you can alternatively do it with bit twiddling in Modula3 too, but the language
> is inviting you to use the more abstract types and operators.  If you use low-level
> techniques, there are going to be a lot more things to address in source code to make
> things independent of word size and endianness.  I have written a fair amount of code
> like this, and it requires a *lot* of attention to details that you could forget about
> otherwise
>
>
>>> Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it.
>>
>> That’s weird.  Here on my host INTEGER and LONGINT are 32- and 64-bit, respectively, and the type BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] is accepted, and 64 bits and 8 bytes in size.The type BITS 24 FOR [0..16777215] is also valid, and 24 bits and 3 bytes in size.  (On the other hand, the type RECORD s: BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] END is unaccepted, which I think is allowed by the language definition.)
>>
>
>  From 2.2.5:
>
> The values allowed for n are implementation-dependent. An illegal value for n is a static error.
> The legality of a packed type can depend on its context; for example, an implementation could
> prohibit packed integers from spanning word boundaries.
>
> So the language pretty much allows a compiler to refuse anything it doesn't want to do, as long
> as it gives a compile error.  Probably it accepts the BITS 64 for a scalar (which it is not required
> to actually honor, but not inside a record, where it honoring it would entail spanning a word
> boundary.  Just my speculative attempt to read the original compiler developers' minds.
>


<snip>

-- 
Rodney Bates
rodney.m.bates at acm.org