[M3devel] 64-bit alignment on 32-bit target?

[Hendrik Boom]

On Sun, Jan 28, 2018 at 03:42:19AM +0000, Jay K wrote:
> Well, those are good points, I hadn't thought of it, however:
> 
> 
>   - Sections within an image must be page aligned. That is how Windows works and it is all but necessary, to have different page attributes.
> 
>  - Heap on Windows is 2x pointer aligned, so that is adequate. To layer that on top of an unaligned heap is cheap enough. Heap being expensive anyway. WIndows has this _aligned_malloc thing but it is overused, since the builtin alignment is usually adequate.
> 
> 
> - Leaving the stack. Dynamic static alignment on x86 has been a thing for a long time, like because SSE/XMM. Because you are right the typical x86 ABI stack alignment is probably 4 or maybe 1. I bet MacOSX already is 16 since it was SSE/XMM from the start (and 32bit is on the way out anyway).
> 
> 
> Dynamic stack alignment should be achievable at the Modula-3 level but with higher cost than what C compilers do.
> 
> 
> The C compiler can save the stack pointer, allocate extra, round it, and use the same offsets after that, with no impact to code beyond the prolog.
> 
> 
> To do this portably however, we would have to..imagine generating 
> C..put all aligned locals in a struct, pad the struct with 
> alignment-1, get a pointer to the struct, and then align that, and 
> use that, constant indirection for every access. It isn't as bad as 
> it sounds because it would only be needed for local structs that 
> contain a LONGINT (recursively).

I remember one IBM processor where it only cared about the alignment of 
the first (recursively) element of the structure, and not on the others.
So if the first element was 64 bits, the whole structure would be so 
aligned, but if other elements were 64 bits they didn't affect the 
alignment at all.

I ever figured out any rationale for this bizarre behaviour.  That was 
beck in the late 80's. early 90's.

-- hendrik
 
> 
> 
>  - Jay
> 
> 
> 
> ________________________________
> From: Rodney M. Bates <rodney_bates at lcwb.coop>
> Sent: Sunday, January 28, 2018 3:08 AM
> To: m3devel at elegosoft.com; Jay K
> Subject: Re: [M3devel] 64-bit alignment on 32-bit target?
> 
> This would be nice, but thinking about it more, this seems like a huge tar pit.
> 
> Aligning *within* a record, array, activation record, heap object, global area, etc. can be
> done with existing mechanisms just by setting the alignment for LONGINT.  But getting these
> entire areas 64-aligned on a 32-bit target is messy.
> 
> For example, for stacks, you either have to make every field 64-aligned, so it is always that way
> or do runtime alignment, conditional on whether it's already 64-aligned, at call sites, before
> pushing any parameters, return address, etc.  Neither is nice.  And it's difficult to do it
> conditionally on whether the to-be-called AR contains 64-aligned fields (usually not) because
> you don't necessarily have anything but the signature for the callee when compiling call site code.
> 
> All heap objects pretty much have to be 64-aligned.  I think mixed alignments of heap objects
> has probably been shown to be a real mess, and in the case of opaque types, you may not know
> at the NEW site what the needed alignment is anyway.
> 
> Also, the linker and loader would have to put sections on 64-bit boundaries as well. Maybe some
> do, but we can hardly depend on it universally, and these are tools we don't control.
> 
> On 01/26/2018 01:09 PM, Jay K wrote:
> > I believe LONGINT should be 64-aligned on 32-bit x86 so for example you can use InterlockedCompareExchange64 on it.
> 
> Is it feasible to implement a 64-bit atomic operation on a 32-bit machine anyway, with, often,
> 32-bit RAM access?  That would entail making a pair of accesses to a pair of words all atomic.
> And if that could happen, the pair probably wouldn't need to be 64-aligned anyway.
> 
> >
> > I suggest LONGINT should be 64-aligned so maybe all targets have the same layout, in general.
> >
> >
> >  - Jay
> >
> >
> >
> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > *From:* M3devel <m3devel-bounces at elegosoft.com> on behalf of Rodney M. Bates <rodney_bates at lcwb.coop>
> > *Sent:* Friday, January 26, 2018 6:35 PM
> > *To:* m3devel
> > *Subject:* [M3devel] 64-bit alignment on 32-bit target?
> >
> > Does anybody know:
> >
> > Do we support, or does there even exist, a target that has 32-bit native words,
> > but has some instruction or other reason why some operand would need to be
> > 64-bit aligned?
> >
> > We appear to be 64-bit aligning LONGINT and big enough subranges thereof on
> > 32-bit targets, which then needs to propagate through records, arrays, and objects
> > that contain them, as well as all heap allocated objects, stack frames, etc.
> >
> > --
> > Rodney Bates
> > rodney.m.bates at acm.org
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> >
> >
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> >
> 
> --
> Rodney Bates
> rodney.m.bates at acm.org

> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel