DIAG unknown OP 
Author Message
 DIAG unknown OP


Quote:
>access to the manual library). Many programmers in fact don't use the
>DIAG macro, but code it directly. Here's an example: Let's say you wanted
>to do the DIAG for 3270 screen I/O (nowadays, the preferred macro is CONSOLE)
>which is DIAG X'58' and you wanted to use R4 & R5 as your registers. You
>could code this line and get the desired result:
>         DC    X'83450058'
>I know it's weird putting a hex constant directly in the source, but that's
>the way you had to do it according to the old IBM manuals.

Yeah it is weird, and there is a pitfall involved here as well.  All 370
instructions MUST be on a halfword boundary (even though halfword integers
themselves do not need to be).  The above instruction, especially if you
are "hiding" it in a macro, could end up on a non-halfword boundary.  This
would happen only if it follows something other than an instruction, such
as some data areas in the program (and of course have a label to branch to).
There are a couple of ways to avoid this:

label    DS    0H
         DC    X'83450058'

and the other is:

         DC    Y(X'8345',X'0058')

You don't need to do this except in the few cases where you might be exposed
to a non-halfword address counter during assembly, but if you code this in a
macro, you can't be sure you will be on a halfword boundary.  If a label is
given that is certainly a clue to the possibility of being off boundary, but
just doing one of the above to be sure you are on the boundary is a simple
enough approach.
--
/***********************************************************************\

| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/



Sat, 18 Jun 1994 01:27:29 GMT  
 DIAG unknown OP

Quote:
>access to the manual library). Many programmers in fact don't use the
>DIAG macro, but code it directly. Here's an example: Let's say you wanted
>to do the DIAG for 3270 screen I/O (nowadays, the preferred macro is CONSOLE)
>which is DIAG X'58' and you wanted to use R4 & R5 as your registers. You
>could code this line and get the desired result:
>         DC    X'83450058'
>I know it's weird putting a hex constant directly in the source, but that's
>the way you had to do it according to the old IBM manuals.

Yeah it is weird, and there is a pitfall involved here as well.  All 370
instructions MUST be on a halfword boundary (even though halfword integers
themselves do not need to be).  The above instruction, especially if you
are "hiding" it in a macro, could end up on a non-halfword boundary.  This
would happen only if it follows something other than an instruction, such
as some data areas in the program (and of course have a label to branch to).
There are a couple of ways to avoid this:

label    DS    0H
         DC    X'83450058'

and the other is:

         DC    Y(X'8345',X'0058')

You don't need to do this except in the few cases where you might be exposed
to a non-halfword address counter during assembly, but if you code this in a
macro, you can't be sure you will be on a halfword boundary.  If a label is
given that is certainly a clue to the possibility of being off boundary, but
just doing one of the above to be sure you are on the boundary is a simple
enough approach.
--
/***********************************************************************\

| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/



Sat, 18 Jun 1994 01:27:29 GMT  
 DIAG unknown OP
Phil Howard correctly observed that the 370 instructions must be aligned on
halfword boundaries (coz this is what the i-fetch unit expects). He noted
that in a macro (or inline for that matter...) you can't expect the assembler
to deposit DC X'...' constants on the appropriate boundary unless you take
steps to persuade it to do so. There are a number of ways to do this,

label   DS 0H
        DC X'constant value'  works fine for *data*

label   DC Y(constant value) is ok too

in each case, these will work fine if you branch to label...

but if you're really building inline *code* for DIAG or something equally arcane,
you probably ought to use CNOP to get the correct alignment. NO-OPs (X'07'?)
work just fine when digested as instructions, pad zeros may not.

BTW, self modifying code does  really icky things to the 370s caches, so they are
best avoided if at all possible.

Another fine message from nit-pickers anonymous :O)

Chris.
--
"That's the problem with nature, something's always stinging you
 or oozing mucous all over you. Let's go and watch TV"  - Calvin


(408) 379-7000 x1163            1315 Dell Ave. Campbell CA 95008



Sat, 18 Jun 1994 03:58:26 GMT  
 DIAG unknown OP

Quote:

>you probably ought to use CNOP to get the correct alignment. NO-OPs (X'07'?)
>work just fine when digested as instructions, pad zeros may not.

If you only have an odd number of bytes to put in, what is the CNOP going
to get for you anyway?  In fact at least one of the assemblers doesn't
even let you drop a CNOP into 1 byte.

If you labeled the CNOP and it was on an odd boundary, You can't jump there,
and you certainly would not be falling through to it (from data).

A CNOP is good for things like alligning a BALR that needs to point R14
to a fullword on a fullword boundary, for example.  You would then use
CNOP to force things to 2 bytes off the fullword boundary (for the length
of the BALR).  Newer machines (all 370's as far as I know) allow almost
everything (except instructions, TOD clock, etc) on any boundary.  And the
high speed caching probably does well to hide the timing losses on the
misalignments anyway.  So today we probably don't need to worry about any
alignment problems except for the few remaining cases.

Quote:
>BTW, self modifying code does  really icky things to the 370s caches, so they are
>best avoided if at all possible.

Self modifying code is certainly a no-no.  If you MUST, only do so at quite
a large distance from the hit code, and don't keep hitting it over and over.
I have one program with self-modifying code, and all it does is change a
branch to a NOP by hitting the condition, and it does it only ONCE and in
the initialization section (the branch/NOP is in a very tight loop elsewhere).

Self modifying code by means of different virtual addresses can also lead
to a disaster.  The CPU can only detect this occurring when the LOGICAL
address is the same.  Suppose you have a privileged instruction in a
virtual machine where you are doing your own address translation.  You
set up two different logical addresses point to the same real address
(all this relative to your virtual machine of course).  Well VM will
have to set up the REAL address translation in a similar way.  But suppose
that privileged instruction is modified to a non-privileged one immediately
before it is used BY MEANS OF THE OTHER LOGICAL ADDRESS.  By this time the
instruction has been prefetch, and probably entirely decoded.  A privileged
operation exception will be passed on to VM (unless it is one that can be
handled in the microcode assist features).  VM now gets control to do the
privileged instruction simulation, but looks at the instruction to figure
out what to do, and there is NOW a non-privileged one there.  As of a couple
years ago, the VM/SP code for CP handled this by using the op code as an
index into a table of addresses in which the position for non-privileged
instruction op code were EMPTY.  CP now dies with a PRG001 or 5 or 6.
I've not looked at XA source to see if that is fixed.

Quote:
>Another fine message from nit-pickers anonymous :O)

At least there remain fewer nits this way :)
--
/***********************************************************************\

| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/


Sat, 18 Jun 1994 06:02:00 GMT  
 DIAG unknown OP
Phil Howard correctly observed that the 370 instructions must be aligned on
halfword boundaries (coz this is what the i-fetch unit expects). He noted
that in a macro (or inline for that matter...) you can't expect the assembler
to deposit DC X'...' constants on the appropriate boundary unless you take
steps to persuade it to do so. There are a number of ways to do this,

label   DS 0H
        DC X'constant value'  works fine for *data*

label   DC Y(constant value) is ok too

in each case, these will work fine if you branch to label...

but if you're really building inline *code* for DIAG or something equally
 arcane,
you probably ought to use CNOP to get the correct alignment. NO-OPs (X'07'?)
work just fine when digested as instructions, pad zeros may not.

BTW, self modifying code does  really icky things to the 370s caches, so they
 are
best avoided if at all possible.

Another fine message from nit-pickers anonymous :O)

Chris.
--
"That's the problem with nature, something's always stinging you
 or oozing mucous all over you. Let's go and watch TV"  - Calvin


(408) 379-7000 x1163            1315 Dell Ave. Campbell CA 95008



Sat, 18 Jun 1994 03:58:26 GMT  
 DIAG unknown OP

Quote:

>you probably ought to use CNOP to get the correct alignment. NO-OPs (X'07'?)
>work just fine when digested as instructions, pad zeros may not.

If you only have an odd number of bytes to put in, what is the CNOP going
to get for you anyway?  In fact at least one of the assemblers doesn't
even let you drop a CNOP into 1 byte.

If you labeled the CNOP and it was on an odd boundary, You can't jump there,
and you certainly would not be falling through to it (from data).

A CNOP is good for things like alligning a BALR that needs to point R14
to a fullword on a fullword boundary, for example.  You would then use
CNOP to force things to 2 bytes off the fullword boundary (for the length
of the BALR).  Newer machines (all 370's as far as I know) allow almost
everything (except instructions, TOD clock, etc) on any boundary.  And the
high speed caching probably does well to hide the timing losses on the
misalignments anyway.  So today we probably don't need to worry about any
alignment problems except for the few remaining cases.

Quote:
>BTW, self modifying code does  really icky things to the 370s caches, so they
 are
>best avoided if at all possible.

Self modifying code is certainly a no-no.  If you MUST, only do so at quite
a large distance from the hit code, and don't keep hitting it over and over.
I have one program with self-modifying code, and all it does is change a
branch to a NOP by hitting the condition, and it does it only ONCE and in
the initialization section (the branch/NOP is in a very tight loop elsewhere).

Self modifying code by means of different virtual addresses can also lead
to a disaster.  The CPU can only detect this occurring when the LOGICAL
address is the same.  Suppose you have a privileged instruction in a
virtual machine where you are doing your own address translation.  You
set up two different logical addresses point to the same real address
(all this relative to your virtual machine of course).  Well VM will
have to set up the REAL address translation in a similar way.  But suppose
that privileged instruction is modified to a non-privileged one immediately
before it is used BY MEANS OF THE OTHER LOGICAL ADDRESS.  By this time the
instruction has been prefetch, and probably entirely decoded.  A privileged
operation exception will be passed on to VM (unless it is one that can be
handled in the microcode assist features).  VM now gets control to do the
privileged instruction simulation, but looks at the instruction to figure
out what to do, and there is NOW a non-privileged one there.  As of a couple
years ago, the VM/SP code for CP handled this by using the op code as an
index into a table of addresses in which the position for non-privileged
instruction op code were EMPTY.  CP now dies with a PRG001 or 5 or 6.
I've not looked at XA source to see if that is fixed.

Quote:
>Another fine message from nit-pickers anonymous :O)

At least there remain fewer nits this way :)
--
/***********************************************************************\

| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/


Sat, 18 Jun 1994 06:02:00 GMT  
 DIAG unknown OP

Quote:
>Newer machines (all 370's as far as I know) allow almost
>everything (except instructions, TOD clock, etc) on any boundary.  And the
>high speed caching probably does well to hide the timing losses on the
>misalignments anyway.  So today we probably don't need to worry about any
>alignment problems except for the few remaining cases.

My 9370 is a factor of 45 (yep, forty-five) times slower on unaligned loads. I
didn't worry much about alignment when I started writing assembler code, on
that old (late 1970's) 370/138. Now I really have to pay attention to this - I
guess that's called progress. Admittedly, 3090's and other "serious" computers
don't suffer from these problems, but unfortunately that's not what I'm working
on.

  Eric



Sun, 19 Jun 1994 00:54:32 GMT  
 DIAG unknown OP

 (Phil Howard KA9WGN) writes...

Quote:
>Newer machines (all 370's as far as I know) allow almost
>everything (except instructions, TOD clock, etc) on any boundary.  And the
>high speed caching probably does well to hide the timing losses on the
>misalignments anyway.  So today we probably don't need to worry about any
>alignment problems except for the few remaining cases.

My 9370 is a factor of 45 (yep, forty-five) times slower on unaligned loads. I
didn't worry much about alignment when I started writing assembler code, on
that old (late 1970's) 370/138. Now I really have to pay attention to this - I
guess that's called progress. Admittedly, 3090's and other "serious" computers
don't suffer from these problems, but unfortunately that's not what I'm working
on.

  Eric



Sun, 19 Jun 1994 00:54:32 GMT  
 DIAG unknown OP

Quote:
>Yeah it is weird, and there is a pitfall involved here as well.  All 370
>instructions MUST be on a halfword boundary (even though halfword integers
>themselves do not need to be).  The above instruction, especially if you
>are "hiding" it in a macro, could end up on a non-halfword boundary.  This
>would happen only if it follows something other than an instruction, such
>as some data areas in the program (and of course have a label to branch to).
>There are a couple of ways to avoid this:

>label    DS    0H
>         DC    X'83450058'

>and the other is:

>         DC    Y(X'8345',X'0058')

And, just for the sake of completeness:

label     DC   0H'0',X'83450058'

Obviously very similar to Phil's first example, but it's easier to copy,
move, etc. from inside an editor.  I use the same method to put things
of a doubleword boundry (precede with 0D'0').
--
The above is my thoughts, not Amdahl's;   |  Terry Carroll  408/992-2152
The above is not legal advice;            |  Senior Computer Architect
All models over 18 years of age;          |  Amdahl Corporation




Sat, 18 Jun 1994 07:53:44 GMT  
 DIAG unknown OP

Quote:
>            .  Newer machines (all 370's as far as I know) allow almost
>everything (except instructions, TOD clock, etc) on any boundary.

FWIW, I recently discovered, much to my surprise, that the storage operand
of CS (Compare and Swap) must still be on a word boundry to avoid a PIC 6
specification exception.
--
The above is my thoughts, not Amdahl's;   |  Terry Carroll  408/992-2152
The above is not legal advice;            |  Senior Computer Architect
All models over 18 years of age;          |  Amdahl Corporation




Sat, 18 Jun 1994 08:08:14 GMT  
 DIAG unknown OP

Quote:

>FWIW, I recently discovered, much to my surprise, that the storage operand
>of CS (Compare and Swap) must still be on a word boundry to avoid a PIC 6
>specification exception.

Also, the storage operand of CDS (Compare Double and Swap) must still be on a
doubleword boundary: both these restrictions make sense, because the underlying
entities which must be partially or completely locked during a CS/CDS (i.e.,
units of memory and/or cache lines) always contain at least one aligned
doubleword so these restrictions make CS/CDS MUCH easier to implement (e.g.,
only one unit of memory is ever locked and only one cache line needs to be
cross-interrogated in other processors' caches).

I thought that CS/CDS might be a bit abstract for some readers, so I'll talk
about a practical use of them.  In MVS (and earlier related systems), an Event
Control Block (ECB), a fullword of data used as a pointer and semaphore when
WAITing for asynchronous events or POSTing that an asynchronous event has
occurred (e.g., a block has been READ from tape), must be on a word boundary
because its contents are defined to be serialized by the CS instruction: this
was done to allow inline processing to bypass the system WAIT and POST routines
(and all their overhead) when possible.

A diagram:

Cleared ECB (before WAIT/POST)  Posted ECB (one that has been posted)

Bit 0 1 ............ 31         Bit 0 1 ............ 31

    0 0 0 ...        0          0 1  (user-defined POST completion code)

Waited ECB (one that is being WAITed on)

Bit 0 1 ............ 31

    1 0 (irrelevant: system-dependent)

This architecture allows WAIT and POST to be done in any order (after the ECB
is cleared) and allows the program which posts an ECB to perform the needed
processing in line when possible.

If a program wants to wait on an ECB that has not yet been posted, it must call
the system WAIT routine (which will both mark the ECB as waited on and suspend
the waiting program); if the ECB has already been posted, the program can
simply continue processing (in this case, it doesn't matter how the ECB is
serialized: it has already been changed).

If a program wants to post an ECB that has been waited on, it must call the
system POST routine (which will both post the ECB and resume the waiting
program), but if the ECB has not yet been waited on, the program can attempt to
"pre-post" the ECB (by fetching the ECB data, checking to see that bit 0 is 0,
and, with the CS instruction, set bit 1 to 1 only if the ECB is unchanged: if
the ECB was unchanged, the pre-post succeeded and the call to the system POST
routine can be skipped, but if the ECB was changed after the ECB was fetched
but before the CS, the CS will leave the ECB alone and set an appropriate
condition code, which means that the pre-post failed and the program must call
the system POST routine).

--
John R. Grout
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development




Mon, 20 Jun 1994 05:11:42 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Serialization (was Re: DIAG unknown OP)

2. DIAG unknown OP

3. CNOP (was Re: DIAG unknown OP)

4. DIAG unknown OP

5. Interpretation of binary-op followed by unary-op

6. Reading unknown number of lines in unknown number of files

7. 2 questions: diag 68 and calling convention

8. instruction alignment and DIAG

9. Diag help files

10. Diag keyword

11. State diag. and Flow chart design

12. Op Code Matrix Enigma

 

 
Powered by phpBB® Forum Software