VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (05/26/91)
On Sat, 25 May 91 23:18:00 PDT Leonard D Woren said: >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
LDW@USCMVSA.BITNET (Leonard D Woren) (05/27/91)
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 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...VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (05/27/91)
On Sun, 26 May 91 14:20:00 PDT Leonard D Woren said: >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
dandrews@bilver.uucp (Dave Andrews) (05/28/91)
In article <9105262118.AA28795@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >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
dandrews@bilver.UUCP (Dave Andrews) (05/28/91)
In article <9105262118.AA28795@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >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
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/29/91)
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) writes: >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. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
news@ucf1vm.BITNET (05/29/91)
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) writes: >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. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
XMAS@BOGECNVE.BITNET (05/29/91)
>>... 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. >... >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 ------------------------------------------------------------------------ Mark A. Stevens BITNET: XMAS@BOGECNVE Educational Computing Network Internet: xmas@ve.bogecn.edu Governors State University Phone: 708-534-0200 University Park, IL 60466 FAX: 708-534-0054
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/30/91)
XMAS@BOGECNVE.BITNET writes: >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. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
news@ucf1vm.BITNET (05/30/91)
XMAS@BOGECNVE.BITNET writes: >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. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
HAROLD@UGA.CC.UGA.EDU (Harold Pritchett) (05/30/91)
On Wed, 29 May 91 08:39:19 -0500 <XMAS@BOGECNVE> said: > >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 Harold C Pritchett | BITNET: HAROLD@UGA BITNET TechRep | ARPA: harold@uga.cc.uga.edu The University of Georgia | Athens, GA 30602 | fido: 1:370/60 (404) 542-3135 | Bbs: SYSOP at (404) 354-0817
XMAS@BOGECNVE.BITNET (05/30/91)
>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? >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 ------------------------------------------------------------------------ Mark A. Stevens BITNET: XMAS@BOGECNVE Educational Computing Network Internet: xmas@ve.bogecn.edu Governors State University Phone: 708-534-0200 University Park, IL 60466 FAX: 708-534-0054
XMAS@BOGECNVE.BITNET (05/30/91)
>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. >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 ------------------------------------------------------------------------ Mark A. Stevens BITNET: XMAS@BOGECNVE Educational Computing Network Internet: xmas@ve.bogecn.edu Governors State University Phone: 708-534-0200 University Park, IL 60466 FAX: 708-534-0054
IQTI400@INDYCMS.BITNET (MacPhil) (05/30/91)
On Thu, 30 May 91 09:04:42 EDT Harold Pritchett said: > >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