[M3devel] Modula-3 bitfields
Jay K
jay.krell at cornell.edu
Fri Aug 24 19:48:02 CEST 2012
Given:
struct foo
{
union
{
struct
{
unsigned a : 16;
unsigned b : 16;
} s;
unsigned c;
} u;
} foo = { {1, 2} };
printf("%X %X\n", c.u.s.a, c.u.s.b);
What do people expect?
Do people really have a mental model as to what the layout rules are for bitfields?
Are they obvious enough that every C compiler writer has actually implemented them the same and they become in a sense portable?
Furthermore, if presented with:
struct foo
{
unsigned a : 16;
unsigned b : 16;
};
void F1(struct foo* f);
printf("%X %X\n", f->a, f->b);
Foo = RECORD a, b: BITS 16 FOR INTEGER END;
<*EXTERNAL F1*> PROCEDURE F1(VAR foo: Foo);
VAR f := Foo{1,2};
F1(f);
What do people expect?
That is, 1) Does anyone really internalize the layout rules for bitfields?
2) Does anyone really need them to line up with C?
I ask because, it seems to me that in m3front/m3middle,
if Little_endian were removed and assumed either always
true or always false, everything would actually just work.
The only thing that would go wrong is
1) interoperability with C..when there are bitfields
2) including in m3core where floats are picked apart
2b) But that's kind of good -- we could remove the little vs. big endian distinction there.
See, I suspect but I am not certain the layout rules are actually well known to some small set of people, and they got encoded in m3front, in order for easier interoperability with C.
Repeat the above exercises for more complicated examples, i.e. bitcounts that aren't multiples of 16.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120824/78a92bbb/attachment-0001.html>
More information about the M3devel
mailing list