From: muta...@gmail.com   
      
   On Wednesday, November 9, 2022 at 9:06:10 PM UTC+8, Joe Monk wrote:   
   > > If you want to call my executables that only use S/370 instructions,   
   > > only use the lower 32 bits of registers, only store integers and pointers   
   > > in 4 bytes, "64 bit" because they happen to be running in AM64, so   
   > > be it.   
   > On z/Arch, there are no S/370 instructions, only z/Arch instructions. The   
   instructions may use the same mnemonic and opcode, but the similarity ends   
   there.   
   >   
   > For instance, LA (Load Address) on z/Arch is not a S/370 instruction because   
   it is AMODE sensitive, unlike the S/370 LA instruction which has no concept of   
   AMODE. LA in AM64 loads 64 bits, regardless of whether you use them all or not.   
   >   
   > "In the 64-bit addressing mode, the address is placed in bit positions   
   0-63." - of a 64bit register. S/370 doesnt have 64-bit registers, it has   
   32-bit registers, and the instruction only loads 24 bits.   
   >   
   > "LOAD ADDRESS may be used to increment the rightmost bits of a general   
   register, other than register 0, by the contents of the D2 field of the   
   instruction. ... The instruction increments 64 bits in the 64-bit addressing   
   mode."   
   >   
   > So you can continue to deceive yourself into thinking that your application   
   is "32 bit", but in fact in AM64, you are executing 64 bit instructions on   
   64-bit registers - and the instruction address in the PSW is always 64 bit.   
      
   And you can deceive yourself that an executable magically   
   transforms from being a 64-bit executable to a 24-bit   
   executable just because you ran it on a S/370 (and you   
   can quote shit from the S/370 manual too if you want).   
      
   What's that animal that can change its colors? A chimera?   
      
   So you keep your belief that there are magical executables   
   that are technically anything from 1-bit to infinity bits, and   
   I'll stick to calling them 32-bit.   
      
   Whenever you see me use the number 32, just know that I mean   
   1 to infinity, randomly, by your (what's the word you used?),   
   gibberish logic.   
      
   > Even more so - when you floated the idea of 32-bit GETMAINs on IBM-MAIN, you   
   were specifically told "NO" by IBM itself...   
   >   
   > "GETMAIN is not going to ever manage 32-bit storage"   
      
   That's IBM being assholes, not what is technically possible.   
      
   And I don't need IBM to stop being assholes anyway.   
      
   You give me 12 GB of virtual storage, and I'll give a 32,   
   sorry, 1-infinity-randomly, bit program access to a clean   
   4 GB address space to call its own.   
      
   The way 32-bit programs were meant to run.   
      
   It's a pity my 32-bit executable can't address more than 4 GB   
   of memory, despite your insistence that it can access infinite   
   memory, god only know why.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)