Instruction for next week: BC 
Author Message
 Instruction for next week: BC

The instruction use statistics I saw said that BC is by far the most
used instruction, something close to 30%, so I think it would be nice
to have as instruction of the week, even though it might not be a very
interesting instruction.

(Also, EDMK was the instruction that the original S/360 designers decided
that they could most easily do without.)

What to say about BC.  There is a mask to select which condition code
values to branch on and which not to.  An ordinary RX style branch address.

Anything else to say about it?

-- glen



Tue, 02 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC
: The instruction use statistics I saw said that BC is by far the most
: used instruction, something close to 30%, so I think it would be nice
: to have as instruction of the week, even though it might not be a very
: interesting instruction.

I consider BCR 15,0 to be *very* interesting.
--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Tue, 02 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC
You knew I was going to respond to this, didn't you!

BR 0 is supposed to perform a "serialization function" on the CPU it's
executed on.  That is, it "trashes the cache" in case another CP has
updated something that's already in *your* cache and that you're about
to depend on to have the latest, greatest, most up-to-date-value.

On certain old OEM CPUs, this didn't happen.

JES2 uses this technique in several places.  The result was the odd S0C4
every few months.  The answer was OY39888 (from 1991).  (The fix was to
source modify JES2 to use a CS to do something pretty irrelevant instead
of the BR 0.  Any old CS would have done, but the author of the fix
actually changed an MVC to a CS so it looked more useful!)

I actually found this quite recently on two different systems.  It went
for literally a couple of years with no problem and then started
cropping up with fair regularity with they started to get pretty busy.

Bob

Quote:

<snip>

> I consider BCR 15,0 to be *very* interesting.
> --
> | Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
> | Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

> | 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |
> | Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Tue, 02 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

> I consider BCR 15,0 to be *very* interesting.
> --

I agree. I would be very interested in a discussion/explaination of when
BCR 15,0 is appropriate versus CS.

Then there was the time in my career when I couldn't remember all the
assembler extended mnemonic instructions (BL, BM, BH, etc.) so I coded
things like:

  BC B'1000',X
  BC B'0110',X

It is really easy to remember that after a compare instruction, the
first bit means zero, the second is low, the third is high and the forth
is overflow. That was a lot easier to remember than:

  BC 8,X
  BC 6,X

--

Beyond Software, Inc.      http://www.beyond-software.com
"Transforming Legacy Applications"



Tue, 02 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

>: The instruction use statistics I saw said that BC is by far the most
>: used instruction, something close to 30%, so I think it would be nice
>: to have as instruction of the week, even though it might not be a very
>: interesting instruction.
>I consider BCR 15,0 to be *very* interesting.

It used to be especially interesting on the 360/91, which was, as far as I
know, the first 360 to execute multiple instructions at the same time.
One result was the `imprecise interrupt', (S0C0) where you didn't really know
where the instruction that caused it was.  No instruction after the BCR 15,0
would be executed until all instructions before were done.

The PL/I F compiler, with some options set, would insert BCR 15,0 between
each statement.  That way, at least the statement number that caused
the interrupt would be right.  Also, the message changed to
'ERROR .... NEAR STATEMENT ...'  

And then my favorite, a debugging system that would let me set breakpoints
and then enter the de{*filter*} when it got to that point.  (It replaced the
instruction with an SVC).  On continue, it would have to simulate the
instruction at the breakpoint.  However, the simulation didn't know about
BCR 15,0 and actually did the branch.  Oops.

I don't know about other models, but it was pretty important on the 91.

-- glen



Tue, 02 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

>On certain old OEM CPUs, this didn't happen.

On a S/370 165 I worked on, you could get imprecise interrupts. The
execution process would go sailing on past the instruction which was
going to cause the interrupt, executing like mad. One I remember was a
soon to be S0C4ing MVC, which was followed by many RR instructions. The
dump demonstrated that about 10 instructions had been executing before
the S0C4 took hold. This was true of many powerful machines such as the
S/360 195.

The fortran compiler at the time had an option to add 0700's after each
generated instruction to isolate the problem in difficult cases.

john alvord



Wed, 03 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

> Then there was the time in my career when I couldn't remember all the
> assembler extended mnemonic instructions (BL, BM, BH, etc.) so I coded
> things like:

>   BC B'1000',X
>   BC B'0110',X

I'm the opposite; I never could remember the condition codes for H and L, so
I not only used the extended mnemonics for BC, but also wrote macros (no
longer needed) for BCR.

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Fri, 05 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

> It used to be especially interesting on the 360/91, which was, as far as I
> know, the first 360 to execute multiple instructions at the same time.
> One result was the `imprecise interrupt', (S0C0) where you didn't really know
> where the instruction that caused it was.  No instruction after the BCR 15,0
> would be executed until all instructions before were done.

The 360/65 had multiple instruction execution pipelines as well. I recall
seeing a dump with a PSW pointing to a perfectly valid instruction AND
result. Then further analysis showed that the PREVIOUS instruction was
the one that blew up. Tried to get IBM to acknowledge they had a potential
problem, only to find it was WAD.

--
Bill



Fri, 05 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

> The 360/65 had multiple instruction execution pipelines as well. I recall
> seeing a dump with a PSW pointing to a perfectly valid instruction AND
> result. Then further analysis showed that the PREVIOUS instruction was
> the one that blew up. Tried to get IBM to acknowledge they had a potential
> problem, only to find it was WAD.

Unless the ILC was zero, they were correct. The PSW on a program check normally
points beyond the failing instruction, and the ILC tells you how much to back up.

And no, the 360/65 did not have multiple instruction pipelines.

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Fri, 05 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC
I agree the 360/65 did not have a pipline or parallel instruction
execution, but I think it did have the ability to separate the I
function (instruction fetch, translation and address computation)
from the E function (instruction execution).  It was either that
or the /75 that could do that.  Because the I and E units were slightly
isolated, I think the /65 could generate an imprecise interrupt.\
However, it has been so long ...


Quote:


>> The 360/65 had multiple instruction execution pipelines as well. I recall
>> seeing a dump with a PSW pointing to a perfectly valid instruction AND
>> result. Then further analysis showed that the PREVIOUS instruction was
>> the one that blew up. Tried to get IBM to acknowledge they had a potential
>> problem, only to find it was WAD.

>Unless the ILC was zero, they were correct. The PSW on a program check normally
>points beyond the failing instruction, and the ILC tells you how much to back up.

>And no, the 360/65 did not have multiple instruction pipelines.

>--

>Shmuel (Seymour J.) Metz
>Reply to host nsf (dot) gov, user smetz

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Sat, 06 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:

>I'm the opposite; I never could remember the condition codes for H and L

Same here. The only time I recall ever coding BC (as opposed to one of the
extended mnemonics) was when I wanted a combination that wasn't covered by one
of the mnemonics.

Mark A. Young



Sat, 06 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC
On Fri, 17 Jul 1998 17:07:39 -0400, Bob Rutledge
[...]

Quote:
>I actually found this quite recently on two different systems.  It went
>for literally a couple of years with no problem and then started
>cropping up with fair regularity with they started to get pretty busy.

Actually you may find that BCR 15,0 is about the same as NOPR 0 on all
recent models.  Cache synchronization has been around for a while.  If
you _really_ had to issue BCR 15,0 to flush storage updates or purge
downlevel cache entries there would be a lot of broken software on
today's 10-way boxes.

----------
Bill Manry - IBM Products Division - Oracle Corp. USA
These are my opinions, not Oracle's.



Sat, 06 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC
NOPR 0 is not mentioned in PoP as doing serialization, BCR 15,0 is.  And
it wasn't me, is was IBM!

Bob

Quote:

<snip>

> Actually you may find that BCR 15,0 is about the same as NOPR 0 on all
> recent models.  Cache synchronization has been around for a while.  If
> you _really_ had to issue BCR 15,0 to flush storage updates or purge
> downlevel cache entries there would be a lot of broken software on
> today's 10-way boxes.

> ----------
> Bill Manry - IBM Products Division - Oracle Corp. USA
> These are my opinions, not Oracle's.



Sat, 06 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC

Quote:



> >I'm the opposite; I never could remember the condition codes for H and L

> Same here. The only time I recall ever coding BC (as opposed to one of the
> extended mnemonics) was when I wanted a combination that wasn't covered by one
> of the mnemonics.

Ditto for me, too. Like Shmuel I wrote macros for extended mnemonics (BC
as well as BCR, IIRC, for DOS in the 1966-67 time frame).

Bill {*filter*}

Quote:

> Mark A. Young



Sat, 06 Jan 2001 03:00:00 GMT  
 Instruction for next week: BC
On Tue, 21 Jul 1998 15:35:41 -0400, Bob Rutledge

Quote:

>NOPR 0 is not mentioned in PoP as doing serialization, BCR 15,0 is.  And
>it wasn't me, is was IBM!

No argument here.  My point is that "checkpoint-serialization" as
relates to processor cache is meaningless on most if not all current
processor models because they know how to cross-invalidate cache
entries on the fly.

Try this: rig a cache-flooding experiment like a CLCL that runs over a
megabyte, repeated 5,000 times.  Do this with a NOPR 0 after the CLCL
and then with a BCR 15,0 after the CLCL.  On our 9672 these time the
same, suggesting that cache is unaffected by BCR 15,0.  (Don't use a
padding MVCL for this test because on at least some models it is
optimized in a way that avoids soaking the cache.)

Not sure why IBM keeps that discussion in the PoP unless it's to
reserve the right to go back to making dumb caches.

----------
Bill Manry - IBM Products Division - Oracle Corp. USA
These are my opinions, not Oracle's.



Sun, 07 Jan 2001 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Next instr of the week - CS please

2. Linux Expo next week

3. C5.5.01 - next week?

4. FYI, I'll be offline for the next week

5. Dylan Course in Northern VA, USA next week

6. USENIX Very High Level Languages Symposium - NEXT WEEK!

7. Eiffel at OOPSLA (next week in Atlanta)

8. USENIX Very High Level Languages Symposium - NEXT WEEK!

9. Determing dates for next week

10. WorldconVR Event Next Week-Starbase C3 Invite!

11. CosmoCode 2.5 for NT due next week

 

 
Powered by phpBB® Forum Software