From: user5857@newsgrouper.org.invalid   
      
   "Chris M. Thomasson" posted:   
      
   > 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..   
      
   The 2-operand+displacement LD/STs have a lock bit in the instruction--that   
   is it is not a Prefix. MOV in My 66000 is reg-reg or reg-constant.   
      
   Oh, and its ESM not EMS. Exotic Synchronization Method.   
      
   In order to get ATOMIC-ADD-to-Memory; I will need an Instruction-Modifier   
   {A.K.A. a prefix}.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|