From: cr88192@gmail.com   
      
   On 9/3/2025 1:26 PM, MitchAlsup wrote:   
   >   
   > Stephen Fuld  posted:   
   >   
   >> On 8/4/2025 9:56 PM, Thomas Koenig wrote:   
   >>> John Savard  schrieb:   
   >>>   
   >>>>> And... would you like to have a stack in your architecture?   
   >>>>   
   >>>> No.   
   >>>   
   >>> OK.  I think that is the final nail in the coffin, I will   
   >>> henceforth stop reading (and writing) about your architecture.   
   >>   
   >> While I agree that having at least push and pop instructions would be   
   >> beneficial,   
   >   
   > AMD's (and my) K9 translated push and pop into ST and LD followed   
   > by sub/add, and then peephole combined the several adds so that a   
   > sequence of instructions::   
   >   
   >       Push   RAX   
   >       Push   RCX   
   >       Push   RDX   
   >   
   > became a parallel list of Operations::   
   >   
   >       ST     RAX,[SP-8]   
   >       ST     RCX,[SP-16]   
   >       ST     RDX,[SP-24]   
   >       SUB    SP,SP,#24   
   >   
   > Taking a data-dependent series of instructions (minimum of 3 cycles)   
   > and allowing all of them begin execution in the same cycle. This is   
   > the fallacy of {push, pop, (Rx)++, --(Rx), and similar}. With GBOoO   
   > it is data-dependent latency that maters, not instruction count.   
   >   
      
   Though, this can be more an argument that having PUSH and POP is not   
   worthwhile. Maybe they help slightly with code density, but this is   
   about it.   
      
      
   They were something I ended up dropping earlier on, as it started to   
   become obvious at the time that having them was net negative.   
      
      
   It is possible that the assembler can fake them as pseudo-instructions,   
   but even this doesn't seem worthwhile to do so.   
      
   Well, nevermind if I did eventually go and add the logic in the   
   assembler to fake auto-increment addressing modes in RISC-V and similar.   
      
   So, say:   
      MOV.L @R10+, R13   
      MOV.L R13, @-R11   
   Or:   
      MOV.L (R10)+, R13   
      MOV.L R13, -(R11)   
      
   Will at least work (by cracking each into multiple instructions), but, ...   
      
      
   Still part of the ongoing tension of BGBCC targeting RV while using AT&T   
   style ASM syntax (and, for ASM fragments, it trying to infer the operand   
   ordering per fragment based on which nmemonics are used, which isn't   
   helped by my specs sort of mixing the use of mnemonics). If there isn't   
   enough to infer a choice based off of, it defaulting to the AT&T style   
   operand ordering.   
      
   Possible foot-guns all around here, but lack a better solution ATM.   
      
      
   >>              I hardly think that is the most "bizarre" and less than   
   >> useful aspect of John's architecture.   
   >   
   > Push and Pop only scratch the surface.   
   >   
   >>                                         After all, both of those   
   >> instructions can be accomplished by two "standard" instructions, a store   
   >> and an add (for push) and a load and subtract (for pop).  Interchange   
   >> the add and the subtract if you want the stack to grow in the other   
   >> direction.   
   >   
   > Which we quit doing 30-odd years ago.   
   >   
      
   I think the usual argument for grows-upwards stack being that   
   (presumably) it makes it less likely that a buffer overflow will hit the   
   saved-registers area.   
      
   But, pretty much everyone settled on grows-down stack.   
      
   On a RISC-style ISA, main difference it makes is that the OS and ABI   
   need to agree on which direction the stack goes. Though, in theory,   
   assuming it were an ABI choice, a flag in the binary or similar could be   
   used to signal stack direction. Granted, and DLLs/SOs would also need to   
   agree which way the stack goes.   
      
      
      
   Actually, could almost make a case for big-endian support, with binaries   
   setting a flag for big-endian, and some sort of CPU control flag to set   
   operation into big-endian mode.   
      
   But, say, having a mismatch between OS and application endianess is   
   asking for a mess.   
      
   Less awful being that pretty much everything defaults to little-endian,   
   but then having ISA support for endian-swapping, and some way to flag   
   data as big-endian.   
      
   FWIW, BGBCC has a __bigendian modifier, but this is pretty nonstandard   
   (and not well tested).   
   IIRC, ATM, would need to be applied to every member in a struct for a   
   fully BE struct, but could maybe make sense to allow it to apply to a   
   whole struct (in a similar way to "__packed" or "__attribute__((packed))").   
      
   Mostly only applies to struct members and pointers, and only for integer   
   types. Would also suck on RISC-V, which lacks any good way to do endian   
   swapping.   
      
      
   But, at least in the case of big-endian, it is commonly used in network   
   protocols and some file formats, so not completely useless.   
      
      
   >> Of course, you are free to stop contributing on this topic, but I, for   
   >> one, will miss your contributions.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)