[M3devel] Another Allow_packed_byte_aligned issue

[Rodney Bates]

-Rodney Bates

--- jay.krell at cornell.edu wrote:

From: Jay K <jay.krell at cornell.edu>
To: Darko Volaric <lists at darko.org>, Rodney Bates <rodney_bates at lcwb.coop>
CC: m3devel <m3devel at elegosoft.com>
Subject: RE: [M3devel] Another Allow_packed_byte_aligned issue
Date: Sun, 27 Sep 2015 05:17:14 +0000

I agree it is probably messed up, but I wonder if another approach or approaches can/should be taken.
1)
I wonder if the boolean should be true for all targets.And the pragmas removed, or changed to do nothing.
And, here comes the important part: for any unaligned load/store, m3front break it down into multiple smaller loads/stores

Upsides: same predictable layout for all targets same does-it-compile/does-it-not-compile behavior for all targets
Downsides: possibly atomic accesses are no longer atomic possibly "efficient" accesses are no longer atomic.

I'm just speculating here, but I would think that if it crosses a boundary of the 
hardware RAM word, (not necessarily the same as a CPU native word) it would be 
non-atomic anyway, regardless of whether the compiler or the CPU took care of 
juggling the separate pieces.  In fact, I get the impression that, even within 
a single RAM word, you can't count on atomicity of even an aligned, single-word 
load or store, with modern multi-CPUs, multi-level hardware caching, etc. 

2)Similar to before:  allow same layouts on all architecures
but on architectures where alignment doesn't matter much, just do the unaligned loads/stores
Keep in mind that "interlocked" alignment does reportedly matter on x86 -- x86 is not really entirely alignment-agnostic.I believe alignment of avx loads/stores sometimes matters too -- again, x86 does care sometimes.
And the rules are more complicated than m3front/m3middle can encode.
Not that we have any avx data types.I'd have to experiment more on the sse2 stuff which we do presumably use.
And yes I agree it generates alignment faults on some targets.We should be able to reproduce this easily enough e.g. on SPARC.
(Not to mention that x86 can be asked to take alignment faults...it is a mode bit in the processor, that justtends to be off.)
 - Jay


Date: Sat, 26 Sep 2015 18:27:59 -0700
From: lists at darko.org
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Another Allow_packed_byte_aligned issue

I implemented the byte aligned packing functionality and the Allow_packed_byte_aligned flag was supposed to be a constant that signified that the target CPU allows byte alignment thus relaxing the normal packing restrictions.

I can't speak for the implementation of the pragma (or later changes), but I think it should be removed since (in my mind) it doesn't serve any useful purpose.

On Sat, Sep 26, 2015 at 12:23 PM, Rodney Bates <rodney_bates at lcwb.coop> wrote:
In trying to better understand the issue, I see, in Module.m3:895, this code:

    Target.Allow_packed_byte_aligned := t.containsLazyAlignments;

>From other places, containsLazyAlignments derives from LAZYALIGN 
pragmas, so this means it will turn on Allow_packed_byte_aligned,
regardless of the target, if there is a LAZYALIGN pragma.  I think this
will generate code that will alignfault, if the target CPU doesn't
support it.  That would be a bug. 


-Rodney Bates

_______________________________________________

M3devel mailing list

M3devel at elegosoft.com

https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel





_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel