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

Sun Jan 28 04:46:03 CET 2018

https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4

IA-32 Function Calling Conventions - Apple Developer<https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4>
developer.apple.com
Describes the function-calling conventions used in the architectures supported by OS X.

If we generate portable C or C++, do it probably the way I said.

If we generate target-specific code, I386_DARWIN can assume 16-alignment (after adjusting by an odd multiple of 8).

But another way, is use the local struct, but maybe no pointer is needed.

There might be a portable way to get it aligned -- like by always putting a 64bit double or longlong at its start.

Or some compiler-specific attribute/declspec.

We'd have to determine if double is 16-aligned (I think not guaranteed) or if there is a portable-enough way.

Maybe C++11 alignas(16) or somesuch -- see generating C++ gets good exception handling, aligned stacks, etc. :)

 - Jay

________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Jay K <jayk123 at hotmail.com>
Sent: Sunday, January 28, 2018 3:42 AM
To: m3devel at elegosoft.com; rodney.m.bates at acm.org
Subject: Re: [M3devel] 64-bit alignment on 32-bit target?

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

 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20180128/7d916f15/attachment.html>