[M3devel] posix/nt/32/64/endian platforms for C backend?

[Jay K]

Is bitfield layout really portable enough and predictable enough that interop is achievable?I don't know the layout algorithms myself.I don't really know what packed does.Change the alignment rules for the record?Remove all padding for alignment? And then access fields piecemeal in case anything is no longer aligned?I should experiment.

 - Jay



Subject: Re: [M3devel] posix/nt/32/64/endian platforms for C backend?
From: hosking at purdue.edu
Date: Tue, 18 Aug 2015 11:57:52 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


On Aug 18, 2015, at 9:43 AM, Jay K <jay.krell at cornell.edu> wrote:But if these are new targets, that can only generate C?I claim the endianness is arbitrary and only serves for interop with C bitfields and nothing else.
And doesn’t interrupt make sense wherever possible.  I would hope that there is a reasonable correspondence between C types and M3 types, particularly for RECORD and PACKED elements.
It doesn't matter what endianness you declare. It is likely to work correctly either way.I have to double check that integers and floats are initialized "at once", and not a byte at a time.
 - Jay



> Subject: Re: [M3devel] posix/nt/32/64/endian platforms for C backend?
> From: hosking at purdue.edu
> Date: Mon, 17 Aug 2015 09:49:37 +1000
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I strongly prefer that the front-end remain aware of target endianness (as it currently is for packing/unpacking bits in memory).
> It is important that there be some correspondence with the target.
> So, endianness should remain.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150818/a4d33cbb/attachment-0002.html>