> - 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. The compiler naturally keeps them zero. The instructions that are used to load registers do not pollute the high-order 32 bits. > 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. Where is this logic please? Can I do a #if 0 or similar to disable it? > 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’m happy to try the approach from BOTH directions and see which one hits “-m32” first. >> 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. That will generate 64-bit z/Arch instructions. I wish to generate ESA/390 instructions. > I'm sure there > will be a few other places that need adaptation, but > it should be pretty straightforward. No, modifying GCC is beyond my ability. I need 20 lines of code from someone who is familiar with the system. > You can also > check the Intel back-end where they're using the > TARGET_X32 macro. See above about beyond my ability. > 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. Shouldn’t the end user be able to decide this for themselves? No-one at all is interested in 32-bit mainframes? > (The latter point may not be an issue for you if you're > looking into a completely new OS anyway.) Correct. Thanks. Paul.
