Serialization (was Re: DIAG unknown OP) 
Author Message
 Serialization (was Re: DIAG unknown OP)


>All instructions 070x, where x=0 to F, are no-ops which mean don't branch
>regardless of the condition code.  The instructions 07x0 are not quite
>equivalent, even though all but one of them are also no-ops (because an
>stored in register 0 is never used for indexing or branching); on all
>processors with multiple functional units (starting with the 360/91 and
>including all modern ones), instruction 07F0 (BCR 15,0) is the serialization
>instruction: all prefetched data is discarded, all results are stored, and the
>processor basically starts at the next instruction from scratch (for things
>like fetching instructions, prefetching data, etc.); in recent processors,
>is only used when one has done something unusual (like an unaligned store into
>an instruction which is about to be executed) which the processor would
>otherwise trip over, but on the 360/91 and 370/195, this instruction was used
>all the time; these processors executed more than one instruction at once, and
>would sometimes take "imprecise interrupts" when an earlier instruction failed

If I remember correctly, on the 360/91, the instruction 07x0 (BCR x,R0), where
is any non-zero value, would force serialization regardless of the condition
code. In the early 70's I used to use the 360/91 at Columbia University where
the PL/I F compiler was configured for the model 91: it would generate BCR 1,R0
instructions (not BR 0) where necessary to handle imprecise interrupts (such as
betwwen statements when the STMT option was turned on). I remember the manual
for the model 91 stating that despite all the caching and prefetching that it
did, it would still operate correctly even if an instruction modified the the
very next instruction; does j-grout's posting mean that this is not true if
the modification is unaligned? On the other hand, I recall the System/370
Principles of Operation stating that an attempted branch to register 0 would
cause a serialization; this would imply that only BCR 15,R0 would do this
unconditionally while the four{*filter*} non-F, non-0 values of x would do it
depending on the cond. code (not no-ops).

Also, getting back to the DIAG instruction, yet another way to code it would

label   DC      H'-31931,88'

Not very obvious, perhaps, but there for the sake of completeness. :-)

As one who hasn't used a 370 in 13 years (I'm now a Mac person), I thought I'd
put in my two cents worth.

Fri, 15 Jul 1994 23:34:19 GMT  
 [ 1 post ] 

 Relevant Pages 

1. DIAG unknown OP

2. DIAG unknown OP

3. CNOP (was Re: DIAG unknown OP)

4. DIAG unknown OP

5. I am glad Oberon is unknown....

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

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

8. 2 questions: diag 68 and calling convention

9. instruction alignment and DIAG

10. Diag help files

11. Diag keyword

12. State diag. and Flow chart design


Powered by phpBB® Forum Software