Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.development    |    Operating system development chatter    |    4,255 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,426 of 4,255    |
|    mutazilah@gmail.com to Joe Monk    |
|    Re: segmentation    |
|    10 Nov 22 16:29:32    |
      From: muta...@gmail.com              On Friday, November 11, 2022 at 8:09:00 AM UTC+8, Joe Monk wrote:       > > No, that's not correct. If a program only ever populates the low       > > 32 bits of registers, to use as addresses, then it is a 32-bit       > > program.       > >       > Not on z/Arch.              Yes, even on z/Arch. The only way a 32-bit program can turn into       a 64-bit program (ie, by definition, actually populating 64 bits with       meaningful values, not 0), is via recompilation.              You can't just run an unchanged executable on a 1024-bit system       and access 2**1024 bytes of memory.              > ALL z/Arch memory access is by absolute address, which is always 64-bit.              Which is why, if you run a 32-bit program on z/Arch, you need to       ensure the high 32 bits are populated with something non-random,       typically 0, prior to execution, because the 32-bit program has no       knowledge that those bits exist.              The other option is to deliberately request address masking, and       then you are free to store garbage in the top x bits, depending on       what masking you have requested. For a 32-bit program, running       on a 64-bit system, you need to mask a minimum of 32 bits, but       you can mask any number up to 63.              Off-the-shelf hardware has the ability to mask the top 33 bits       or top 40 bits, but you can obtain custom emulated hardware       capable of masking just 32 bits.              BFN. Paul.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca