RE: running PowerPC instructions in a user space -- MI400

Steve,

Very interesting....

Now the questions in my mind are whether this technique can be used flexibly
in an ILE/C program to:

1). Examine machine registers (if required) as part of the creation of a
"root-set" based on global (static) and automatic memory plus registers that
may contain pointers to heap objects, so that the root set can be the
starting point of a scan by a 3rd-party garbage collector,
 
2). Execute native machine code as an efficient replacement of a
higher-level interpreted byte code.

I noted in your example you were using STRSST to alter machine code
instructions in an existing program, correct?

(I've asked questions relating to the possibility of porting an open-source
gc to the 400 using ILE/C teraspace-enabled previously, on this and other
lists, and am still plugging away, so your post caught my eye...)

______________________________________
Regards,
Peter.


> -----Original Message-----
> From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx] On
> Behalf Of Steve Richter
> Sent: Sunday, 31 October 2004 5:57 AM
> To: chat. Mi400
> Subject: [MI400] running PowerPC instructions in a user space
> 
> I have been curious to know if PowerPC encoded instructions could be place
> in a user space and an RPG program be made to branch its execution to that
> code.   The answer, after a little bit of digging and experimenting ( and
> reading the archives! ), is that yes, that can be done.
> 
> The as400/ppc uses 8 byte pointers when it branches to code in a program.
> It also uses 8 byte pointers when it loads and stores data to 8 byte
> addresses of data in user spaces.  The theory is that the 8 byte address
> of
> a data that is stored to in a user space can also be branched to using
> that
> same 8 byte address.
> 
> Here is rpg code that copys 4 bytes ( a word ) pointed to by a pointer
> into
> an rpg program variable:
>  d pData        s            *
>  d Data         s           4a   based(pData)
>  d ch4          s           4a
>   /free
>        ch4      = Data ;
> 
> here is the corresponding PowerPC code:
>  LQ     20, 0x1e40(30), 6
>  SELRI  23, 21, 0, 41
>  LWZ    22, 0x0(23)
>  STW    22, 0x128( 30 )
> 
> LQ loads "pData", the pointer ( quad word ) stored at EA ( effective
> address ) reg30 + 0x1e40, into reg20 and reg21.   reg30 is the pointer to
> either the automatic storage of the RPG program or to its procedure call
> stack. Not sure which.  0x1e40 is the displacement from reg30 to the
> "pData"
> variable.
> 
> SELRI does something to reg21 with the result ending up in reg23. reg21 is
> important because it holds the actual pointer after LQ loaded both reg20
> and
> reg21.
> 
> LWZ ( load word, zero fill ) loads the word ( 4 bytes ) located at EA
> reg23
> + 0 into reg22.  These are the 4 characters pointed to by "pData" in the
> rpg
> program.
> 
> STW stores the word stored in reg22 into the word at EA reg30 + 0x128.
> That
> is the rpg variable "ch4".
> 
> That is how the PowerPC loads and stores data to an EA.  The following is
> PPC code that would branch execution to code at that same address:
>   mtspr    9, 23
>   bcctrl   20, 0
> 
> MTSPR ( move to special register ) moves reg23 to special register #9.
> That
> is the "count" register.
> http://www.nersc.gov/vendor_docs/ibm/asm/mtspr.htm#a29891041
> 
> BCCTRL ( branch conditional to count register ) branches to the address
> stored in the count register.  ( the 20 means do it unconditionally ).
> Because there is an "L" at the end of the opcode name ( BCCTRL instead of
> BCCTR ) it also stores the return address, the address of the next
> instruction, in the link register.
> 
> Here is the PowerPC code that branches to the instruction words pointed to
> by the above RPG variable "pData"
>  E29E1E46   LQ      20, 0x1e40(30), 6
>  7AB7049C   SELRI   23, 21, 0, 41
>  7EE903A6   mtspr   9, 23
>  4E800421   bcctrl  20, 0
> 
> The hex values in the left column is the hex external form of the 4 byte
> power pc instructions.  This site is pretty good at explaining what the
> encoding is all about:
> http://www.nersc.gov/vendor_docs/ibm/asm/mastertoc.htm
> 
> Here is code that when executed will store an immediate value to an EA and
> then branch unconditionally to the link register:
>  3A600320     addi  19, 0, 800
>  927E012C     stw   19, 30, 300
>  4E800020     bclr  20, 0
> 
> The first stmt effectively places the immediate value 800 into reg19.  The
> "stw" stmt stores reg19 to the word at EA reg30 + 300.  The last stmt,
> "bclr" branches unconditionally to the address in the link register.
> 
> If this code is stored in a user space, it can be executed from an RPG
> program by doing the following:
>   - make sure "pData" points to the data/code in the user space
>   - use the display/alter/dump facility of STRSST to punch the mtspr and
> bcctrl stmts shown above in place of the LWZ and STW in the rpg program:
> 
> original RPG emitted code:
>  LQ     20, 0x1e40(30), 6
>  SELRI  23, 21, 0, 41
>  LWZ    22, 0x0(23)
>  STW    22, 0x128( 30 )
> 
> becomes:
>  E29E1E46   LQ      20, 0x1e40(30), 6
>  7AB7049C   SELRI   23, 21, 0, 41
>  7EE903A6   mtspr   9, 23
>  4E800421   bcctrl  20, 0
> 
> The user space code to be executed:
>  3A600320     addi  19, 0, 800
>  927E012C     stw   19, 30, 300
>  4E800020     bclr  20, 0
> 
> is going to store the immed word value "800" to displacement 300 from the
> au
> tomatic storage of the RPG program.  That was the displacement to a 10i 0
> int variable in the rpg program I was working with.  It is there to prove
> the concept that the patched rpg code actually did branch to the user
> space
> and execute the above statements.  If you are going to do the same you
> should change that displacement to a value you see from using SST to dump
> your own RPG code.
> 
> What I did was add a breakpoint to the rpg program at the statement after
> the one that was patched, ran the code, hoped for the best and presto, the
> breakpoint broke and an EVAL of the RPG INT variable showed that it
> contained the value "800" !
> 
> -Steve Richter
> 
> 
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/mi400
> or email: MI400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
> 
>