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.