I believe such an approach might break C semantics regarding
pointer addition?
In a 32-bit address space (where presumably only 32-bits of the
register are used to address a value) the addition of a pointer past-the-end
(or prior to the start) of an addressable object is undefined. C compilers
(include the Dignus compiler) make use of that to perform some pretty
clever optimizations. Any addressable object in this 32-bit address
space must be within that 4G of space, so to get these optimizations
correct, the compiler/optimizer can safely assume wrap-around at 32-bits.
So, if you are constraining pointers to being 32-bits, you really can’t
address memory outside of that range [0-4G].
But, if you are saying “hey - I’d like to _actually_ have a special 64-bit AMODE
where pointers are really 64-bits, but I’m guaranteed to be able to allocate
(malloc) memory in the first 4G, _and_ I’m guaranteed that my stack comes
from the first 4G, _and_ I’m guaranteed that my program is loaded in
the first 4G” That’s a different beast… and I don’t think it
fits in the Linux memory model… (where stack addresses, for example,
start pretty high in the virtual address space.)
You might be able to hack-away a Linux kernel to create a hybrid OS
that does this… but I don’t think the Linux developers would accept it
into the canonical sources.
- Dave Rivers -
> On May 23, 2018, at 2:57 AM, Paul Edwards <[email protected]> wrote:
>
>>
>> Hi Timothy.
>>
>
> Great questions.
>
> I don't want to use -m64 because that uses the
> 64-bit registers for everything, but I wish to produce
> compact modules using only 32-bit registers and
> pointers.
>
> I would think that most ELF32 programs are already
> able to use the full 4 GiB address space without
> needing a recompile. malloc() can start returning
> addresses in the 2 GiB - 4 GiB range.
>
> The only fly in the ointment that I know of is if an
> application program does a negative index
> expecting that to wrap at 32 bits. It would be good
> if compilers can be updated to avoid doing that so
> that programs start becoming naturally capable of
> running as AM64. I think gcc on z/Linux doesn't
> have this problem but I'm not certain.
>
> Regarding MVS 3.8j, the situation there is different,
> but ideally applications themselves are AMODE
> neutral and the same binary just accepts whatever
> AMODE it was invoked in instead of demanding a
> particular AMODE. That way the module can run
> optimally on any environment.
>
> 32-bit modules running as AM64 on z/Linux would
> basically be treating the environment as AM-infinity,
> which I think is ideal and this should be the model
> for all architectures. Rather than having a different
> mode like x64 has. I think z/Arch is fundamentally
> superior.
>
> BFN. Paul.
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
