[M3devel] Target.Allow_packed_byte_aligned

Jay K jay.krell at cornell.edu
Mon Sep 21 06:40:46 CEST 2015


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?

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


More information about the M3devel mailing list