From: user5857@newsgrouper.org.invalid   
      
   scott@slp53.sl.home (Scott Lurndal) posted:   
      
   > "Brian G. Lucas"  writes:   
   > >On 11/26/25 5:16 PM, Scott Lurndal wrote:   
   > >> MitchAlsup  writes:   
   > >>>   
   > >>> Robert Finch  posted:   
   > >>>   
   > >>   
   > >>>> The Qulps PUSH and POP instructions have room for six register fields.   
   > >>>> Should one of the fields be used to identify the stack pointer register   
   > >>>> allowing five registers to be pushed or popped? Or should the stack   
   > >>>> pointer register be assumed so that six registers may be pushed or   
   popped?   
   > >>>   
   > >>> My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,   
   > >>> instead of giving it a number of registers, there is a start register   
   > >>> and a stop register, so 1-to-32 regsiters can be saved/restored. The   
   > >>> immediate contains how much stack space to allocate/deallocate.   
   > >>   
   > >> That seems both confining for the compiler designers and less   
   > >> useful than the VAX-11 register mask stored in the instruction stream   
   > >> at the function entry point(s).   
   > >>   
   > >When the compiler can control the order in which registers are chosen   
   > >to allocate, the ENTER and EXIT stuff works very well.   
   >   
   > They are often, however, constrained by the processor specific ABI   
   > which defines the usage model for registers when multiple languages   
   > are linked to provide code for an application.   
   >   
   > When every enter insn that calls the function has that mask,   
      
   a) wrong order: It is subroutine entry point that has the mask   
      not the calling point. Thus, the mask is universal to the   
      subroutine just entered. And, thus, the corresponding EXIT   
      will use the same "bit pattern".   
      
   >            there is the possibility for strange and difficult to locate   
   > errors when a program links with a library function that was built   
   > earlier or with a different version of a (or even different language)   
   > compiler and thus the mask is not necessarily correct for the latest   
   > version of the called function.   
      
   b) this was the x86-32 problem in using one of its "CALL" instructions   
      the stack was manipulated on the calling side instead of the called   
      side. Originally this worked fine for PASCAL and nadda-so-gooda for   
      C-like languages.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)