On 08/05/2018 09:30 PM, Robin Vowels wrote:
----- Original Message ----- From: "Steve Thompson"
<ste...@copper.net>
To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Sent: Monday, August 06, 2018 4:21 AM
Subject: Re: EX
On 08/05/2018 08:13 AM, Robin Vowels wrote:
From: "Paul Gilmartin"
<00000014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, August 03, 2018 3:09 AM
<SNIPPAGE>
EX can "modify" everything, but it does not modify the subject
instruction.
Exception, EX.
Of course. In the context, EX can modify everything.
And anyway, why would you want to EX an EX?
<SNIP>
How easy is it to get a S0C1 (PIC 1) in a program? Now look at
the next several program interrupts and ask, how could I get such
an interrupt?
Well, there is the wild branch into code or data.
Then there is the storage overlay of data (also known as storage
corruption).
In all my years of programming, I have never seen an accidental
S0C3.
But I have seen plenty of PIC 1s, a few PIC 2s, PIC 5-7. And most
of those have been as a result of a bad branch. But you can get
them trying to "run" data as if they were instructions.
So, because of its usefulness, I code it in a macro typically
called SUICIDE. There is no question about what is going to
happen when this instruction is pulled into the processor. S0C3.
And because of comments I put with it, you will know why this is
going to happen.
BTW, there are a few instructions on IBM systems that are not
documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an
SIE either (this is part of the Interpretive Execution Facility).
Regards,
Steve Thompson
