On 2018-08-06, at 23:35:58, Bernd Oppolzer wrote:
> BTW: the German mainframe Telefunken TR440 had some similar instructions
> which were not protected the same way like EX. There were at least three
> ways to stop the CPU from a non-privileged program ... I recall them being
> called
After some research:
Dr. Heinz Schecher was a computer scientist at the TU Munich (technical
university);
look here (for example):
BTW: the German mainframe Telefunken TR440 had some similar instructions
which were not protected the same way like EX. There were at least three
ways to stop the CPU from a non-privileged program ... I recall them being
called "Schecher-Stop type n" (n = 1,2,3), because Schecher was the name
of
There is a difference;
when coding B *, the CPU has to fetch the instruction
again and again, so it is easy to interrupt the endless loop by another
process or task. But a (theoretical) EX R0,* loop cannot be interrupted,
because
the loop is inside the execution logic of ONE instruction.
Kind
There's a fundamental difference between B * and EX reg,*; the EX gives you a
single instruction that never terminates, while the branch gives you multiple
instructions each of which completes quickly. So to allow the execute you'd
have to make it re startable.
BTW, IBM had earlier machines in
On 8/6/2018 18:12, Dan Greiner wrote:
I was once asked why the execute exception existed. That is, why not just let
the hardware — or, in this odd case, the firmware — cascade down a chain of
multiple EX instructions, ORing the bits of the R1 field with the subsequent
target instruction,
The work you do to make a subroutine refreshable pretty much takes care of
recursion. There's only one R14 slot in a save area.
Similar considerations apply if you're using XPLINK.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
On 2018-08-06, at 17:07:35, Charles Mills wrote:
> I get the impression that the hardware handles EX like a subroutine call. If
> a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM.
>
> Subroutine returns are a heckuva lot easier to implement if you only allow
> subroutine calls to
I get the impression that the hardware handles EX like a subroutine call. If
a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM.
Subroutine returns are a heckuva lot easier to implement if you only allow
subroutine calls to be one deep. You have only one return address pointer to
On 2018-08-06, at 16:56:55, Steve Smith wrote:
>>
>> The debugger branched to the address in register 0.
>>
>> Fortunately, I knew who to contact to fix the bug. No-one had
>> ever tried that before.
>>
> Really? How did it manage to do that?
>
I'd guess it simulated the instruction,
On 2018-08-06, at 16:55:00, Seymour J Metz wrote:
> Why try totally irrelevant code? ...
>
Somehow, I'm reminded:
https://xkcd.com/325/
... not what you asked for!
-- gil
On 8/6/2018 16:25, glen herrmannsfeldt wrote:
Bernd wrote:
We also had a self-written batch debugger, which relied completely on
S0C1 and SPIE to do its instrumentation and implement the breakpoints;
at least in the first version.
Reminds me of a debugger I used with Orvyl/370 in S/370 days.
Why try totally irrelevant code? I wrote "Further, you can't use the same label
on two different instructions"; if you want to give me a code example, give me
one where you use the same label in two different instructions.
Note that I wrote label, not symbol; that means a string in column 1,
On 2018-08-06, at 16:47:33, Robin Vowels wrote:
>
>> True, but irrelevant. Adding a B or F to a label reference in any other
>> assembler
>> doesn't have the same semantics. E.g., this doesn't work:
>
>>TMoperand,mask
>>BOFOOF
>>XRR0,R0
>> FOO AR
On 2018-08-06, at 16:12:37, Dan Greiner wrote:
> I was once asked why the execute exception existed. That is, why not just let
> the hardware — or, in this odd case, the firmware — cascade down a chain of
> multiple EX instructions, ORing the bits of the R1 field with the subsequent
> target
From: "Seymour J Metz"
Sent: Tuesday, August 07, 2018 5:57 AM
True, but irrelevant. Adding a B or F to a label reference in any other
assembler
doesn't have the same semantics. E.g., this doesn't work:
TMoperand,mask
BOFOOF
XRR0,R0
FOO ARR2,R3
I was once asked why the execute exception existed. That is, why not just let
the hardware — or, in this odd case, the firmware — cascade down a chain of
multiple EX instructions, ORing the bits of the R1 field with the subsequent
target instruction, whatever instruction that might be. Aside
Unless there’s a concurrent PER and Monitor event indicated*;
then it wouldn’t be a typo, but that’s just what it was. Thank you for reading
my post and commenting on my mistake. Maybe I should pay more attention to my
posts
Bernd wrote:
> We also had a self-written batch debugger, which relied completely on
> S0C1 and SPIE to do its instrumentation and implement the breakpoints;
> at least in the first version.
Reminds me of a debugger I used with Orvyl/370 in S/370 days.
I believe it used SVC 255 for
In some very old code (1975-1985) where storage was severely constrained, the
inline halfword was a value from 0-255 for error#s 0-255.
richard
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday,
Am 06.08.2018 um 22:02 schrieb Seymour J Metz:
It might be that some SPIE routines handle the interrupt,
maybe print a message, and then allow it through to the OS.
I vaguely recall someone using DC H'0' followed by a message in a special
format to get a tailored error message via a SPIE exit.
>It might be that some SPIE routines handle the interrupt,
>maybe print a message, and then allow it through to the OS.
I vaguely recall someone using DC H'0' followed by a message in a special
format to get a tailored error message via a SPIE exit.
>I do still remember S0C0 from the 360/91
True, but irrelevant. Adding a B or F to a label reference in any other
assembler doesn't have the same semantics. E.g., this doesn't work:
TMoperand,mask
BOFOOF
XRR0,R0
FOO ARR2,R3
BCT R1,FOOB
Further, you can't use the same label on
We always used
DC H'0'
at my old customer's site; anything wrong with that?
Of course only in cases where we did not expect to get there;
otherwise we would output some messages and use a real
ABEND macro. Because it needs some effort to get the reason
of the S0C1 from the abending module and
Shmuel (Seymour J.) Metz wrote:
> No; it is guarantied to generate a program 001 interrupt.
> You only get an ABEND S0C1 if there is no SPIE/ESPIE exit.
I suspect that some use S0C1 as shorthand, and as you note
incorrect, description for program interrupt 1.j
It might be that some SPIE
No; it is guarantied to generate a program 001 interrupt. You only get an ABEND
S0C1 if there is no SPIE/ESPIE exit. I've written code that distinguished[1]
between a S/360 and a S/370 with a SPIE[2] for codes 1 and 2; the exit assumed
that it was a S/370 if the code was 2.
[1] Well, it was
Nonsense; a good comment makes it perfectly clear and not at all elitist or
opaque. Doing it without a comment, OTOH, is bad form.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Paul Gilmartin
No, you get a program interrupt 003; you only get an ABEND S0C3 if the program
interrupt is not handled by a SPIE/ESPIE exit. There's actually software that
uses EX 0,* as a control structure. I don't recall whether it was a debugger, a
profiler or "E none of the above".
--
Shmuel (Seymour
Hmm, didn't think of using CRTE etc, since I was fixated on CLFITxx
instructions. The immediate value is a halfword, so you can code a lot more
variations of the CLFIT instruction to uniquely identify which specific
instance produced the S0C7.
Robert Ngan
HCL
P.S. I always seem to code the
Robert Ngan writes:
> Not sure why no one has mentioned the COMPARE AND TRAP type instructions, in
> most(?) cases they'll do the test and force the abend when required.
If you have to write product code that still works for CMS users
in ESA mode, then COMPARE AND TRAP is not an option. It needs
Not sure why no one has mentioned the COMPARE AND TRAP type instructions, in
most(?) cases they'll do the test and force the abend when required.
My only gripe is there's no extended mnemonic for an unconditional TRAP when
there's no appropriate "compare" (e.g. I need to do a TM).
I had to code
On Mon, Aug 6, 2018 at 10:22 AM Jonathan Scott
wrote:
> John McKown writes:
> > Just in case anyone else is interested, given that Gil has disclaimed any
> > interest at all. J *+2 generates the instruction: 7A44 0001 .
>
> On IBM Z the instruction is actually A7F4 0001.
>
Thanks. I thought
On 2018-08-06 10:35, Ed Jaffe wrote:
We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
with an 0C1.
'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a
code base register and so is more generally usable in modern code.
--
Regards, Gord Tomlin
Action
On 8/6/2018 8:23 AM, Keven wrote:
Ditto for
EX R0,*
except that you get a 0C3 program interrupt instead, which is usually a sign of
code scuttling itself and can be treated as such in recovery routines.
Yes, I used the 'EX R0,*' technique back in the 80s and early 90s
Ouch, obviously not as Jonathan points out... :facepalm:
On Mon, 6 Aug 2018 at 17:23, Rob van der Heij wrote:
> On Mon, 6 Aug 2018 at 16:35, Ed Jaffe wrote:
>
>> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
>> with an 0C1.
>>
>> I'm very fond of having an extra code
On Mon, 6 Aug 2018 at 16:35, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1.
>
> I'm very fond of having an extra code for the type of assert, so I can
already blush before I see the listing ;-)
I suppose I could have the macro generate
Ditto for
EX R0,*
except that you get a 0C3 program interrupt instead, which is usually a sign of
code scuttling itself and can be treated as such in recovery routines.
John McKown writes:
> Just in case anyone else is interested, given that Gil has disclaimed any
> interest at all. J *+2 generates the instruction: 7A44 0001 .
On IBM Z the instruction is actually A7F4 0001.
7A44 0001 would be AE 4,1(4,0)
Jonathan Scott, HLASM
IBM Hursley, UK
Ed Jaffe writes:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1.
I like that; OK by assembler and no branch in the normal case
but guaranteed to program check on 00. If my old code that uses
TRAP ever needs to be updated to a relative addressing version,
I
The ABEND macro unfortunately disturbs a couple of registers. Various
S0C1/2/3 strategies are better from a "debugging the original problem" point
of view, if not from a code obscurity point of view.
J *+2 is easy to understand. It jumps to the second halfword of the
instruction itself (*+0 would
On Mon, Aug 6, 2018 at 9:51 AM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
>
> > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1.
> >
> I am *not* going to read the PoOps to learn why
We do the same.
The relative halfword count is at +2 - so the instruction is 00
It's handy to see where exactly you died. And why.
On 8/6/18, 10:51 AM, "IBM Mainframe Assembler List on behalf of Paul
Gilmartin" wrote:
On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
> We use 'Jxx *+2'
On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with
> an 0C1.
>
I am *not* going to read the PoOps to learn why that "is guaranteed
to fail". I'm merely dismissing it as elitist opaque code. Comments
help only slightly.
>
On Sun, Aug 5, 2018 at 4:26 AM Glen wrote:
> I believe that some DEC assemblers allow local labels of
> the form d$ where d is a digit from 0 to 9.
>
> Local labels need to be unique between any two normal labels.
> References to them would, then, only work between those same labels.
>
> -- glen
On 08/05/2018 09:30 PM, Robin Vowels wrote:
- Original Message - From: "Steve Thompson"
To:
Sent: Monday, August 06, 2018 4:21 AM
Subject: Re: EX
On 08/05/2018 08:13 AM, Robin Vowels wrote:
From: "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday,
Robin Vowels wrote:
> L 0,1
> will do it.
That instruction will normally produce an alignment warning at
assembly time but won't stop anything at run time unless you're
running on a System/360 without the BOOF (byte oriented operand
feature) or on Linux on Z, where page 0 is not addressable by
J *+1 isn't even possible, as the hardware offset for relative
addressing is in halfwords.
For many years I have been using a conditional TRAP macro which
is equivalent to
BC cond,*+1
but which is coded using LA with an ORG back to change the
opcode, to avoid getting an error message. This
From: "Martin Ward"
Sent: Monday, August 06, 2018 6:40 PM
On 06/08/2018 02:30, Robin Vowels wrote:
And anyway, why would you want to EX an EX?
To cause an ABEND after an error, of course!
I have seen "EX 0,*" in production code to do this
(along with "J *+1")
L 0,1
will do it.
---
This
On 06/08/2018 02:30, Robin Vowels wrote:
And anyway, why would you want to EX an EX?
To cause an ABEND after an error, of course!
I have seen "EX 0,*" in production code to do this
(along with "J *+1")
--
Martin
Dr Martin Ward | Email: mar...@gkc.org.uk |
49 matches
Mail list logo
