[M3devel] Modula-3 bitfields

[Jay K]

 > What mental model? > We have network order. Everything network is bit streams, from left to right, most > significant bits/bytes.  Does any Modula-2 or Modula-3 or C compiler follow this model?For a little endian target? I'm skeptical.If it really is obvious, maybe we can make cm3 follow it?Even if it breaks bitfield interop with C?I would like to have m3front and M3C.m3 not have any target-endian dependentness.I do believe it would break pickles, and some floating point code in m3core/libm3.  ..because..you see.. I think there some mental model in C compiler writer's heads...that cm3 tries to adhere to, but which I might have diverged a bit from (look at the history of Target.m3).  In particular, standard C only allows bit fields to be of type "int" or "unsigned".However it is a common extension to allow the type of a bitfield to also unsigned/signed char, short, long, and long long, and this does I believe affect the layout. Does that fit your mental model? In your model, must a 32bit bit field be aligned on a 32bit boundary? What does this look like: struct {  unsigned a : 1;  unsigned b : 32;};?   - Jay
 From: dragisha at m3w.org
Date: Fri, 24 Aug 2012 21:53:44 +0200
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Modula-3 bitfields

What you are proposing is to do a compiler-level job with a library. Just because such a library exists does not mean it invalidates every other approach. And we are talking about one of most complicated pieces of Modula-3 system, comparable in complexity with compiler. Of course, there are other approaches too, like some kind of interface language, to be processed into Modula-3 source code by cm3 build system.
Your latest example is good illustration for my proposal too. Another simple example to show a need for exact bit packing layout method. Thank you!

--Divided by a common language
Dragiša Durićdragisha at m3w.org



On Aug 24, 2012, at 9:28 PM, Mika Nystrom wrote:
And what does that mean, exactly?  No gaps allowed?  What does it
mean, in particular, on a little-endian machine?

What about ARRAY [0..1] OF BITS 31 FOR [0..16_8fffffff] ?

What I am proposing isn't particularly difficult, it's not unportable,
either.  And much more powerful than any sets of pragmas.  Not tied to
your one architecture.

    Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120825/e30e70b6/attachment-0002.html>