[M3devel] Modula-3 bitfields

[Dragiša Durić]

On Aug 25, 2012, at 9:22 AM, Jay K wrote:

> 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.

Modula-3 can do everything needed, in ad-hoc and generally totally unportable manner :).

> 
> 
> 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.

Not if we have means to force both endianness of data and 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.

  I don't need much bitfield related interop with C. 32bit aligned pointers remain on my wish list :).

> 
> 
> 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.

libc interop is great, and I depend a lot on it. Thank you.


> 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..)

 :) This realy is a tangent. As my proposal was (localized to single structures) pragma, I don't see a link here.

dd

> 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/9cefe8e7/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/9cefe8e7/attachment-0002.sig>