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.
I agree that if your intention is to single step an entire program it can be done using EX. In order to do so in a general way, without any limitations on the target code, several things must be done. For each instruction to be executed, the instruction length must be determined so that the "virtual PSW" can be updated. The instruction to be executed must be examined to determine whether it makes sense to use it as a target of an execute instruction. 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. All of this requires many instructions to be processed for every instruction to be executed. And, IIRC, execute is an expensive instruction. That's why I said that the target program would run an order of magnitude slower. Of course, if you can be sure that there is be a register that will never used by the target code, the task is much simpler. Still, I think assembler code interpreted in this manner would perform an order of magnitude better than the usual method of modifying the storage after each instruction to be executed so that a program interruption or an SVC interruption occurs after every instruction. All of the same work must be done when using the interrupt method. In addition, every instruction results in an interruption and the cost of the FLIH must be factored in. Mr. Raulerson's assertion that the overhead for this kind of interpretive execution is "Not nearly as much as one might think" leaves me wondering what kind of overhead he thinks would be involved. Unfortunately, he has provided precious little detail in any of his posts in this thread. If someone were to measure the CPU requirements of a program running natively and then run the same program single stepped using ptrace() to execute one instruction at a time, I would not be surprised if the interpreted run used three orders of magnitude more CPU. I would be very surprised if it used less that two orders of magnitude more CPU. -- Tom Marchant
