srutledg@yoda.eecs.wsu.edu (rutledge shawn d - CS250) (05/24/91)
This has already been asked before, so I'll be breif and please E-mail me personaly with any answer you could kindly supply... I am new at assembly programming and would like to know how to disable an interupt. I am trying to disable CTRL-BREAK on an MS-DOS maching. The interupt is 1Bh or 23h. Any reply would be greatly apriciated.
srutledg@YODA.EECS.WSU.EDU (rutledge shawn d - CS250) (05/24/91)
This has already been asked before, so I'll be breif and please E-mail me personaly with any answer you could kindly supply... I am new at assembly programming and would like to know how to disable an interupt. I am trying to disable CTRL-BREAK on an MS-DOS maching. The interupt is 1Bh or 23h. Any reply would be greatly apriciated.
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/25/91)
srutledg@yoda.eecs.wsu.edu (rutledge shawn d - CS250) writes: >This has already been asked before, so I'll be breif and please >E-mail me personaly with any answer you could kindly supply... >I am new at assembly programming and would like to know how to >disable an interupt. I am trying to disable CTRL-BREAK on an >MS-DOS maching. The interupt is 1Bh or 23h. Any reply would >be greatly apriciated. Wrong newsgroup. IBM mainframes are not PC's (we wish). Try alt.msdos.programmer or comp.os.msdos.programmer or comp.sys.ibm.pc.programmer and see if they know. -- /***************************************************************************\ / 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/25/91)
srutledg@yoda.eecs.wsu.edu (rutledge shawn d - CS250) writes: >This has already been asked before, so I'll be breif and please >E-mail me personaly with any answer you could kindly supply... >I am new at assembly programming and would like to know how to >disable an interupt. I am trying to disable CTRL-BREAK on an >MS-DOS maching. The interupt is 1Bh or 23h. Any reply would >be greatly apriciated. Wrong newsgroup. IBM mainframes are not PC's (we wish). Try alt.msdos.programmer or comp.os.msdos.programmer or comp.sys.ibm.pc.programmer and see if they know. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (05/25/91)
On Fri, 24 May 91 23:29:16 GMT <news%ucf1vm.BITNET%LILAC.BERKELEY.EDU@OHSTVMA.AC
>Wrong newsgroup. IBM mainframes are not PC's (we wish).
Phil:
Why would you wish that IBM mainframes were the brain-dead architecture
that the PC uses? You need the '386 before you can truly multitask safely,
and even if a 386 *can* go at 15MIPS, it's still useless because it
spends 12 of them doing loads and stores out of the 4 registers...
At the risk of starting a holy war, MS-DOS and the Intel 8x86 architecture
are the single worst thing to happen to computing.
Obligatory assembler question:
On small machines and handhelds (6502, HP-11, stuff like that), there's
a subculture involved in exploring undocumented opcodes, "synthetic
programming", and the like.
Does anybody out there have a war story of a "undocumented" opcode or
similar feature on an IBM 360/370/etc mainframe? My personal favorite
was when I was doing MUSIC hacking, and a kernel routine of mine took a
branch to East Fishkill on an IBM 4341, hit a data area, and tried to
execute a SIGP instruction. Oddly enough, it died on a privop
exception, not the regular operation exception you'd expect. I never
got brave enough to explore whether the 4341 *really* had a SIGP
instruction, or whether CP's instruction simulation was doing something
to me....
And is it true that a 360/44 had its SS format instructions
intentionally removed to cripple it and keep it slower than the 360/50,
because the 44's floating point made it so much faster?
/Valdisphil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/25/91)
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) writes: >>Wrong newsgroup. IBM mainframes are not PC's (we wish). >Phil: >Why would you wish that IBM mainframes were the brain-dead architecture >that the PC uses? You need the '386 before you can truly multitask safely, >and even if a 386 *can* go at 15MIPS, it's still useless because it >spends 12 of them doing loads and stores out of the 4 registers... You misunderstand. You interpreted it backwards. I wished that the 370 architecture was in the box we call a PC. >At the risk of starting a holy war, MS-DOS and the Intel 8x86 architecture >are the single worst thing to happen to computing. The only reason I disagree is because those are the TWO worst things. >And is it true that a 360/44 had its SS format instructions >intentionally removed to cripple it and keep it slower than the 360/50, >because the 44's floating point made it so much faster? While the other machines were microprogrammed, the 360/44 functioned mostly from hardware interpretation of the instructions, including hardware floating point operations in 5 different precisions. Single precision was normal, but double precision had a front panel dial that allowed 32, 40, 48, or 56 bit fractions to be used in calculation. The PS/44 operating system JOB card had a field where you specified the precision desired, the operating system asked the operator to set the dial, and when all was done, ran the job. So you could make a delicate tradeoff between precision and speed (the shorter formats were faster, of course). It didn't seem to catch on. The higher models of the 360 series soon beat it. -- /***************************************************************************\ / 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/25/91)
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) writes: >>Wrong newsgroup. IBM mainframes are not PC's (we wish). >Phil: >Why would you wish that IBM mainframes were the brain-dead architecture >that the PC uses? You need the '386 before you can truly multitask safely, >and even if a 386 *can* go at 15MIPS, it's still useless because it >spends 12 of them doing loads and stores out of the 4 registers... You misunderstand. You interpreted it backwards. I wished that the 370 architecture was in the box we call a PC. >At the risk of starting a holy war, MS-DOS and the Intel 8x86 architecture >are the single worst thing to happen to computing. The only reason I disagree is because those are the TWO worst things. >And is it true that a 360/44 had its SS format instructions >intentionally removed to cripple it and keep it slower than the 360/50, >because the 44's floating point made it so much faster? While the other machines were microprogrammed, the 360/44 functioned mostly from hardware interpretation of the instructions, including hardware floating point operations in 5 different precisions. Single precision was normal, but double precision had a front panel dial that allowed 32, 40, 48, or 56 bit fractions to be used in calculation. The PS/44 operating system JOB card had a field where you specified the precision desired, the operating system asked the operator to set the dial, and when all was done, ran the job. So you could make a delicate tradeoff between precision and speed (the shorter formats were faster, of course). It didn't seem to catch on. The higher models of the 360 series soon beat it. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) (05/25/91)
In comp.lang.asm370 you write: >Why would you wish that IBM mainframes were the brain-dead architecture >that the PC uses? You need the '386 before you can truly multitask safely, >and even if a 386 *can* go at 15MIPS, it's still useless because it >spends 12 of them doing loads and stores out of the 4 registers... BTW, the 486 does not have this problem. It caches internally in such a way that load and store take less than a cycle (if there is a hit in the internal cache). I'd much rather use some of the other processors anyway, such as 680x0, 88000, 80860, etc. I'm not a particular fan of RISC machines, but they are OK. Actually the 360/370 architecture is not all that far from what RISC turns out to be. VAXen are a mess. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
JIM@AUVM.AUVM.EDU (Jim McIntosh) (05/26/91)
In article <910524.224442.EDT.VALDIS@vtvm1.cc.vt.edu>, Valdis Kletnieks <VALDIS@VTVM1.CC.VT.EDU> says: >Does anybody out there have a war story of a "undocumented" opcode or >similar feature on an IBM 360/370/etc mainframe? Well, this is probably more appropriate for the alt.computer.folklore newsgroup, but here goes. Back in the early 80's I worked for a small PCM called Magnuson. The Magnuson processor had been designed by Carl Amdahl (which meant our company was called "Son of Amdahl") and competed with the 138/148 (and later the 4331/4341) boxes. The guy who wrote the initial cut of the microcode was a guy named Kevin Anderson (still in jail, last I heard, for trying to ship things he shouldn't have to the Russians). Kevin was an Othello buff, and hacked a game we had on our games disk... moving critical routines into the microcode. The Magnuson M80 was, therefore, the only IBM 370-compatible machine that had (in addition to ECPS:MVS, ECPS:VM, etc.) an undocumented ECPS:OTHELLO. I pity the poor programmer who stumbled into that instruction. :-) Speaking of assembler trivia, what are the three 370/390 instructions that have to be done twice in microcode for each target instruction? (The microcode has to run through the whole operation once to see what will happen, and then again for real.) Hint: The answer's in the POO. :-) --- Jim McIntosh (jim@auvm.auvm.edu) The American University Washington DC 20016-8019 USA
LDW@USCMVSA.BITNET (Leonard D Woren) (05/26/91)
> Why would you wish that IBM mainframes were the brain-dead architecture > that the PC uses? You need the '386 before you can truly multitask safely, > and even if a 386 *can* go at 15MIPS, it's still useless because it > spends 12 of them doing loads and stores out of the 4 registers... Yep. That's the problem with people who like to claim that a Sun 4/490 is 23 mips -- so what? If it wastes 90% of those cheap cycles running grossly inefficent C code, the true speed is 2.3 mips. If it takes you 10 instruction to do what can be done in one instruction on a 370, it's absolutely unreasonable to even talk about mips. That's why IBM resists giving mips ratings. > At the risk of starting a holy war, MS-DOS and the Intel 8x86 architecture > are the single worst thing to happen to computing. Nah, *ix is. At least not many people claim that MS-DOS is a reasonable system. But there are large numbers of people who think that *ix is the salvation of computing. Flames cheerfully ignored. > Does anybody out there have a war story of a "undocumented" opcode or > similar feature on an IBM 360/370/etc mainframe? How about an instruction that under certain conditions gives the wrong answer, guaranteed? Someone sprung that one on me. On a 360/91, there is a bug in the TRT instruction if you use R2 for the translate 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
BRUCE@UMDD.BITNET (Bruce Crabill) (05/26/91)
Microcode bugs still exist and IBM still refuses to believe/do anything about
them. I found a bug in 9370s that can cause the system to machine check by
running a program that runs in normal user mode. Never did get much
interest from IBM in fixing it.
Brucedave@visual1.jhuapl.edu (Dave Weintraub) (05/29/91)
In article <9105260616.AA17447@ucbvax.Berkeley.EDU>, LDW@USCMVSA.BITNET (Leonard D Woren) writes: |> Yep. That's the problem with people who like to claim that a Sun |> 4/490 is 23 mips -- so what? If it wastes 90% of those cheap cycles |> running grossly inefficent C code, the true speed is 2.3 mips. If it |> takes you 10 instruction to do what can be done in one instruction on |> a 370, it's absolutely unreasonable to even talk about mips. That's |> why IBM resists giving mips ratings. |> Worst case I've seen of this was a SAS speaker on the HP sell-the-new-HP-workstation videotape. He shows a SAS application running on a 3090/E61 with vector, crawling along. Only problem is that, to the best I've been able to determine, SAS C compiler does not take advantage of multiprocessing OR vector ... Dave
news@ucf1vm.BITNET (05/29/91)
In article <9105260616.AA17447@ucbvax.Berkeley.EDU>, LDW@USCMVSA.BITNET (Leonard D Woren) writes: |> Yep. That's the problem with people who like to claim that a Sun |> 4/490 is 23 mips -- so what? If it wastes 90% of those cheap cycles |> running grossly inefficent C code, the true speed is 2.3 mips. If it |> takes you 10 instruction to do what can be done in one instruction on |> a 370, it's absolutely unreasonable to even talk about mips. That's |> why IBM resists giving mips ratings. |> Worst case I've seen of this was a SAS speaker on the HP sell-the-new-HP-workstation videotape. He shows a SAS application running on a 3090/E61 with vector, crawling along. Only problem is that, to the best I've been able to determine, SAS C compiler does not take advantage of multiprocessing OR vector ... Dave
Jerry Bryan <BRYAN@wvnvm.wvnet.edu> (05/29/91)
> >Does anybody out there have a war story of a "undocumented" opcode or >similar feature on an IBM 360/370/etc mainframe? My personal favorite >was when I was doing MUSIC hacking, and a kernel routine of mine took a >branch to East Fishkill on an IBM 4341, hit a data area, and tried to >execute a SIGP instruction. Oddly enough, it died on a privop >exception, not the regular operation exception you'd expect. I never >got brave enough to explore whether the 4341 *really* had a SIGP >instruction, or whether CP's instruction simulation was doing something >to me.... > The old Waterloo WATBOL compiler used invalid opcodes on purpose (trapping them with SPIE macro) to effect paragraph tracing. One of the opcodes they chose invoked the APL microcode assist on a 370/148 rather than generating on operation exception. We therefore found the problem of why tracing wouldn't work by reading the 148's microcode. (By the way, a 148 would run APL faster than a 168 because of the 148's microcode assist.)
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/30/91)
Jerry Bryan <BRYAN@wvnvm.wvnet.edu> writes: >The old Waterloo WATBOL compiler used invalid opcodes on purpose (trapping >them with SPIE macro) to effect paragraph tracing. One of the opcodes >they chose invoked the APL microcode assist on a 370/148 rather than >generating on operation exception. We therefore >found the problem of why tracing wouldn't work by reading the 148's >microcode. If the compiler is generating the code, why can't it simply generate a branch to a trace subroutine. When I need tracing, I use a set of trace macros I write. Works great and does not affect any registers. The only requirement is that there be a base register in effect. -- /***************************************************************************\ / 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)
Jerry Bryan <BRYAN@wvnvm.wvnet.edu> writes: >The old Waterloo WATBOL compiler used invalid opcodes on purpose (trapping >them with SPIE macro) to effect paragraph tracing. One of the opcodes >they chose invoked the APL microcode assist on a 370/148 rather than >generating on operation exception. We therefore >found the problem of why tracing wouldn't work by reading the 148's >microcode. If the compiler is generating the code, why can't it simply generate a branch to a trace subroutine. When I need tracing, I use a set of trace macros I write. Works great and does not affect any registers. The only requirement is that there be a base register in effect. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/