>> > 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? > This is not in one single place, but spread throughout the > compiler, both common code and back-end. I do not think it will > be possible to get the compiler to generate correct code if > you do not specify the address size correctly. 1. Is there any way to put a constraint on index registers, to say that a particular machine can only index in the range of –512 to +512 or some other arbitrary set? If so, I can do 0 to 2 GiB. 2. Is there a way of saying a machine doesn’t support indexing at all? >> > 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. > Why? AMODE64 exists only in z/Arch, so of course there > will be z/Arch instructions available ... For the same reason people constructed Babbage’s invention, I wish to demonstrate the minor changes that would have been required to the S/360 so that we would never have arrived at a 31-bit black hole, and we could have in fact had the perfect 32-bit machine. Almost identical to the 31-bit machine. A S/360+, a S/370+ and a S/390+. >> > 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? > It's open source, of course everybode can decide what they > want to work on themselves. But we decide what we spend > our own time on based on we think is useful ... Sure. >> No-one at all is interested in 32-bit mainframes? > Not any more, at least not in Linux. Linux is pretty much > 64-bit only at this point. I think z/OS is pretty much still 31-bit only, as far as apps are concerned, right? I’d like to bump that up to 32-bit. BFN. Paul.
