RE: An introduction to MI by example II (part B)...

ah, all kinds of tidbits surfaces. Don (in DC), you must be pleased
to see what you have started.

> -----Original Message-----
> From: Blair Wyman [SMTP:wyman@VNET.IBM.COM]
> Sent: Wednesday, November 17, 1999 3:18 PM
> To:   MI400@midrange.com
> Subject:      Re: An introduction to MI by example II (part B)...
> 
> Excerpts from mi400: 16-Nov-99 RE: An introduction to MI b..
> Jon.Paris@halinfo.it (1773*) 
> 
> 
> > [MI] was never the native language for anything. Just something the old
> > OPM compilers generate as an intermediate language.  
> 
> Well, arguably MI *is* the pre-ILE "assembler" language on the AS/400,
> provided you accept the definition of assembler language as: "The
> lowest-level language useful to an applications programmer."  Of course,
> Original MI is very much a 'storage-to-storage' model, which hobbles
> advanced compiler optimizations.  W-code and the "new" MI are based on a
> stack model, and were designed as such primarily to address this
> shortcoming. 
> 
> > TIMI does stand for Technology Independent Machine Interface but that is
> > _not_ MI.  
> 
> Mmm, well...  These terms are probably close enough for government work.
>  *8-)  The TIMI is effectively *composed* of MI instructions (and their
> associated AS/400 "objects"), eh? 
> 
> > As Hans Boldt pointed out on Midrange-L the MI that you are programming
> > in here is further away from the system in some ways than programming in
> > C.  
> 
> Further away from any chance at modular, optimizable, bindable code for
> certain.  There have been no enhancements to the MI Transformer (other
> than minor bug fixes and support for new/modified instructions) since we
> wrote it in V3R6, and optimization of OPM (Original Program Model)
> programs has never resurfaced as a key requirement, (particularly after
> the nice boost from the RISC hardware). 
> 
> > I don't want to discourage people from using MI (well in some ways I do
> > <grin>) but don't use it thinking you're getting closer to the metal -
> > you're not. You can just do things that can't be done in RPG - unless of
> > course you use the MI functions of the C library. This has the added
> > advantage of being a bound call whereas the calls to MI programs are
> > dynamic. 
> 
> Absolutely agreed. 
> 
> > All new OS/400 function tends to be developed in C and C++ and not in
> > PL/MI (which itself is not MI) - IBM never (or hardly ever) wrote in MI.
> >  The current IBM compilers generate W-code (a sort of itty bitty
> > assembler) which is transformed into MI-prime I think, for translation
> > purposes.  But MI-prime is almost identical to W-code [...] 
> 
> W-code is more platform-neutral than MI-prime, but they are very close
> indeed -- close enough to where the transliteration is a relatively
> miniscule portion of overall program-creation processing. 
> 
> >  [W-code] in turn is very close to the Risc instruction set.  
> 
> I beg to differ, but W-code is so far above the RISC instruction set
> that we've got satellites in low-earth orbit closer to the RISC
> instruction set than W-code is...  W-code is an intermediate language
> only -- it's a whole lotta work (done by tens of thousands of lines of
> code) to turn that into RISC instructions. 
> 
> > That is why the C compiler and its built-ins can do a better job than MI
> > for the RISC boxes. 
> 
> +---
> | 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
+---