From: Tom Marchant <[email protected]>
To: [email protected] <[email protected]>
Date: Saturday, 17 July 2010 1:48

>On Fri, 16 Jul 2010 12:07:01 +1000, robin wrote:
>
>>From: Tom Marchant <[email protected]>
>>Date: Friday, 16 July 2010 3:48
>>
>>
>>>On Thu, 15 Jul 2010 11:25:06 +1000, robin wrote:
>>>>
>>>>It's possible in the s/390 architecture to trap (inhibit) non-priveleged
>>>>instructions, using EX to execute every instruction [except, of course,
>>>>EX itself].  The overheads are not "an order of magnitude", but are
>>>>not trivial either.
>>>
>>>  Aside from
>>>execute type instructions (EX and EXRL), instructions such
>>>as BC, BRC, BASM
>>>and BASSM need special attention.  When they are executed
>>>and the branch is
>>>taken, the PSW address is updated.
>>>
>>>The instruction to be executed must be decoded enough to determine what
>>>registers will be used and ensure that the registers have the correct values
>>>that will be needed by the program.  This is necessary because the
>>>interpreter will require the use of at least two registers.  One to point to
>>>the instruction to be executed and another to point to an area of storage
>>>where it can store data that it needs.  If nothing else, it needs a place to
>>>store the value that the user's program expects in the register used to
>>>address the interpreted instruction.
>>
>>As I mentioned befiore, instructions are not "interpreted".
>>They are (were) executed by the processor "as is where is".
>
>Ok, "interpreted" was a poor choice of words.  The point I was
>trying to make is that there is considerable processing that
>must be done for every instruction that is to me executed.

The point I was making was there was NOT "considerable processing"
that must be done.
To be sure, register fields need to be examined.
Memory addresses need to be calculated.
Instruction decoding is done by table lookup.
Take for example, RR instructions:-
    The only instructions that require checking are those
    that branch (BC, BALR, BCTR, etc), and MR and DR.
    Most of the group of RR instructions require little done at all.
Take for example RX instructions:-
    Register addresses are checked.
    Memory address is checked.
    Choosing a register for addressing the subject instruction
    is done by table lookup.  For avoiding any of the three possible
    registers (first operand, index, base) table lookup is used.
    A particular EX instruction is chosen using one of the remaining "free" 
registers.

In all cases, these sequences are short compared to the corresponding
sequences required for full emulation.  Instruction groups like float,
decimal, character have considerably long sequences to emulate fully
the arithmetic or other operations required.

Full emulation suffers anything from 1 to 2 orders of magnitude time penalty.
Merely checking the validity of the operation typically requires
less than an order of magnitude of extra time.

>That's why I originally wrote that the target program would
>require an order of magnitude more CPU time than when it runs
>natively.  Dozens of instructions would have to be executed to
>prepare to execute each target instruction on a z/Architecture
>system, including all of the processing that I described in my
>previous append.
>
>If you want to protect your data areas from potential overlay
>by the target program, the overhead is considerably higher.
>If you don't, debugging errors in the target program will be
>very difficult.  For example, the value that the program has
>in a register may change unexpectedly if that register was one
>that you needed to use for the execute and the target program
>overlaid the storage that you used to save it.

That's what the checks are for.  Before executing
an instruction that references memory, the memory address is calculated.
If it's within the range of allocated memory, it's OK, but if it's
outside the that range (including the area occupied by the checker),
then the operation is terminated and helpful diagnostic is given.

>>Executing instructions via EX is a lot faster than simulation,
>
>I agree with that.  Also faster than causing an interrupt after
>every instruction to determine whether an instruction is to be
>suppressed.

Reply via email to