Bogon interrupts... 
Author Message
 Bogon interrupts...

On Sat, 25 May 91 23:18:00 PDT Leonard D Woren said:
Quote:
>table base register.  I also was told a story about that same 360/91.
>When it was first installed, apparently a STM that started in your key
>and crossed a page boundary into another key FINISHED and THEN gave a
>protection exception.  IBM wouldn't believe it until a systems
>programmer toggled a demonstration program into the machine via the
>front panel switches...  (First they claimed it was an O.S. bug.)

Leonard:

Well, I'll agree that failure to suppress/terminate is a bug...
However, I remember another bugaboo that the 360/65 (and probably other
models) had - the "imprecise interrupt"...

"When the instruction-length code in the program old PSW is zero, the
exception was not necessarily caused by the last instruction executed.
Interruptions that case a zero instruction-length code to be set in the
program old PSW are referred to as IMPRECISE PROGRAM INTERRUPTIONS, and
the exceptions causing such interrupts are referred to as IMPRECISE
EXCEPTIONS.  By contrast, a program interruption associated with a
non-zero instruction-length code, and the corresponding exception, are
referred to as PRECISE.  In the Model 65, an IMPRECISE program exception
can occur only when a protection check (store only) is encountered."
(from the 360/65 functional characteristics manual).

I remember as a beginning assembler jock having problems with this - it
was *very* unhandy to debug your program.  Loads of fun to be saying
"Well, it was *probably* the 'ST R3,0(,R6)' except we'll never know
since we did the LM R2,R8,8(,R11) before we got shot down...."

My feeble memory recalls one time where a program did a bad store, then
did an SVC call, and the imprecise interrupt arrived later...  with
predictable results...

/Valdis



Thu, 11 Nov 1993 15:23:03 GMT  
 Bogon interrupts...
Hmmm... And I thought that the 360/91 was the only machine that had
those blasted imprecise interrupts.  NOPR ^0 was a special
implementation that flushed the pipeline, so that you could isolate
instructions that were causing S0C0s.

I once had a program get an S0C0 on the LR at the top of a loop:
  LOOP  LR  R1,R2
        ...
        ...
        ST  R3,0(,R4)
        B   LOOP
It turned out to be the ST that was bad!!!

I haven't read Functional Characteristics for newer machines as
carefully as I read the one for the 360/91, and it seems that they
don't have as much detail as that one did, but I get the idea that no
machine since the 91 has the same sophisticated parallelism and
pipelining.  The 91 had 3 fixed point execution units, and 4 floating
point execution units.  The number of cycles listed for a floating
point add, substract, or load register (etc) was zero!  The 91 could
actually count in floating point faster than in fixed point.

Assembler programming on the 91 was interesting.  To get the maximum
performance out of the machine, we would use strange instruction
sequences like
   S    R1,aaa
   ST   R0,xxx
   BNP  wherever
instead of putting the ST in front of the S, because the BNP had to
wait for the results of the S, so we could give the machine something
else to do while waiting for the S to complete.

Also, the 91 would follow *both* forks in a branch instruction, and
then discard the results of the unsuccessful direction.  I don't know
how it avoided S0C0s down the unsuccessful path...

Since the 91 didn't have decimal instructions except for CVB, CVD, ED,
and EDMK, it was a long time before I learned to use things like AP.
I still resist them.

/Leonard

P.S.

Quote:
> ... {quote about imprecise interrupts} ...
> (from the 360/65 functional characteristics manual).

So I'm not the only who keeps some old manuals for their historical
value.  I wonder where my 360/20 F.C. is...


Fri, 12 Nov 1993 05:20:00 GMT  
 Bogon interrupts...
On Sun, 26 May 91 14:20:00 PDT Leonard D Woren said:
Quote:
>Hmmm... And I thought that the 360/91 was the only machine that had
>those blasted imprecise interrupts.  NOPR ^0 was a special

Did some poking around in my S/370 POO (GA22-7000-10) and
the "imprecise interrupt" on a store is listed in the "Priority of
program-interruption conditions" on page 6-32, so at least some
models of the S/370 may have had this problem.  I think that they fixed
this in the 303x, and later CPUs, so it was confined to the S/360 and S/370
processors only.

I see that what goes around, comes around..  sounds like the 360/91 had
similar pipelining and delayed branch semantics as the current
generation of RISC chips.  This proves that programmers as a whole are
getting soft - the 360/91 was considered programmable in assembler, but
today's programmers think that it's "too hard" and let an optimizing
compiler do it.....

/Valdis



Sat, 13 Nov 1993 00:34:30 GMT  
 Bogon interrupts...


Quote:
>Hmmm... And I thought that the 360/91 was the only machine that had
>those blasted imprecise interrupts.  NOPR  0 was a special
>implementation that flushed the pipeline, so that you could isolate
>instructions that were causing S0C0s.

>/Leonard
>So I'm not the only who keeps some old manuals for their historical
>value.  I wonder where my 360/20 F.C. is...

I was also a little surprised about the m65.  In my old PLIF Programmer's
Reference (there are more of us pack rats than you'd think!) I remember
the section on the M91 option, where the F compiler would insert NOPs
at strategic places in order to handle ON-units properly.

From Appendix G:
  "IBM System/360 Models 91 and 195 are high-speed processing systems
  in which more than one instruction is executed concurrently.  As a
  result, an exception may be detected and an interrupt occur when
  the address of the instruction which caused the exception is no longer
  held in the central processing unit.  Consequently, the instruction
  causing the interrupt cannot be precisely identified.  Interrupts of
  this type are termed _imprecise_."
It goes on to describe the M91 option.  They say:
  "The option must always apply when the compiler is used to produce
  object programs for execution on a Model 91 or 195.  The effect of
  the option is:
    1.  To cause the compiler to insert 'no-operation' instructions
        at certain points in the program to localize imprecise interrupts...
        No-operation instructions are generated a. before an ON statement
        b. before a REVERT statement, c. before compiled code to set the
        SIZE condition, d. before compiled code to change prefix conditions,
        e. for a null statement, and f. before every statement if the
        STMT compiler option applies.
    2.  To creat an ESD entry for the PL/I library module IHEM91..."

Anyway, it doesn't mention m65.  Doesn't mean you aren't right, though.
I've Been Misled, and all that.

- Dave



Sat, 13 Nov 1993 01:57:05 GMT  
 Bogon interrupts...

Quote:
>Hmmm... And I thought that the 360/91 was the only machine that had
>those blasted imprecise interrupts.  NOPR ^0 was a special
>implementation that flushed the pipeline, so that you could isolate
>instructions that were causing S0C0s.

>/Leonard
>So I'm not the only who keeps some old manuals for their historical
>value.  I wonder where my 360/20 F.C. is...

I was also a little surprised about the m65.  In my old PLIF Programmer's
Reference (there are more of us pack rats than you'd think!) I remember
the section on the M91 option, where the F compiler would insert NOPs
at strategic places in order to handle ON-units properly.

From Appendix G:
  "IBM System/360 Models 91 and 195 are high-speed processing systems
  in which more than one instruction is executed concurrently.  As a
  result, an exception may be detected and an interrupt occur when
  the address of the instruction which caused the exception is no longer
  held in the central processing unit.  Consequently, the instruction
  causing the interrupt cannot be precisely identified.  Interrupts of
  this type are termed _imprecise_."
It goes on to describe the M91 option.  They say:
  "The option must always apply when the compiler is used to produce
  object programs for execution on a Model 91 or 195.  The effect of
  the option is:
    1.  To cause the compiler to insert 'no-operation' instructions
        at certain points in the program to localize imprecise interrupts...
        No-operation instructions are generated a. before an ON statement
        b. before a REVERT statement, c. before compiled code to set the
        SIZE condition, d. before compiled code to change prefix conditions,
        e. for a null statement, and f. before every statement if the
        STMT compiler option applies.
    2.  To creat an ESD entry for the PL/I library module IHEM91..."

Anyway, it doesn't mention m65.  Doesn't mean you aren't right, though.
I've Been Misled, and all that.

- Dave



Sat, 13 Nov 1993 01:57:05 GMT  
 Bogon interrupts...

Quote:

>I see that what goes around, comes around..  sounds like the 360/91 had
>similar pipelining and delayed branch semantics as the current
>generation of RISC chips.  This proves that programmers as a whole are
>getting soft - the 360/91 was considered programmable in assembler, but
>today's programmers think that it's "too hard" and let an optimizing
>compiler do it.....

Yes, I definitely see this as a trend.

Some of us are good programmers and we can do things in just about any
language, and can chose which one is best for whatever needs to be done.
And when that happens to be assembler, we won't flinch, either.

But as a greater and greater portion of the population becomes programmers,
we start to lower the common denominator.
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Sun, 14 Nov 1993 09:31:34 GMT  
 Bogon interrupts...

Quote:

>I see that what goes around, comes around..  sounds like the 360/91 had
>similar pipelining and delayed branch semantics as the current
>generation of RISC chips.  This proves that programmers as a whole are
>getting soft - the 360/91 was considered programmable in assembler, but
>today's programmers think that it's "too hard" and let an optimizing
>compiler do it.....

Yes, I definitely see this as a trend.

Some of us are good programmers and we can do things in just about any
language, and can chose which one is best for whatever needs to be done.
And when that happens to be assembler, we won't flinch, either.

But as a greater and greater portion of the population becomes programmers,
we start to lower the common denominator.
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Sun, 14 Nov 1993 09:31:34 GMT  
 Bogon interrupts...

Quote:
>>...                        This proves that programmers as a whole are
>>getting soft - the 360/91 was considered programmable in assembler, but
>>today's programmers think that it's "too hard" and let an optimizing
>>compiler do it.....

>Yes, I definitely see this as a trend.

It should be.

Quote:
>...
>But as a greater and greater portion of the population becomes programmers,
>we start to lower the common denominator.

Not all of us are Indy/Grand Prix/etc race car drivers, but most of us
can operate a motor vehicle with some small proficiency.

Not all of us are surgeons, but most people can remove a splinter and
apply a band-aid(tm).

 ... Mark
------------------------------------------------------------------------


Governors State University                     Phone: 708-534-0200
University Park, IL  60466                       FAX: 708-534-0054



Sun, 14 Nov 1993 21:39:19 GMT  
 Bogon interrupts...

Quote:

>Not all of us are Indy/Grand Prix/etc race car drivers, but most of us
>can operate a motor vehicle with some small proficiency.
>Not all of us are surgeons, but most people can remove a splinter and
>apply a band-aid(tm).

Of course.  But we don't suggest that race car drivers use conventional
road practices, nor that surgeons just use little band-aids.

But there are some that would want even the expert programmers to follow
the practices that make it possible for so many others to program, and
then uses excuses like "that someone else might have to maintain it".
If someone else has to maintain it, then we are back to depending on the
lower common denominator.
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Mon, 15 Nov 1993 08:16:20 GMT  
 Bogon interrupts...

Quote:

>Not all of us are Indy/Grand Prix/etc race car drivers, but most of us
>can operate a motor vehicle with some small proficiency.
>Not all of us are surgeons, but most people can remove a splinter and
>apply a band-aid(tm).

Of course.  But we don't suggest that race car drivers use conventional
road practices, nor that surgeons just use little band-aids.

But there are some that would want even the expert programmers to follow
the practices that make it possible for so many others to program, and
then uses excuses like "that someone else might have to maintain it".
If someone else has to maintain it, then we are back to depending on the
lower common denominator.
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Mon, 15 Nov 1993 08:16:20 GMT  
 Bogon interrupts...

Quote:

>Not all of us are Indy/Grand Prix/etc race car drivers, but most of us
>can operate a motor vehicle with some small proficiency.

>Not all of us are surgeons, but most people can remove a splinter and
>apply a band-aid(tm).

That's fine if all you want to do is something on the level of splinter
removal.  If, however you want to do something on the level of open heart
surgery, do you do it yourself, or do you get a professional?

As far as I am concerned, there are too many amateurs out there trying to
do brain surgery when they should stick to what they do best and get a
professional programmer to do what they do best.

Harold



The University of Georgia  |
Athens, GA 30602           |    fido:  1:370/60
(404) 542-3135             |     Bbs:  SYSOP at (404) 354-0817



Mon, 15 Nov 1993 21:04:42 GMT  
 Bogon interrupts...

Quote:
>But there are some that would want even the expert programmers to follow
>the practices that make it possible for so many others to program, and
>then uses excuses like "that someone else might have to maintain it".

What specific practices inhibit expert programmers from writing good
code that cause maintenance to be so much more difficult?

Quote:
>If someone else has to maintain it, then we are back to depending on the
>lower common denominator.

This seems to be getting on "religious" grounds, but I would like to
add:

If you maintain somebody elses code, I (imho) think you have a tougher
job than the designer.  A maintainer has to learn to think like the
author in order to fix or enhance the original product.

If you disagree, you haven't dealt with much of what IBM distributes ;->
especially in terms of fixing.

 ... Mark
------------------------------------------------------------------------


Governors State University                     Phone: 708-534-0200
University Park, IL  60466                       FAX: 708-534-0054



Mon, 15 Nov 1993 22:07:09 GMT  
 Bogon interrupts...

Quote:
>That's fine if all you want to do is something on the level of splinter
>removal.  If, however you want to do something on the level of open heart
>surgery, do you do it yourself, or do you get a professional?

I'm not in disagreement.  If you haven't time/skill to do it properly,
get someone who can.  It's far less expensive in the long run.

Quote:
>As far as I am concerned, there are too many amateurs out there trying to
>do brain surgery when they should stick to what they do best and get a
>professional programmer to do what they do best.

You got that right.  However, we do happen to be in a position to help
the amateur do better.  He/she may never be capable of brain surgery,
but with our help, they might do better than removing splinters.

 ... Mark
------------------------------------------------------------------------


Governors State University                     Phone: 708-534-0200
University Park, IL  60466                       FAX: 708-534-0054



Mon, 15 Nov 1993 22:19:44 GMT  
 Bogon interrupts...
On Thu, 30 May 91 09:04:42 EDT Harold Pritchett said:

Quote:

>As far as I am concerned, there are too many amateurs out there trying to
>do brain surgery when they should stick to what they do best and get a
>professional programmer to do what they do best.

That's because they see it as "cheaper" (to steal the old tv ad "we're
just as good as AT&T, just "cheaper").  But then, they don't consider all
of the additional costs & troubles & frustrations built into their
estimate.

Just remember:

   "You get what you pay for, and if you don't, then you didn't."
                                        -p. paxton



Mon, 15 Nov 1993 23:05:18 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. GNAT: Ada.Interrupts and Ada.Interrupts.Names

2. Interrupts in TSR interrupt handlers

3. Interrupts in interrupts?

4. interrupts in interrupts

5. Interrupt interrupts ?

6. interrupt handler for timer interrupt-shekhar

7. Calling interrupts from within interrupts????????

8. PM Programming: Interrupts not interrupting

9. DOS Interrupt/BIOS interrupt function reference

10. play sound file from an interrupt service routine of the timing interrupt?

11. Getting pre-interrupt registers under a DPMI hw interrupt?

12. play sound file from an interrupt service routine of the timing interrupt?

 

 
Powered by phpBB® Forum Software