[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
> > Example: 16-bit m68k > no, it's a 32bit platform with extra alignment requirements. Actually, fewer. Most architectures have alignof(x) == sizeof(x) for all the primitive types, but m68k is more relaxed and caps alignof(x) at 2. This means that assert((p & sizeof(long)) == 0) is too strict, and should instead just be assert((p & alignof(long)) == 0), which is always correct, rather than relying on implementation-defined alignment requirements. In autoconf there's AC_CHECK_ALIGNOF just as there is AC_CHECK_SIZEOF, the result of which should be used for the alignment check instead. That's the portable way to do it (and would allow the removal of the #ifdef). ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VZU4F6OQZ2ADHHH7ZWL7DGEIRRBBFQYR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
Barry Scott wrote: > > On 22 Feb 2021, at 12:40, Michał Górny mgo...@gentoo.org wrote: > > I'm talking about 16-bit memory alignment which > > causes SIGBUS if it's > > not respected on m68k. > > I don't understand why you consider this to be a problem. After all, > > x86 has stronger (32-bit) alignment requirements, so m68k is actually > > less likely to break. > > On x86 you can make unaligned access to memory. > Alignment is a nice to have for performance. > But on m68k you MUST align or you get a SIGBUS. > Barry That is not the problem. Many architectures (SPARC, PA-RISC, IA-64, ...) do not natively support unaligned accesses. The problem is in fact that m68k's alignment requirements are *weaker* than x86 *and they are exposed to C*. On x86, the compiler still aligns ints to 4 byte boundaries, but on m68k they are only aligned to 2 byte boundaries. This means that assert(p % sizeof(int) == 0) does not work. The code in question is #ifdef'ed out for three reasons: 1. The assert is overly strict. This is trivially fixed by changing the SIZEOF_SIZE_T to ALIGNOF_SIZE_T. 2. The `if` uses (and code within the `if` relies on it using) SIZEOF_SIZE_T to check the alignment. 3. The code is potentially slower on m68k than the simple byte-by-byte loop, though I don't think anyone's going to complain about slight performance regressions on m68k if it comes from cleaning up the code, and I imagine the supposed performance hit came from not fixing 2 properly (i.e. there was a bunch of extra code that wasn't able to be used that often due to overly-strict requirements in the algorithm). I have filed https://github.com/python/cpython/pull/24624 to fix all these, though the first smaller commit is the only one strictly required for correctness on m68k (and any other architecture that chooses/has chosen to make the same ill-advised choices in its ABI), whilst the second larger one makes minor changes to the algorithm (that should not affect performance on any supported architecture other than m68k), and the many copies of it, in order to also cope with ALIGNOF_SIZE_T < SIZEOF_SIZE_T. This thus improves m68k support whilst removing m68k-specific hacks and making the code less reliant on implementation-defined behaviour, i.e. is how portability patches are _meant_ to be. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CDZZLFTOVKWTZDA4YS45IU2NRLNUJ64Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Move support of legacy platforms/architectures outside Python
Michał Górny wrote: > On Mon, 2021-02-22 at 19:27 +0000, Jessica Clarke wrote: > > Example: 16-bit m68k > > no, it's a 32bit platform with extra alignment requirements. > > Actually, fewer. Most architectures have alignof(x) == sizeof(x) for > > all the primitive types, but m68k is more relaxed and caps alignof(x) > > at 2. This means that assert((p & sizeof(long)) == 0) is too strict, > > and should instead just be assert((p & alignof(long)) == 0), which is > > always correct, rather than relying on implementation-defined > > alignment requirements. In autoconf there's AC_CHECK_ALIGNOF just as > > there is AC_CHECK_SIZEOF, the result of which should be used for the > > alignment check instead. That's the portable way to do it (and would > > allow the removal of the #ifdef). > > I agree, except that -- as I mentioned elsewhere -- the #ifdef was added > because the x86 optimization hack is actually slower on m68k. I suspect > that if more benchmarking was made, it might turn out that #ifdef should > actually disable it on more platforms. I think it's more complicated than that. The code in question didn't just have a bogus assert, it actually relied on ALIGNOF_SIZE_T == SIZEOF_SIZE_T in order to work, but without much good reason other than being written in a poor style. I suspect that the slowdown was seen because the strictness of the `if` on m68k meant the optimised version wasn't used that often but was still sitting there using up space, and time to evaluate the branch, plus potentially the various consequences of additional register pressure, and that the performance hit goes away once the algorithm is fixed to be more general (in such a way that other architectures shouldn't see any performance hits, and possibly even a slight improvement). I've done this in https://github.com/python/cpython/pull/24624. Plus, even if m68k is slightly slower, who cares? It still works, better to have working clean code than hacky slightly-faster code. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PGR4QL3NXQXMSFG6KRTIKBCDM4UN4EU5/ Code of Conduct: http://python.org/psf/codeofconduct/
