[M3devel] Modula-3 bitfields

[Jay K]

1) Most likely, whatever you want, you can get with Modula-3.
You can at least attain the compactness you want.
How you match up with some specified protocol, independently
implementable e.g. with C and shifting/masking, less certain.


2) If this is for some network/persistant I/O, the result will
not be portable. At least due to endianness. Possibly due to alignment.


3) I claim that interop with C remains a strong feature of Modula-3,
but not necessarily regarding bitfields. There is some attempt at such
interop, but I'd just as soon ignore it. I'd even give an error
if types with bitfields are used with <* external *> functions.


For my libc interop, I'm very conservative -- records contain just
longint and integer, sorted by size -- there is never any padding,
except maybe at the end.
I looked a bit through "windows.i3" and "xlib.i3" and decided
they seem pretty save too.



3) I am faced with generating target-independent C.
This is the worry/doubt I inject/tangent into your line of questioning.
  You ask about one thing, I bring up something else (kind of like Daniel..)
m3front checks endian, making it almost impossible.
I fear there isn't a good answer here.
I kind of would just like to a) remove the check b) adjust
{libm3, m3core}/float accordingly.
Alternatively, change m3front/m3cg some.
Have the result say:


#ifdef LITTLE_ENDIAN
something
#else
something else
#endif


Perhaps the endian check can be removed if the target platform is "C"?


Relevant aside:
"By default", in C#, layout is undefined.
It could sort the fields by size/name, I think, and be valid.
  Or put stuff near each other based on runtime profiling.
  Is Modula-3 this abstracted too??
But there are at least two ways to control the layout.
You can assert that it must be "sequential".
You can give actual offsets.
I don't think C# even has bitfields though.


 - Jay




Subject: Re: [M3devel] Modula-3 bitfields
From: dragisha at m3w.org
Date: Sat, 25 Aug 2012 08:31:16 +0200
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: mika at async.caltech.edu

I see no problem with this. 
As I have illustrated, we are already apart from "implied mapping to C". Also - proposed pragma is local behavior. Not active unless you need it, but when you need it you will be really grateful for it :).

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



On Aug 25, 2012, at 7:35 AM, Mika Nystrom wrote:Yeah I think Modula-3 historically tries to stay as close as possible to
an implied mapping to C.  It's definitely *not* big-endian on a little-endian
machine.

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