From: chris.m.thomasson.1@gmail.com   
      
   On 12/21/2025 10:12 AM, MitchAlsup wrote:   
   >   
   > John Savard  posted:   
   >   
   >> On Sat, 20 Dec 2025 20:15:51 +0000, MitchAlsup wrote:   
   >>   
   >>> For argument setup (calling side) one needs MOV   
   >>> {R1..R5},{Rm,Rn,Rj,Rk,Rl}   
   >>> For returning values (calling side)   needs MOV {Rm,Rn,Rj},{R1..R3}   
   >>>   
   >>> For loop iterations                   needs MOV {Rm,Rn,Rj},{Ra,Rb,Rc}   
   >>>   
   >>> I just can't see how to make these run reasonably fast within the   
   >>> constraints of the GBOoO Data Path.   
   >>   
   >> Since you actually worked at AMD, presumably you know why I'm mistaken   
   >> here...   
   >>   
   >> when I read this, I thought that there was a standard technique for doing   
   >> stuff like that in a GBOoO machine.   
   >   
   > There is::: it is called "load 'em up, pass 'em through". That is no   
   > different than any other calculation, except that no mangling of the   
   > bits is going on.   
   >   
   >>                                     Just break down all the fancy   
   >> instructions into RISC-style pseudo-ops. But apparently, since you would   
   >> know all about that, there must be a reason why it doesn't apply in these   
   >> cases.   
   >   
   > x86 has short/small MOV instructions, Not so with RISCs.   
      
   Does your EMS use a so called LOCK MOV? For some damn reason I remember   
   something like that. The LOCK "prefix" for say XADD, CMPXCHG8B, ect..   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)