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
+---