2 Sep
2014
2 Sep
'14
4:05 p.m.
As I understand it, what these instructions do is basically jump to a
word in memory, execute that word as an instruction, and them jump
right back. What were the usages of these in standard code? What was
the rationale behind them?
--
Thanks,
Kevin
2 Sep
2 Sep
4:19 p.m.
On Tue, Sep 02, 2014 at 05:05:20PM -0600, Kevin Keith wrote:
As I understand it, what these instructions do is
basically jump to a
word in memory, execute that word as an instruction, and them jump
right back. What were the usages of these in standard code? What was
the rationale behind them?
They avoid self-modifying code, in cases where there are hardware or
religious reasons to do so.
The EX instruction on the S/360 also lets you apply a value from a
register to an instruction where the value would be hard-coded, so
this makes it possible to use MVC etc. with a variable-length string.
John Wilson
D Bit
6:13 p.m.
They avoid self-modifying code, in cases where there
are hardware or
religious reasons to do so.
Forgive my slowness, but I've having a hard time seeing how this would
work. Could you point me to any examples?
On 2 September 2014 17:19, John Wilson <wilson at dbit.com> wrote:
On Tue, Sep 02, 2014 at 05:05:20PM -0600, Kevin Keith
wrote:
--
Thanks,
Kevin
As I understand it, what these instructions do is
basically jump to a
word in memory, execute that word as an instruction, and them jump
right back. What were the usages of these in standard code? What was
the rationale behind them?
They avoid self-modifying code, in cases where there are hardware or
religious reasons to do so.
The EX instruction on the S/360 also lets you apply a value from a
register to an instruction where the value would be hard-coded, so
this makes it possible to use MVC etc. with a variable-length string.
John Wilson
D Bit
7:10 p.m.
On Tue, Sep 02, 2014 at 07:13:03PM -0600, Kevin Keith wrote:
The example that pops in my head (even though it doesn't make sense on
a mainframe with no graphics hardware) is setting the "write" mode for
drawing on a graphics screen. So you do whatever math it takes to get
it down to a register full of bit(s) that you want to put into screen
memory using either an OR or XOR or MOV instruction (or local equivalent).
With self-modifying code you'd modify the code in-line (whenever the
write mode is changed), but that could cause unpleasantness if the CPU
has a prefetch queue or cache weirdness or read-only (or execute-only)
code space. And even if not, some people think it's morally wrong.
So instead you either maintain the modified opcode in a variable, or
else keep a pointer to one of three different constant opcodes, and
issue XCT/EX/etc. using that variable (or pointer) when the time comes.
So your main code path is never touched, but you can substitute the
correct opcode as needed.
Honestly, it doesn't come up much, but it's absolute magic when you
do need it. And as I said, on the IBM mainframes, it's the only way
to insert a variable count into a MVC/CLC/TR/TRT/etc. instruction
(I think MVCL etc. came in later models only? or there's some other
reason why you wouldn't always use it, that I've forgotten).
John Wilson
D Bit
They avoid
self-modifying code, in cases where there are hardware or
religious reasons to do so.
Forgive my slowness, but I've having a hard time seeing how this would
work. Could you point me to any examples? 
8:04 p.m.
On 09/02/2014 07:10 PM, John Wilson wrote:
So instead you either maintain the modified opcode in
a variable, or
else keep a pointer to one of three different constant opcodes, and
issue XCT/EX/etc. using that variable (or pointer) when the time comes.
So your main code path is never touched, but you can substitute the
correct opcode as needed.
In processors with very small instruction sets (no, I wouldn't call the
S/360 one), it can be very useful.
Consider for example the 8x300 (Signetics) bipolar microcontroller. 3
bits in the instruction for the opcode:
MOV (move) ADD, AND, XOR, XMIT (sort of a move immediate), NZT (jump if
not zero, XEC and JMP. What's useful about the XEC is that it could
take external data and use it to perform a sort of "computed GOTO".
Remember that the instruction store for this chip is in bipolar PROM--no
instruction modification in memory. Or you could use a computed target
address to perform a single instruction or jump.
Here's a hypothetical example. Suppose you're on an 8080 (not Z80)
MPU--and suppose you need to perform an IN or an OUT to a computed I/O
port. Well, IN and OUT take an immediate value as the target I/O address.
This means that you either (a) create a table of IN and OUT to every
possible I/O address, following each IN or OUT with a RET and then
simulating a computed CALL into the table. Clumsy, but if you can't
modify instructions (execute out of RAM), that's pretty much your only
choice. If the 8080 would have had an "execute" instruction that could
modify the second byte of any instruction, that would have meant that
you didn't have resort to clumsy schemes as already described.
--Chuck
3 Sep
3 Sep
11:41 a.m.
From: Kevin Keith
Sent: Tuesday, September 02, 2014 6:13 PM
Forgive my slowness, but I've having a hard time
seeing how this would
work. Could you point me to any examples?
A real life example, from the Tops-10 monitor (v7.04). In the page-fail
handler, we find the following code:
;HERE IF WE BELIEVE THAT THE ADDRESS IN THE PAGE FAIL WORD IS REALLY A
; VIRTUAL ADDRESS. MUST BE TRUE OR THE PARITY ERROR WAS SPURIOUS
PRTRP4: MOVE T4,[PXCT PX.MEM,[MAP P1,(P1)]] ;SET UP PXCT OF MAP INSTRUCTION
SKIPL .CPPFW## ;IS THIS A USER CONTEXT REFERENCE?
TLZ T4,(PX.MEM,) ;NO--THEN PXCT BECOMES REGULAR XCT
MOVE P1,.CPPFW## ;NOT PHYSICAL REFERENCE, GET VIRTUAL ADDRESS
XCT T4 ;DO A MAP TO TURN PF WORD INTO PHYS ADDR IN P1
A note on Macro-10 syntax: Literals are in square brackets [], and can be
nested. <symbolname>## indicates a global symbol.
PXCT is a privileged variant of the XCT instruction which is used in the
monitor (read "kernel") to perform instructions in the "previous
context"
(which is to say, the context in which a system call or other monitor event
occurred) to provide data to the monitor context which handles the event.
This particular piece of code sets up a MAP instruction, which will convert
a virtual address to a real physical address. It assumes that the page
fault took place in a user context (since if the system is running well
that's the usual state). If that is not the case, it zeroes the accumulator
field of the PXCT instruction in accumulator T4, making it an ordinary XCT.
It now moves the page-fail word into accumulator P1, for use by the MAP
instruction pointed to by the (P)XCT instruction in T4, and does an XCT of
the (P)XCT, which in turns executes the MAP instruction, which puts the
physical address of the word pointed to by the page-fail word into P1, for
the use of the monitor's page fault handler.
The XCT instruction, including its previous-context variant, allows all of
those variations on what we are looking for to be handled in 5 instructions,
instead of special case code to handle "is this in the monitor rather than
in user context?" Makes the code simpler to maintain, since we don't have
to make parallel changes in different routines.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
4:09 p.m.
Thanks for all of the examples everyone! That helped a lot.
On 3 September 2014 12:41, Rich Alderson <RichA at livingcomputermuseum.org> wrote:
From: Kevin Keith
Sent: Tuesday, September 02, 2014 6:13 PM
--
Thanks,
Kevin
Forgive my slowness, but I've having a hard
time seeing how this would
work. Could you point me to any examples?
A real life example, from the Tops-10 monitor (v7.04). In the page-fail
handler, we find the following code:
;HERE IF WE BELIEVE THAT THE ADDRESS IN THE PAGE FAIL WORD IS REALLY A
; VIRTUAL ADDRESS. MUST BE TRUE OR THE PARITY ERROR WAS SPURIOUS
PRTRP4: MOVE T4,[PXCT PX.MEM,[MAP P1,(P1)]] ;SET UP PXCT OF MAP INSTRUCTION
SKIPL .CPPFW## ;IS THIS A USER CONTEXT REFERENCE?
TLZ T4,(PX.MEM,) ;NO--THEN PXCT BECOMES REGULAR XCT
MOVE P1,.CPPFW## ;NOT PHYSICAL REFERENCE, GET VIRTUAL ADDRESS
XCT T4 ;DO A MAP TO TURN PF WORD INTO PHYS ADDR IN P1
A note on Macro-10 syntax: Literals are in square brackets [], and can be
nested. <symbolname>## indicates a global symbol.
PXCT is a privileged variant of the XCT instruction which is used in the
monitor (read "kernel") to perform instructions in the "previous
context"
(which is to say, the context in which a system call or other monitor event
occurred) to provide data to the monitor context which handles the event.
This particular piece of code sets up a MAP instruction, which will convert
a virtual address to a real physical address. It assumes that the page
fault took place in a user context (since if the system is running well
that's the usual state). If that is not the case, it zeroes the accumulator
field of the PXCT instruction in accumulator T4, making it an ordinary XCT.
It now moves the page-fail word into accumulator P1, for use by the MAP
instruction pointed to by the (P)XCT instruction in T4, and does an XCT of
the (P)XCT, which in turns executes the MAP instruction, which puts the
physical address of the word pointed to by the page-fail word into P1, for
the use of the monitor's page fault handler.
The XCT instruction, including its previous-context variant, allows all of
those variations on what we are looking for to be handled in 5 instructions,
instead of special case code to handle "is this in the monitor rather than
in user context?" Makes the code simpler to maintain, since we don't have
to make parallel changes in different routines.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
2 Sep
2 Sep
5:32 p.m.
On Tue, Sep 2, 2014 at 4:05 PM, Kevin Keith <krfkeith at gmail.com> wrote:
As I understand it, what these instructions do is
basically jump to a
word in memory, execute that word as an instruction, and them jump
right back. What were the usages of these in standard code? What was
the rationale behind them?
I am working with entirely different hardware and software, but I have
encountered functionally equivalent execute instructions used to adapt the
code to hardware variations; e.g. different models of the I/O controller
had different ways of getting the value of a status register. There is
some initialization code like:
int get_status_instruction;
initialize ()
{
...
if (dev_type == model_a)
get_status_instruction = 0040355000; // instruction to read
status from model A
else
get_status_instruction = 004488730; // instruction to read
status from model B
...
}
#define get_status xeq(get_status_instruction)
code...
status = get_status;
So, the idea is that the overhead of the execute instruction is less then
the over head of checking the dev_type every time you need the status, and
is easily changed to handle additional variations since only the initialize
routine needs to be modified.
-- Charles
3545
days inactive
3546
days old
7 comments
5 participants
participants (5)
-
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
krfkeith＠gmail.com -
RichA＠LivingComputerMuseum.org -
wilson＠dbit.com