[M3devel] Modula-3 bitfields

[Dragiša Durić]

Did I said in my first post, pragma? With pragma you don't activate a behavior unless you need something pragma provides. Locally, in pragma's scope. So you will not break anything, anywhere outside pragma's scope.

gm2 is very precise with bitpacking and aligning. I did not check for byte/bit order, or anything gm2 recently, too much work (most of it in Modula-3). As this is perfectly logical system programming requirement I do not doubt Gaius will be positive to such proposal.

What good is bitfield interop when our pointers are 64bit aligned and GCC's are 32bit? And when every interop question is answered with "write critical piece in C" ? 

Proposed pragma would not break anything, it is local behavior.

I believe in "mental model", but I also believe in evolution. Do you? :) All of us have decades of experience accumulated, and my decades changed my models, as slow as it is. I see this pattern, I see this need. I see solution through alternate bit/byte packing into structures inside pragma scope.

As for your example, outside of proposed pragma scope it will be 32 bit aligned. But, if it is a 64 bit value - in GCC it will be 32bit aligned, while cm3 will (most probably) align it to 64bit. There goes interop. Ooops.

TIA

--
Divided by a common language

Dragiša Durić
dragisha at m3w.org




On Aug 25, 2012, at 5:06 AM, Jay K wrote:

>  > 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;
> };
> ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120825/8bd7d4f1/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120825/8bd7d4f1/attachment-0002.sig>