XPost: alt.folklore.computers   
   From: cr88192@gmail.com   
      
   On 8/12/2025 11:08 AM, Scott Lurndal wrote:   
   > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:   
   >> cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>> MAP_32BIT is only used on x86-64 on Linux, and was originally   
   >>> a performance hack for allocating thread stacks: apparently, it   
   >>> was cheaper to do a thread switch with a stack below the 4GiB   
   >>> barrier (sign extension artifact maybe? Who knows...).  But it's   
   >>> no longer required for that.  But there's no indication that it   
   >>> was for supporting ILP32 on a 64-bit system.   
   >>   
   >> Reading up about x32, it requires quite a bit more than just   
   >> allocating everything in the low 2GB.   
   >   
   > The primary issue on x86 was with the API definitions.   Several   
   > legacy API declarations used signed integers (int) for   
   > address parameters.    This limited addresses to 2GB on   
   > a 32-bit system.   
   >   
   > https://en.wikipedia.org/wiki/Large-file_support   
   >   
   > The Large File Summit (I was one of the Unisys reps at the LFS)   
   > specified a standard way to support files larger than 2GB   
   > on 32-bit systems that used signed integers for file offsets   
   > and file size.   
   >   
   > Also, https://en.wikipedia.org/wiki/2_GB_limit   
   >   
      
   Also, IIRC, the major point of X32 was that it would narrow pointers and   
   similar back down to 32 bits, requiring special versions of any shared   
   libraries or similar.   
      
   But, it is unattractive to have both 32 and 64 bit versions of all the SO's.   
      
   Though, admittedly, not messed with it much personally...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)