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,428 of 4,255    |
|    mutazilah@gmail.com to Joe Monk    |
|    Re: segmentation    |
|    10 Nov 22 18:45:41    |
      From: muta...@gmail.com              On Friday, November 11, 2022 at 9:33:08 AM UTC+8, Joe Monk wrote:       > > 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're referring to what is known as an effective address. Thats a different       address than an actual memory address. Effective addresses are translated by       the system to real addresses. Hence, an attribute of an effective address is       that it is a        generated address by the system.       > "whenever the machine generates and provides to the program a 24-bit or       31-bit address, the address is made available (placed in storage or loaded       into a general register) by being imbedded in a 32-bit field, with the       leftmost eight bits or one bit in        the field, respectively, set to zeros."               And some niche mainframe operating systems return the full       32 bits. If you have a 32-bit executable, as all of mine are, they       have access to a full 4 GB of memory under the right circumstances.              And also note that the OS normally just returns an address of the       start of a memory block. The application, using 32-bit instructions,       then creates 32-bit addresses of its own, that the OS has no explicit       knowledge of (but may suddenly find out when one is passed to it).              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