[M3devel] Target.Allow_packed_byte_aligned

[Jay K]

Sorry, clarification:
 struct A  {   char a;   int b;  };

is defined and fairly portable in C, and means generally the same thing onall platforms (ignoring 16bit int), the same thing as:
RECORD a: Ctypes.char b: Ctypes.intEND;
what is not portable in C is expecting this to have other than size 8.
Strictly speaking, its size is completely not portable, but on the vast vast majorityof systems its size is 8, and getting it less requires compiler-specific mechanisms.

  - Jay


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

But it us defined in C, just target-specific.

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




 ps, you can't even do this portably in C.

 struct A  {   char a;   int b;  };

  will have padding between a and b on all systems.  The way to eliminate it varies by compiler, #pragma pack for Visual C++, something else with gcc.  And might result in an alignment fault.

 And we do have this wacky LAZYALIGN pragma that that might make it work.  Really that pragma is weird. You might get the packed layout, but you'll also get alignment faults on some targets, unless we decompose the reads into byte by byte -- assuming this isn't hardware access that demands a single access.

In C you have a chance with:
struct A{ char a; char b[4];};
and then maybeA a;
*(int*)&a.b;

but it will fault on most target -- but not x86/amd64.

If you don't need one read, you can do:

 int c = a.b[0]  b <<= 8; b |= a.b[1];  b <<= 8; b |= a.b[2]; b <<= 8; b |= a.b[3]; 

or such.
You can do like that in Modula-3 also.

So I don't see a strong need to support these things.

 - 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 02:51:08 +0000




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/f7880933/attachment-0002.html>