[M3devel] Another Allow_packed_byte_aligned issue

[Jay K]

I forgot to mention/ask: "packed" basically means "no padding", right?
 
 - Jay

 
From: jay.krell at cornell.edu
To: lists at darko.org; rodney_bates at lcwb.coop
Date: Sun, 27 Sep 2015 05:17:14 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Another Allow_packed_byte_aligned issue




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.
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 		 	   		  

_______________________________________________
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/20150927/ff518fad/attachment-0002.html>