From rodney_bates at lcwb.coop Thu Jan 18 18:51:56 2018 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Thu, 18 Jan 2018 09:51:56 -0800 Subject: [M3devel] Github commit messages on m3devel? Message-ID: <20180118095156.5462D77@m0117566.ppops.net> Do we want auto messages from Github for commits to come also to m3devel? -Rodney Bates From lists at darko.org Thu Jan 18 18:57:40 2018 From: lists at darko.org (Darko Volaric) Date: Thu, 18 Jan 2018 18:57:40 +0100 Subject: [M3devel] Github commit messages on m3devel? In-Reply-To: <20180118095156.5462D77@m0117566.ppops.net> References: <20180118095156.5462D77@m0117566.ppops.net> Message-ID: If we have them coming to m3devel then we should probably trash the M3 Commit list since it would just be duplication. Personally I find it annoying having commit messages intermingled with the discussion group. On Thu, Jan 18, 2018 at 6:51 PM, Rodney Bates wrote: > > Do we want auto messages from Github for commits to come also to m3devel? > > > -Rodney Bates > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jan 18 21:13:34 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 18 Jan 2018 15:13:34 -0500 Subject: [M3devel] Github commit messages on m3devel? In-Reply-To: References: <20180118095156.5462D77@m0117566.ppops.net> Message-ID: <20180118201334.GA13164@topoi.pooq.com> On Thu, Jan 18, 2018 at 06:57:40PM +0100, Darko Volaric wrote: > If we have them coming to m3devel then we should probably trash the M3 > Commit list since it would just be duplication. Personally I find it > annoying having commit messages intermingled with the discussion group. Suggesting they should go to the M3 Commit list. -- hendrik From rodney_bates at lcwb.coop Wed Jan 24 22:38:49 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Jan 2018 15:38:49 -0600 Subject: [M3devel] Compiler and language problems with packed types Message-ID: There are a number of cases where the compiler crashes with messages like: ** INTERNAL CG ERROR *** unable to find integer type? type=Word.64 size/offset/align=64/20/32 In working on these, I also find cases where the compiler does not crash but is out of compliance with the language, and/or the language is not clear. 2.2.5 Packed Types clearly says (concerning BITS n FOR Base): "variables of type T *that occur in records, objects, or arrays* will occupy exactly n bits and be packed adjacent to the preceding field or element." So for scalar variables, the BITS n FOR should have no effect on allocated size or alignment. For scalar local variables and formal parameters, the compiler complies. For global variables, it does not. For example, for BITS 15 FOR CHAR, it rounds n up to 16 and allocates that. In all cases, scalar, global, even record fields, BITSIZE always reports n, regardless whether this agrees with actual allocated space. BYTESIZE always reports BITSIZE rounded up and converted to bytes. ADR crashes the compiler on non-byte-aligned fields. The language doesn't define the 3 sizes nor ADR for non-byte-aligned, packed variables, scalar or otherwise. Aside from fixing the crashes, I propose the following: 1) Fix the compiler to allocate global scalars unpacked, per the language. 2) For scalar variables, make BITSIZE, BYTESIZE, and ADRSIZE report according to the actual allocation, not the ignored packed size. This is both a language clarification and a compiler fix. 3) Applied to types, make BITSIZE report according the n, in other words, as if the type were used for a field or element. This is already happening in the compiler, but is not defined by the language. 4) Applied to types, make BYTESIZE and ADRSIZE round up to whole bytes. This is what is happening now, but is not defined by the language. Or would it be better to make a static error if the address is not statically known to be a byte multiple? 5) For ADR, make it a static error if the address is not statically known to be a byte multiple. 2), 3), 4), and 5) entail adding better definition to the language. 1), 2), 5), and the 2nd alternative in 4) entail compiler changes. 5), however would only change a compiler crash to a static error. It is possible there is existing code that would be sensitive to some of the compiler changes. I have seen a lot of low-level bit twiddling code that appears to have been written on the assumption that BITS n FOR also affects allocation of scalars, although I am not sure how much of it actually depends on this. Only global scalars would be affected. Any thoughts? -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Fri Jan 26 07:20:39 2018 From: lists at darko.org (Darko Volaric) Date: Fri, 26 Jan 2018 07:20:39 +0100 Subject: [M3devel] Compiler and language problems with packed types In-Reply-To: References: Message-ID: ADR should only be able to return a valid address for the architecture, allowing any byte aligned address may be too permissive. Either way this should be defined to be implementation dependent since there may be performance considerations. It should be a static error to take the address of something that doesn't produce a valid address and one that actually points or can point to the data in question. I think that that BITSIZE should report the declared number of bits (the minimum number of bits allocated) with BYTESIZE reporting the actual allocated size of the field or variable (eg: after alignment). Both are valuable information. What is the point of BYTESIZE if it can simply be derived from BITSIZE? If we're interfacing with say C, and a global there is defined to be 16 bits, how do we define that in M3? Do we make a subrange and assume the compiler will do the right thing? How can we be sure that we're not overwriting adjacent data in that global data space in the C code? On Wed, Jan 24, 2018 at 10:38 PM, Rodney M. Bates wrote: > There are a number of cases where the compiler crashes with messages like: > > ** INTERNAL CG ERROR *** unable to find integer type? type=Word.64 > size/offset/align=64/20/32 > > In working on these, I also find cases where the compiler does not crash > but > is out of compliance with the language, and/or the language is not clear. > > 2.2.5 Packed Types clearly says (concerning BITS n FOR Base): > > "variables of type T *that occur in records, objects, or arrays* > will occupy exactly n bits and be packed adjacent to the preceding > field or element." > > So for scalar variables, the BITS n FOR should have no effect on > allocated size or alignment. For scalar local variables and formal > parameters, the compiler complies. For global variables, it does not. > For example, for BITS 15 FOR CHAR, it rounds n up to 16 and allocates > that. > > In all cases, scalar, global, even record fields, BITSIZE always > reports n, regardless whether this agrees with actual allocated space. > BYTESIZE always reports BITSIZE rounded up and converted to bytes. > > ADR crashes the compiler on non-byte-aligned fields. > > The language doesn't define the 3 sizes nor ADR for non-byte-aligned, > packed variables, scalar or otherwise. > > Aside from fixing the crashes, I propose the following: > > 1) Fix the compiler to allocate global scalars unpacked, per the language. > > 2) For scalar variables, make BITSIZE, BYTESIZE, and ADRSIZE > report according to the actual allocation, not the ignored > packed size. This is both a language clarification and a > compiler fix. > > 3) Applied to types, make BITSIZE report according the n, in > other words, as if the type were used for a field or element. > This is already happening in the compiler, but is not defined > by the language. > > 4) Applied to types, make BYTESIZE and ADRSIZE round up to whole bytes. > This is what is happening now, but is not defined by the language. > Or would it be better to make a static error if the address is not > statically known to be a byte multiple? > > 5) For ADR, make it a static error if the address is not statically > known to be a byte multiple. > > 2), 3), 4), and 5) entail adding better definition to the language. > > 1), 2), 5), and the 2nd alternative in 4) entail compiler changes. > 5), however would only change a compiler crash to a static error. > > It is possible there is existing code that would be sensitive to some > of the compiler changes. I have seen a lot of low-level bit twiddling > code that appears to have been written on the assumption that BITS n > FOR also affects allocation of scalars, although I am not sure how > much of it actually depends on this. Only global scalars would be > affected. > > Any thoughts? > > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Jan 26 19:35:28 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 26 Jan 2018 12:35:28 -0600 Subject: [M3devel] 64-bit alignment on 32-bit target? Message-ID: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> 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 From jayk123 at hotmail.com Fri Jan 26 20:09:51 2018 From: jayk123 at hotmail.com (Jay K) Date: Fri, 26 Jan 2018 19:09:51 +0000 Subject: [M3devel] 64-bit alignment on 32-bit target? In-Reply-To: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> References: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> Message-ID: I believe LONGINT should be 64-aligned on 32-bit x86 so for example you can use InterlockedCompareExchange64 on it. I suggest LONGINT should be 64-aligned so maybe all targets have the same layout, in general. - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Jan 28 04:08:12 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 27 Jan 2018 21:08:12 -0600 Subject: [M3devel] 64-bit alignment on 32-bit target? In-Reply-To: References: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> Message-ID: <5e1f1387-bdeb-22b6-d7c1-93135d391710@lcwb.coop> 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 on behalf of Rodney M. Bates > *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 From jayk123 at hotmail.com Sun Jan 28 04:42:19 2018 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Jan 2018 03:42:19 +0000 Subject: [M3devel] 64-bit alignment on 32-bit target? In-Reply-To: <5e1f1387-bdeb-22b6-d7c1-93135d391710@lcwb.coop> References: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> , <5e1f1387-bdeb-22b6-d7c1-93135d391710@lcwb.coop> Message-ID: 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 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 on behalf of Rodney M. Bates > *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: From jayk123 at hotmail.com Sun Jan 28 04:46:03 2018 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Jan 2018 03:46:03 +0000 Subject: [M3devel] 64-bit alignment on 32-bit target? In-Reply-To: References: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> , <5e1f1387-bdeb-22b6-d7c1-93135d391710@lcwb.coop>, Message-ID: 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 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 on behalf of Jay K 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 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 on behalf of Rodney M. Bates > *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: From hendrik at topoi.pooq.com Sun Jan 28 10:59:13 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 28 Jan 2018 04:59:13 -0500 Subject: [M3devel] 64-bit alignment on 32-bit target? In-Reply-To: References: <8bce60bf-4820-b3d6-8368-25addcc2faba@lcwb.coop> <5e1f1387-bdeb-22b6-d7c1-93135d391710@lcwb.coop> Message-ID: <20180128095913.GA19016@topoi.pooq.com> 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 > 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 on behalf of Rodney M. Bates > > *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