Re: stack vs. storage-to-storage

Excerpts from mi400: 24-Nov-99 RE: stack vs. storage-to-st.. Leif
Svalgaard@pentasafe (3647) 

> > The key advantage to a stack-based virtual machine is in code 
> > optimization.  Consider this simple sequence of HLL code:  
>       [Leif Svalgaard]     
>       Although Blair does have a valid point, it should be moderated a bit. 
>       Below I show the actual generated code for a C-program  
        [snippage] 
>       Part of the lack of dramatic difference is that the two 
>       compilers do different optimizations and not all that 
>       great ones, either. 

Well, you didn't let the optimizer at the code generated by the C
compiler -- what you posted is the opt level 10 disassembly.  (The
optimizing translator performs *no* optimizations at level 10,
preferring instead to run as fast as possible itself.)  Let's look at a
couple more disassemblies, at higher optimization levels.   

First, the same chunk of MAIN posted previously, but compiled at opt
level 20.  (Opt level 20  requires stores to go "all the way home" and
loads to come "all the way from home" for debuggability purposes.) 

          LWA 12,0XFFE4(31)   
          LWA 9,0XFFE8(31) 
          MULLD 10,12,12 
          MULLD 8,9,9 
          EXTSW 10,10 
          EXTSW 8,8 
          ADD 7,8,10 
          EXTSW 7,7 
          STW 7,0XFFEC(31)  <-- to storage 
          ADD 6,10,7 
          EXTSW 6,6 
          STW 6,0XFFE0(31)  <-- to storage 

Look a little better?   

Next, I'd like to post the opt 40 code.  Um...  I'd *like* to, but the
chunk of MAIN that correspsonds to the other disassemblies is *gone.* 
The only remaining instruction in MAIN is the BCLR 20,0 which says
'return'. 

Compare this to the MI version, as optimized as it can get....  Any and
all optimizations performed by QPRCRTPG are constrained to honor the
storage-to-storage requirements of the OMI architecture, for each MI
instruction. 

Now, to be fair, the MI program should be compiled specifying full
optimization as well.  I'd be interested to see the disassembly.   

The key point I tried to make, though, is simply that a stack-based
machine is better handled by an optimizing translator -- the same
translator that is shackled by the Original MI storage-to-storage
architectural requirements when it handles OPM programs. 

        [hand-optimized MI version snipped] 

>       which is exactly the same as we got for the C-program, 
>       so it is NOT the underlying difference (stack based versus 
>       storage based) that makes the difference, but solely the 
>       optimizations made by the compilers (in both modes). 

Actually, while you were certainly able to hand-optimize the MI version
quite a ways, you violated the MI architecture by not storing the
results in the temporary variables.  <tsk, tsk> <G> 

Fun stuff! 

-blair 
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---