[M3devel] packing problem… how exactly does modula-3 pack data into records??

[Jay K]

I believe our layout endeavors to be C compatible.
For some supposedly typical C behavior.
It is, I am pretty certain, endian-dependent.
I would like to remove that actually -- the frontend at this point knows very little
about each target, and I'd like to see if it can know even less.
It knows:
 word size
 endianness
 jmpbuf size


not much more.
jmpbuf size I know we can remove, but I had trouble when tried to fix that, about a year ago.
I've had much less time to work on  Modula-3 the past year or so. :(


(then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.)


I know it's a little wierd what I say -- C is impelementation-dependent and we try
to be C compatible. And m3core/libm3 used to have some dependency
on this C compatibility, e.g. the waitpid stuff. But I believe I removed all
such dependency.


 - Jay

From: dragisha at m3w.org
Date: Thu, 19 Jan 2012 18:47:39 +0100
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] packing problem… how exactly does modula-3 pack data into records??



Why wouldn't it be portable? What endiannes has to do with bit strings?
I don't think it is wrong to make it left-to-right-until-spent… As it's implementation dependent… ok… Why would not our implementation be left-to-….? :)
I think it's totally reasonable to expect from implementation exactly what I am expecting here and now.
As for C… I know several ways to implement this… And good ones. What I would like is to have cm3 doing it in obvious, intuitive way.
TIA

On Jan 19, 2012, at 5:28 AM, Jay K wrote: > packing data into record about packing bits left-right-until-spent?
It is not portable.
In particular, there is endianness variation.
The C spec leaves things up to implementation.

If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation.
Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking.
(Maybe still a few, like struct linger).
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120119/46de8624/attachment-0002.html>