[M3devel] Target.Allow_packed_byte_aligned

Jay K jay.krell at cornell.edu
Mon Sep 21 18:31:12 CEST 2015


 I guess we have other problems here -- packed records in the C backend. But maybe we can provide some good value here.
In particular:
 - I can put in the compiler-specific stuff, like:   #if _MSC_VER    #pragma pack(1)    #endif    at the top of every file.    Something for other compilers.     - In the frontend, doing layout, if any padding is inserted   in a record, insert an array of chars.    - generate static asserts that front end layout matches C layout  OR maybe just accept C layout.       - Jay

From: jay.krell at cornell.edu
To: hosking at purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Target.Allow_packed_byte_aligned
Date: Mon, 21 Sep 2015 14:41:02 +0000




I was asked what the point is: To have just one or two C outputs for distribution/bootstrapping.

Another option is I can verify that the n different outputs are the same and then eliminate them afterward.i.e. verify this setting makes no different for wide swaths of code, but still leave it there for other code.

Again, per-target packing rules don't allow the records to be as easily written by one target and read by another. Granted, such binary I/O is always problematic. Textual I/O is commonly used instead.

 - Jay


From: jay.krell at cornell.edu
To: hosking at purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] Target.Allow_packed_byte_aligned
Date: Mon, 21 Sep 2015 05:56:00 +0000




"stat" used to be packed and it was bad.It is no longer.

Let's say I'm interfacing with hardware.A lot of hardware can be presented to a variety of processors.For example, every x86, amd64, arm32, and arm64 device probably has USB.So target-specific rules don't help.

Let's say I'm interfacing with a file format.Again, target-specific rules are clearly wrong.

The only place this really makes sense is interfacingwith things like x86 interrupt descriptor tables and such (which do haveunnatural layout I believe).This can be handled by using chars and combing them, orcoming up with C code that uses whatever compiler-specific mechanism.

What is difficult to achieve is unnatural alignment and atomic access,even though x86/amd64 I guess support that -- at least as long as youaren't crossing a cache line. If you are crossing a cache line, thenI think one instruction is still going to exhibit non atomic access, at whichpoint you might as well read individual byte and reconstruct the larger integer.

And Modula-3 does have pragmas for types.<* lazyalign *> and <* strictalign *>

Arguably that is a better method -- as it might still give the same IR and Cacross all targets.

As well, let's say I am defining a file format.For this, it helps to have the same layout/alignment rules across all targets.Though I'm torn on this -- the alignment of a 64bit integer shouldtypically be only 4 bytes on a 32bit target, so something like:
RECORD a: Ctypes.int; b:LONGINT END;
should/can be smaller on a 32bit target.
I believe with the changes I made years ago,they will have the same layout, for better and worse.Given that I can't likely unify IR/C for word size, maybe we shouldfix that.
I should review the Win32 .i3 files for this, though it probablydoesn't occur, given the recentness of LONGINT.
 - Jay


Subject: Re: [M3devel] Target.Allow_packed_byte_aligned
From: hosking at purdue.edu
Date: Mon, 21 Sep 2015 14:57:15 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu



Sent from my iPhone
On Sep 21, 2015, at 2:40 PM, Jay K <jay.krell at cornell.edu> wrote:




You mean, the source code will be in target-specific directories?Isn't expected to be portable anyway?Yet we should still provide a way to do it?
Yes to all.  M3 is meant to be a systems programming language and packed types are the way you handle layout for specific targets. Are you sure we don't have packed types in the libraries?  I thought we used to.


I'm kinda keen on just not having them.Very little code needs them.

I'd like to eliminate target-specificity, so that C code from the C backendcan be used to bootstrap any platform. I'm resigned to not quite make it there,but I don't want unnecessary variation anyway.

I think can I decree the C backend is always big endian.But word size I can't eliminate due to access to external data structureswith size_t/integer. So we'd always have at least two C targets -- 32bitand 64bit.

Non-C targets can retain their "correct" endianness.They don't interoperate anyway because of nested function implementation varying.

Again, this was only true for x86/amd64.And there is a strange pragma to allow it on modules or types.Instead of always on the target.

Allowing it on types is kinda close to what Visual C++ offers -- something scopedinstead of global.

 - Jay


Subject: Re: [M3devel] Target.Allow_packed_byte_aligned
From: hosking at purdue.edu
Date: Mon, 21 Sep 2015 14:30:15 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Packed will generally be target-specific no?

Sent from my iPhone
On Sep 21, 2015, at 12:51 PM, Jay K <jay.krell at cornell.edu> wrote:




I don't believe this is portable.Such code would only compile for x86/amd64 targets.I think.We want to cater to such target-specific constructs?I should confirm it is target-specific?I want to eliminate gratuitous target-specific aspects and devolve the IR to having essentially 3 variables -- word size and endian and NT vs. posix. Fewer if I can manage to.

 - Jay


Subject: Re: [M3devel] Target.Allow_packed_byte_aligned
From: hosking at purdue.edu
Date: Mon, 21 Sep 2015 12:47:07 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Packed types are part of the language and their behavior should be preserved. Just because we don't use it on the libraries others do!

Sent from my iPhone
On Sep 21, 2015, at 12:19 PM, Jay K <jay.krell at cornell.edu> wrote:




I don't think so.I built the system with it.Granted, only one target.
If we had something likeTYPE T =  BITS BITSIZE(INTEGER) + 8 FOR PACKED RECORD  a: CHAR  b:INTEGEREND;
I think it'd break that.I'm not sure we any longer use packed types.And such things would only work for x86/amd64 I believe.
 - Jay


Subject: Re: [M3devel] Target.Allow_packed_byte_aligned
From: hosking at purdue.edu
Date: Mon, 21 Sep 2015 10:44:59 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

We should be careful here. Might break something, no?

Sent from my iPhone
On Sep 21, 2015, at 2:53 AM, Jay K <jay.krell at cornell.edu> wrote:




I propose that Allow_packed_byte_aligned be set to FALSE for all targets.
Or make it const.

Or remove it.

This will degrade slightly x86/amd64 but in, I speculate, fairly rare paths.Specifically, if you manage to create a packed type with unaligned fields,presumably loads/stores get converted to multiple aligned loads/stores followedby putting stuff back together. The occurrence of the unaligned fields shouldbe very rare in the first place.

I does not affect any other target.

Granted, x86 and amd64 are the most common targets.

Ok? - Jay


 		 	   		 !
  
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
 		 	   		  
 		 	   		  
 		 	   		   		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150921/87dc1837/attachment-0002.html>


More information about the M3devel mailing list