[M3devel] max_align

Sat Feb 27 20:11:18 CET 2010

The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter.

 We probably don't generate atomic operations against them.

  I already changed it to 64 for the front/middle ends

But right, max_align is wrong for a few targets.

I believe max_align ends up being basically target-independent. It is always 64.

 Types are always aligned on their size.

The only exceptions are 68K platforms where max_align is possibly 2 bytes.

  68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list.

PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs

that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems

like a language hole to me.

I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86.

 - Jay

> From: hosking at cs.purdue.edu
> Date: Sat, 27 Feb 2010 11:10:32 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] TInt/TWord/N
> 
> Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though.
> On 27 Feb 2010, at 02:34, Jay K wrote:
> 
> > 
> >> As I understand it your stuff in m3back is mostly working.
> >> I took a look at the code there and I see a number of issues
> > 
> > 
> > Tony, I don't know of anything that isn't working.
> > Please let me know.
> > All 64bit operations should work. atomic32 should work.
> > Not yet atomic8/16/64, soon.
> > Oh there is an alignment issue once atomic64 is there.
> > It's present on other platforms too, for different reasons (incorrect max_align).
> > 
> > 
> > Thanks,
> > - Jay
> > 
> > 
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Sat, 27 Feb 2010 01:16:32 -0500
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] TInt/TWord/N
> >> 
> >> The solution is not to push upstream into m3middle.
> >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime.
> >> 
> >> -- T
> >> 
> >> On 26 Feb 2010, at 23:48, Jay K wrote:
> >> 
> >>> 
> >>> Tony, I just don't understand what is wrong with TIntN, TWordN.
> >>> They are what TInt/TWord did for a long time after all. ?
> >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks.
> >>> 
> >>> 
> >>> - Jay
> >>> 
> >>> 
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500
> >>>> To: jkrell at elego.de
> >>>> CC: m3commit at elegosoft.com
> >>>> Subject: Re: [M3commit] CVS Update: cm3
> >>>> 
> >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this.
> >>>> 
> >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote:
> >>>> 
> >>>>> CVSROOT: /usr/cvs
> >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34
> >>>>> 
> >>>>> Modified files:
> >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
> >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3
> >>>>> Wrx86.i3 Wrx86.m3 m3makefile
> >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3
> >>>>> TWordN.i3 TWordN.m3 Target.i3
> >>>>> Target.m3 m3makefile
> >>>>> Removed files:
> >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3
> >>>>> M3BackWord.m3
> >>>>> 
> >>>>> Log message:
> >>>>> introduce type Target.IntN which is Int plus a precision
> >>>>> just like the old Target.Int
> >>>>> (previously M3BackInt.Int)
> >>>>> 
> >>>>> make TIntN and TWordN support it
> >>>>> they are just thin wrappers over TInt, TWord
> >>>>> previously named M3BackInt, M3BackWord
> >>>>> 
> >>>>> add small amount of support to TInt:
> >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate
> >>>>> These could, if desired, go into their only users: TIntN, TWordN.
> >>>>> (with the understanding that that Target.Int is "revealed" to them.)
> >>>>> 
> >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision
> >>>>> 
> >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged
> >>>>> This is "just" additions.
> >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.)
> >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN)
> >>>>> (A little unsatisfactory that N is bytes instead of bits.)
> >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) )
> >>>>> 
> >>>>> While at it, in TIntN, rename things slightly:
> >>>>> FromInt => FromHostInteger
> >>>>> ToInt => ToHostInteger
> >>>>> 
> >>>>> "Int" is "Target.Int"
> >>>>> "HostInteger" is "INTEGER"
> >>>>> 
> >>>>> again, TInt/TWord/m3front/m3middle not much affected.
> >>>>> 
> >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds
> >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we
> >>>>> really need INTEGER to be 4 bytes throughout m3back?
> >>>>> (I know that mklib has little endian dependency.)
> >>>> 
> >> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100227/d66cf5e4/attachment-0002.html>