RE: stack vs. storage-to-storage

[Colin Williams <Williamsc@xxxxxxxxxxxxxxxxx>]

I dont think its too far off topic. Its also great for guys like me to
know whats going on under the covers. You just dont find this kind of
stuff anywhere else. I'm learning something new every day almost!

>-----Original Message-----
>From: Blair Wyman [mailto:wyman@vnet.ibm.com]
>Sent: Thursday, November 25, 1999 1:03 AM
>To: MI400@midrange.com
>Subject: Re: stack vs. storage-to-storage
>
>
>Excerpts from mi400: 24-Nov-99 Re: stack vs. storage-to-st..
>leif@attglobal.net (1174*) 
>
>> I don't think that the MI architecture requires you to store 
>variables 
>> you don't use.  
>
>Well, if the variables are observable, I know it does.  This is a
>fundamental bugaboo of the MI's storage-to-storage 
>architecture.  We had
>to code the MI Transformer (the component that permits Original MI
>programs to be retranslated to RISC using the optimizing translator
>instead of the old translator) in such a fashion as to honor every MI
>store, bar-none. 
>
>> I would confess, that since I don't use x and y 
>> either, the whole program could be optimized away.  
>
>...but not if there is a single MI instruction with an observable store
>target.  Removing that instruction's side-effects violates the
>architecture.  IMO, part of this extreme standpoint is based on the
>integrity of the single-level store. 
>
>> Anyway, in the vast majority of RPG type applications 
>> there are hardly much gained by optimizing complicated 
>> expressions. 
>
>Not to be argumentative, but I do not agree, and would suggest that an
>ILE/RPG benchmark be crafted that is executed and timed at a few
>optimization levels -- say levels 10, 20 and 40.  Or, we could peel
>apart the disassemblies again -- that was illustrative.   
>
>Frankly, I think we'll see considerable speedups at higher optimization
>levels.  I believe this because -- although the high-level language
>semantic may be straightforward -- the low-level code-gen for RPG is
>undoubtedly quite complicated, and surely amenable to some global
>analysis and optimization. 
>
>For instance, optimized re-use of partial established addressability
>could be a significant factor.  (It's really just a special case of
>common subexpression elimination...) 
>
>When referencing fields of a based structure several times, it's
>possible for the compiler to store 'most' of the addressability
>calculation to the base of the structure in a global temp, and reuse
>that partial addressability in subsequent references.  Btw, this is
>valid in, and used for, OMI. 
>
>Thanks for the discussion!  This is good stuff, and hopefully not too
>far off-topic for the MI400 list... 
>
>-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
>+---
>
+---
| 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
+---