home bbs files messages ]

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