entropy@pawl.rpi.edu (Math Student from Hell) (07/26/89)
Under CMS, an SVC 202 instruction is followed by a four-byte
address which points at the place to which control returns in the event
of an error.
I was recently made aware of this fact. I was adding features
to our source-level debugger, and discovered that the 'disassemble'
feature was failing to disassemble instructions that followed SVC
202s. Why? Well, SVC is a two-byte instruction (opcode 10<64), and
after the disassembler disassembled the SVC, it looked two bytes
farther along for the next instruction and found garbage- the error
return address.
It wasn't hard to patch it up and make a special case: Just
check if the first word of the instruction is 0ACA, and if it is, the
instruction length is 6 bytes, not 2, but it occurred to me: When IBM
first introduced the CMS SVC 202 call, it must have broken _every_
_single_ _disassembler_ in the entire world.
Am I perceiving this wrong? Is there a simple solution? Can
someone show me that IBM did not perpetrate an utterly stupid,
gratuitously shoddy piece of design? Or did they? Why not, for
example, require register three or some such to be loaded with the
error return address?
Truly, IBM moves in Strange and Mysterious ways.
What a wonderful thing is the human brain; how I wish I possessed one.
Mark-Jason Dominus entropy@pawl.rpi.EDU entropy@rpitsmts (BITnet)entropy@PAWL3.PAWL.RPI.EDU (Math Student from Hell) (07/26/89)
Under CMS, an SVC 202 instruction is followed by a four-byte
address which points at the place to which control returns in the event
of an error.
I was recently made aware of this fact. I was adding features
to our source-level debugger, and discovered that the 'disassemble'
feature was failing to disassemble instructions that followed SVC
202s. Why? Well, SVC is a two-byte instruction (opcode 10<64), and
after the disassembler disassembled the SVC, it looked two bytes
farther along for the next instruction and found garbage- the error
return address.
It wasn't hard to patch it up and make a special case: Just
check if the first word of the instruction is 0ACA, and if it is, the
instruction length is 6 bytes, not 2, but it occurred to me: When IBM
first introduced the CMS SVC 202 call, it must have broken _every_
_single_ _disassembler_ in the entire world.
Am I perceiving this wrong? Is there a simple solution? Can
someone show me that IBM did not perpetrate an utterly stupid,
gratuitously shoddy piece of design? Or did they? Why not, for
example, require register three or some such to be loaded with the
error return address?
Truly, IBM moves in Strange and Mysterious ways.
What a wonderful thing is the human brain; how I wish I possessed one.
Mark-Jason Dominus entropy@pawl.rpi.EDU entropy@rpitsmts (BITnet)jbeard@quintus.UUCP (Jeff Beard) (07/27/89)
SVC 202 is NOT your only problem! EVERY SVC is exposed to this issue.
Recall that the 370 memory is monolithic ( ie unclassified as to data vs. code).
While some systems segregate instruction space from data space (typically
stack architecures like Tandem, DecVax...), the 370 does not.
This leads to the necessity of fetching and decoding the op-code at the current
instruction counter(IC) location, and if not sucessfull, program check
interrupt 01 occurs.
This allows such weird sequences as
op1,br->op2,data1,op2,br->op3,data2,op3,....
which occurs with many assembler macro expansions! The MF={E,L} ensures
that this does not occure, specifying the data for the code to be
at the MF=L invocation and only code at the MF=E invocation. BUT THIS IS
NOT THE DEFAULT! Unless specifically concerned with multi-threading or
reentrantcy, most if not all 370 coders will use the default and allow
macros to expand as in
open dcb,input
+ la r1,dcb
+ o r1,=xl8'80000000'
+ st r1,&sysindx
+ la r1,&sysindx
+ svc 13
+ b &sysindex+4
+&sysindx ds f
+
(don't flame if the above is not precisely the expansion ... it's been a
long time and the conecpt is the issue anyway).
The parameter to open is R1, pointing to a data area in the instruction steam
which MUST be bypassed with the Branch.
The case you site (SVC 202, and by the way 203) is unique to VM, in that
the data area follows immediately after the SVC, which requires the functional
code to return R14+6 for the normal case return or indirectly for errors
via `L R14,2(,R14), BR R14'. SVC 203 uses the following (?? halfword) data
as input to the function.jbeard@SUN.COM (Jeff Beard) (07/27/89)
SVC 202 is NOT your only problem! EVERY SVC is exposed to this issue.
Recall that the 370 memory is monolithic ( ie unclassified as to data vs. code).
While some systems segregate instruction space from data space (typically
stack architecures like Tandem, DecVax...), the 370 does not.
This leads to the necessity of fetching and decoding the op-code at the current
instruction counter(IC) location, and if not sucessfull, program check
interrupt 01 occurs.
This allows such weird sequences as
op1,br->op2,data1,op2,br->op3,data2,op3,....
which occurs with many assembler macro expansions! The MF={E,L} ensures
that this does not occure, specifying the data for the code to be
at the MF=L invocation and only code at the MF=E invocation. BUT THIS IS
NOT THE DEFAULT! Unless specifically concerned with multi-threading or
reentrantcy, most if not all 370 coders will use the default and allow
macros to expand as in
open dcb,input
+ la r1,dcb
+ o r1,=xl8'80000000'
+ st r1,&sysindx
+ la r1,&sysindx
+ svc 13
+ b &sysindex+4
+&sysindx ds f
+
(don't flame if the above is not precisely the expansion ... it's been a
long time and the conecpt is the issue anyway).
The parameter to open is R1, pointing to a data area in the instruction steam
which MUST be bypassed with the Branch.
The case you site (SVC 202, and by the way 203) is unique to VM, in that
the data area follows immediately after the SVC, which requires the functional
code to return R14+6 for the normal case return or indirectly for errors
via `L R14,2(,R14), BR R14'. SVC 203 uses the following (?? halfword) data
as input to the function.