"Paul Edwards" <mutazi...@gmail.com> wrote on 02.09.2021 17:26:25:
> > Therefore again my question, what is the actual goal > > you want to achieve? I'm still not sure I understand > > that ... > I would like to know what is required to implement > “-m32” in the S/390 target. I realize that z/Arch > doesn’t have a specific AM32, but I don’t need a > specific AM32. What would actually happen if you > coded a “-m32” and then ran it in an AM64 > environment? That depends on what that would actually do. I'm still not quite sure what the actual requirements are. Is this about supporting a 4GB address space instead of a 2GB space? (I'm not aware of that being used anywhere currently.) 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.) Is it something else? In either case, what is the actual benefit of that mode? (I.e. what benefit would justify the effort to implement it?) > >> Also, I just realized – if GCC is using LA for maths > >> for 32-bit registers, then values will be limited to > >> 2 GiB instead of 4 GiB for unsigned, but that is not > >> the case. > > > That's why GCC makes sure to only use the instruction > > when a 31-bit addition is wanted. This can be the > > case either when GCC can prove that the involved > > operands are pointer values (which are by definition > > restricted to 31-bit values in -m31 mode) > > The compiler doesn’t create a restriction there. > It just generates a simple LA and it works > differently depending on whether it is AM24/31/64. It is the other way around. The compiler knows exactly how the LA instruction behaves in hardware, and will use the instruction whenever that behavior matches the semantics of (a part of) the program. Since the behavior of the instruction differs based on the addressing mode, the compiler will have to know which mode the executable will be running in. Currently, the -m31/-m64 switch basically changes several things (at the same time): - the assumption on which AM the executable will run in - the (used) size of a general-purpose register - the (default) size of a pointer type - ABI (function calling convention) details In theory, it would be possible to split this apart into distinct features, so that it would be possible to implement a mode where you can have code that uses 32-bit pointers but is running in AM64 (which would then support a 4 GB address space). Is this what you mean by an "-m32" mode? Basically, this would involve looking at all uses of the TARGET_64BIT macro in the back-end and determine which of them actually depend on which of the above features, and disentangle it accordingly. I guess that would be possible, but it requires a nontrivial effort. Bye, Ulrich
