"Paul Edwards" <mutazi...@gmail.com> wrote on 02.09.2021 22:05:39: > > Is this about supporting a 4GB address space instead > > of a 2GB space? > > Yes, correct.
OK, that makes things clearer. This implies in particular: - 4GB address space means you need to run in AMODE64 - AMODE64 means the native address size is 64 bits. This implies that Pmode has to be DImode, since Pmode tells the compiler what the native address size is. Specifically, if you try to run AMODE64 with Pmode equals SImode, the compiler will not be aware that the hardware uses the high 32 bits of base and index registers, and will not necessarily keep them zero. Also, the compiler will assume the base + index (+ displacement) arithmetic will operate in 32 bits -- I'm pretty sure this is actually the root cause of your "negative index" problem. > > Is it about supporting a 32-bit pointer type in an > > otherwise AM64 environment? (This is already used > > by the TPF target, but the 32-bit pointer will still > > refer to a 2GB address space.) > Yes, all pointers will be 32-bit – a normal 32-bit system. Note that even if Pmode == DImode, you can still use 32-bit *pointer* sizes. This is exactly what e.g. the Intel x32 mode does (as was mentioned by Andreas). > I’d like to approach the problem from the other > direction – what modifications are required to > be made to “-m31” so that it does “-m32” instead? > I’m happy to simply retire “-m31”, but I don’t care > if both exist. If you want to go for an "x32" like mode, I think this is wrong approach. The right approach would be to start from "-m64", and simply modify the pointer size to be 32 bits. This would work by setting POINTER_SIZE to 32, while leaving everything else like for -m64. I'm sure there will be a few other places that need adaptation, but it should be pretty straightforward. You can also check the Intel back-end where they're using the TARGET_X32 macro. We've thought about implementing this mode for Linux, but decided not to do it, since it would only provide marginal performance improvements, and has the drawback of being another new ABI that would be incompatible to the whole existing software ecosystem. (The latter point may not be an issue for you if you're looking into a completely new OS anyway.) Bye, Ulrich
