[M3devel] Target.Allow_packed_byte_aligned

Mon Sep 21 16:41:02 CEST 2015

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