RE: MI as the MI language of the as400. was: porting OS/400 compiler functionality to Windows...

-----Original Message-----
From: mi400-admin@midrange.com [mailto:mi400-admin@midrange.com]On
Behalf Of Simon Coulter

>>What is his opinion on how Rochester has used OMI on the AS400 ?

>That implies you think they've screwed up and that Glenn would agree with
>you.  Why?


Hi Simon,

My two points of contention on this subject are the decision to make NMI and
wcode effectively inaccessible and the return of the link edit that ILE
brought to our platform. And then there is the added complexity of the ILE
model which I could accept, but I would like the lead designers at IBM to
explain the need for.

MI needed intra pgm call stack support to enable function call based
languages like C to be possible on the as400. If ILE was an ambitious effort
to merge the intra pgm (functions) call stack and the job (programs) call
stack, then I applaud the objective but laud the overly complex, closed to
developers results. Was the scoping aspect of the ILE call stack ( file
override and file opens auto close when the call leaves scope ) needed by
the C compiler ? I doubt it. If not, then the assertion that ILE was needed
to bring C to our platform has one less leg to stand on.

Extending intra pgm call support to OMI is very doable. Add push and pop
stack instructions, provide STACK as an addressability mode ( AUTO STAT BAS
PARM ... STACK ), formalize the structure of the stack entries, integrate
exception handling. All doable in my view.

The merging of the inter and intra pgm call stack would be an excellent
addition to our platform.  You dont have to look any further than the
complexity, cost and years needed to deliver COM on the windows platform to
see the benefits that a call stack that is integrated into the OS would
bring. A call stack model that integrates and supports function calls,
program calls and marshalled calls ( an RPC is a subset of marshalled call
support ) would ensure our platforms viability for many years to come.

The external module call that I proposed on this list last year is, in my
view, the basis of a better way to do ILE.  The SLS provides the ability to
set a byte level pointer ( space, instruction ) to any object on the system.
A jump to an instruction residing in an external module object can execute
as fast as an indirect jump within a program.  So C functions can reside in
external, standalone system objects. Using instruction pointers just like
space pointers, jumps ( calls ) from one module to another will execute
without any  impact on performance compared to an intra pgm call/jump. THIS
IS AN ARCHITECTURAL ADVANTAGE THAT SHOULD BE EXPLOITED BY ISERIES DESIGNERS
AND MARKETERS.

Here is the basic MI code that would execute a module call:
  DCL INSPTR ipCode ;
  DCL SYSPTR spModule ;
  DCL INSPTR ipMostRecentCaller BASPCO POS(160001) ;
  SETSYSP spModule, "object name", *MODULE  /* set system pointer to module
object */
  SetIpFp ipCode, spModule ;   /* set IP to 1st instruction in the module.
*/

  SETIP ipMostRecentCaller, CURRENT_INSTRUCTION + 2 ; /* set the return addr
*/
  B ipCode ;  /* branch to instruction pointer */

/* another way to call the extenal module */
  CALLMOD ipCode, pSomeSortOfModuleCallStackEntry ;

This post of mine provides some more details.
http://archive.midrange.com/mi400/200107/msg00074.html

There are system security implications to the unvarnished MI level module
call. I've been told that run time assembly of executable code is a security
audit no-no. I dont agree or disagree with this assertion, but restricting
the setting of an instruction pointer to only pre compiled code should
obviate this concern.

But the details are not as important as the concept. Exploiting the SLS to
jump to external code is the key. Add a formalized call stack that is
documented and exposed, with exception handling and scoping boundary
elements, is flexible enough to support function, pgm and marshalled calls,
and is integrated into the OS so the running pgm is always under the control
of the OS, .... and you'll have a real good system.

best regards,

Steve Richter
AutoCoder, LLC
973-625-7241