From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Early interupts on mainframes Date: 5 Aug 1999 23:48:57 GMT Organization: Net Access BBS Lines: 41 Message-ID: <7od7t9$kin@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newsfeed.stanford.edu!arclight.uoregon.edu!news-xfer.newsread.com!news-toy.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root This came up before, but I remain confused on the concept of a computer "interupt" and how it worked on older machines. First a definition: As I understand a CPU "interupt" today (either mainframe or PC), the CPU will automatically cease work on a problem program when an interupt signal is generated. The CPU has, in essence, a secondary input source beyond that of the application program, that senses the interupt signal, and then switches control to handle the interupt. The application program has to wait until the interupt is serviced. On the mainframe, this concepts allows multiprogramming. When a program needs CPU service, it issues an interupt. The CPU's supervisor program then kicks in to service the interupt and switch control around as necessary. This concept also allows more efficient "polling". Instead of the CPU constantly executing a program loop to test an indicator to see if the situation changed, the CPU may freely do other work (such as an application program without any such tests). If say an online terminal needs service, the interput is generated and the CPU will notice it and take appropriate action. So that's the definition. Let's look back at the 7090, IBM's old big machine. Did that machine have true "interupt" handling, or did all application programs have to follow a shop convention of testing some indicator on every loop cycle, then taking some action on a hit? (And of course all programmers including the action logic in their programs). On the 7090, was SABRE the only online application it carried, or did other users have online applications as well? What kind of terminals and online controllers did the 7090 have? Were IBM's Selectric typewriter terminals available for it? In 1965-66 my bank put in computer terminals to service passbook accounts. I'm think they were the 1040 (it used a Selectric ball.) I always wondered if they had a 7090 or S/360 behind it--this was still very early in the S/360 era. ###### Message-ID: <37AA43D4.437F1DF5@iedu.org> From: Morris Dovey Organization: iedu.org / iedu.com X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,fr,pt,ru,es MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 22 Date: Thu, 05 Aug 1999 21:09:24 -0500 NNTP-Posting-Host: 207.108.37.10 X-Trace: news.uswest.net 933905480 207.108.37.10 (Thu, 05 Aug 1999 21:11:20 CDT) NNTP-Posting-Date: Thu, 05 Aug 1999 21:11:20 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!news-out.uswest.net!news.uswest.net!not-for-mail Lisa or Jeff wrote: > In 1965-66 my bank put in computer terminals to service passbook > accounts. I'm think they were the 1040 (it used a Selectric ball.) > I always wondered if they had a 7090 or S/360 behind it--this was > still very early in the S/360 era. Your understanding of interrupts is on-target. One important aspect was that the interrupt mechanism (circuitry + software/firmware) saved the state of the machine at the time the interrupt was recognized and (normally) restored the machine to that state when interrupt service is complete. The bank could have had either a 709x or a S/360 (more probably a S/360 at that point in time) or they may even have had an IBM 1800 or 14xx machine. I'd guess that 1040's were more likely to appear on a S/360 or 1800 than the others. Morris Dovey West Des Moines, Iowa USA mrdovey@iedu.org ###### Message-ID: <37AA6F54.F904FEE3@iedu.org> From: Morris Dovey Organization: iedu.org / iedu.com X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,fr,pt,ru,es MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> <37aa51a7.40124388@news.shuswap.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 29 Date: Fri, 06 Aug 1999 00:15:00 -0500 NNTP-Posting-Host: 207.108.37.10 X-Trace: news.uswest.net 933916616 207.108.37.10 (Fri, 06 Aug 1999 00:16:56 CDT) NNTP-Posting-Date: Fri, 06 Aug 1999 00:16:56 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!logbridge.uoregon.edu!news-out.uswest.net!news.uswest.net!not-for-mail Gene Wirchenko wrote: > hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: > > >On the mainframe, this concepts allows multiprogramming. When a > >program needs CPU service, it issues an interupt. The CPU's supervisor > >program then kicks in to service the interupt and switch control around > >as necessary. > > NO! > > If a program doesn't have the CPU, how could it do anything? > > If you substitute "I/O device" for "program", you have an > accurate statement. Classical misunderstanding. On /some/ systems applications could execute an instruction which would generate an interrupt signal (like the SVC instruction on the S/360 or the RST instruction on the Intel 8080) once the interrupt had been generated, it was typically handled (by the hardware) just as if it had been generated by an I/O device. One of the common uses for such program-generated interrupts was to request kernel/supervisor services without having to know the address of the service routine. Morris Dovey West Des Moines, Iowa USA mrdovey@iedu.org ###### From: genew@shuswap.net (Gene Wirchenko) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Fri, 06 Aug 1999 05:00:25 GMT Organization: Okanagan Internet Junction Lines: 26 Message-ID: <37aa51a7.40124388@news.shuswap.net> References: <7od7t9$kin@netaxs.com> Reply-To: genew@shuswap.net NNTP-Posting-Host: salmonarm1-29.shuswap.net X-Trace: news.junction.net 933915367 16353 206.87.124.157 (6 Aug 1999 04:56:08 GMT) X-Complaints-To: abuse@junction.net NNTP-Posting-Date: 6 Aug 1999 04:56:08 GMT X-Newsreader: Forte Free Agent 1.1/32.230 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!cyclone.bc.net!news.junction.net!not-for-mail hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: [snip] >On the mainframe, this concepts allows multiprogramming. When a >program needs CPU service, it issues an interupt. The CPU's supervisor >program then kicks in to service the interupt and switch control around >as necessary. NO! If a program doesn't have the CPU, how could it do anything? If you substitute "I/O device" for "program", you have an accurate statement. [snip] Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ###### From: jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: 6 Aug 1999 13:20:49 GMT Organization: The MITRE Corporation Lines: 72 Message-ID: <7oenfh$aq1$1@top.mitre.org> References: <7od7t9$kin@netaxs.com> Reply-To: jcmorris@linus.mitre.org NNTP-Posting-Host: jmorris-pc.mitre.org X-Trace: top.mitre.org 933945649 11073 128.29.251.13 (6 Aug 1999 13:20:49 GMT) X-Complaints-To: usenet@news.mitre.org NNTP-Posting-Date: 6 Aug 1999 13:20:49 GMT X-Newsreader: NN version 6.5.0 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.cwix.com!169.132.11.200!news.idt.net!usenet.logical.net!news.tufts.edu!blanket.mitre.org!news.mitre.org!jmorris-pc.MITRE.ORG!jcmorris hancock4@bbs.cpcn.com (Lisa or Jeff) writes: >On the mainframe, this concepts allows multiprogramming. When a >program needs CPU service, it issues an interupt. The CPU's supervisor >program then kicks in to service the interupt and switch control around >as necessary. This is a "synchronous interrupt," one that occurs at a particular point in the execution of the currently-running task. It may occur as the result of a deliberate request by the program (in the S/360 world, this is the function of the SVC (Supervisor Call) instruction), or it might be the result of a program error trap (such as a reference to an invalid address, or an attempt to execute a privileged instruction in user mode, or something similar). >This concept also allows more efficient "polling". Instead of the >CPU constantly executing a program loop to test an indicator to see >if the situation changed, the CPU may freely do other work (such as >an application program without any such tests). If say an online >terminal needs service, the interput is generated and the CPU will >notice it and take appropriate action. More correctly, the use of interrupts makes polling unnecessary. In this situation you have an *asynchronous interrupt;" that is, one that occurs as a result of some event external to the currently- running task. Typically this might be the completion of an I/O event, the expiration of a timer, or the detection of a hardware failure in the computer itself. In general, the arrival of an asynchronous interrupt is handled by identifying the cause of the interrupt, performing any appropriate actions on the associated task, possibly initiating an I/O action, and either returning control of the computer to the interrupted task or causing a task switch. Does anyone notice that this is a description of a classic "object-oriented" environment? Mainframe operating systems programmers were doing OO long before the name was invented. >Let's look back at the 7090, IBM's old big machine. Did that >machine have true "interupt" handling, or did all application programs >have to follow a shop convention of testing some indicator on every loop >cycle, then taking some action on a hit? (And of course all programmers >including the action logic in their programs). The 709x (and 704x) had interrupt capabilities. As best I can recall the FMS (Fortran Monitor System) used the timer interrupt but didn't use the I/O interrupts for normal I/O (remember that this was a single-user, batch system); IBSYS (the successor to FMS) did. >On the 7090, was SABRE the only online application it carried, >or did other users have online applications as well? >What kind of terminals and online controllers did the 7090 have? >Were IBM's Selectric typewriter terminals available for it? I never used a 709x that had attached communications devices so I can't directly answer the question, but I do recall seeing both TeleType and Selectric (1050?) terminals sitting around in the MIT computer center. >In 1965-66 my bank put in computer terminals to service passbook >accounts. I'm think they were the 1040 (it used a Selectric ball.) >I always wondered if they had a 7090 or S/360 behind it--this was >still very early in the S/360 era. The 10xx terminals date to the 14xx/70xx period, but their use continued long into the S/360 era. Joe Morris ###### From: glass2@glass2.lexington.ibm.com Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: 6 Aug 1999 13:53:42 GMT Organization: IBM Austin Lines: 80 Message-ID: <7oepd6$vdk$1@ausnews.austin.ibm.com> References: <7od7t9$kin@netaxs.com> <37aa51a7.40124388@news.shuswap.net> <37AA6F54.F904FEE3@iedu.org> Reply-To: wa4qal@vnet.ibm.net NNTP-Posting-Host: glass2.cv.lexington.ibm.com X-Newsreader: IBM NewsReader/2 2.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!news-peer-europe.sprintlink.net!news.sprintlink.net!newsfeed1.swip.net!swipnet!tank.news.pipex.net!pipex!uunet!zur.uu.net!ffx.uu.net!an02.austin.ibm.com!ausnews.austin.ibm.com!not-for-mail In <37AA6F54.F904FEE3@iedu.org>, Morris Dovey writes: >Gene Wirchenko wrote: > >> hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: >> >> >On the mainframe, this concepts allows multiprogramming. When a >> >program needs CPU service, it issues an interupt. The CPU's supervisor >> >program then kicks in to service the interupt and switch control around >> >as necessary. >> >> NO! >> >> If a program doesn't have the CPU, how could it do anything? >> >> If you substitute "I/O device" for "program", you have an >> accurate statement. > >Classical misunderstanding. On /some/ systems applications could execute an >instruction which would generate an interrupt signal (like the SVC >instruction on the S/360 or the RST instruction on the Intel 8080) once the >interrupt had been generated, it was typically handled (by the hardware) >just as if it had been generated by an I/O device. One of the common uses >for such program-generated interrupts was to request kernel/supervisor >services without having to know the address of the service routine. > >Morris Dovey >West Des Moines, Iowa USA >mrdovey@iedu.org Acutally, the SVC does more than just call a service routine. It can also change the priviledge level of the system. Consider where a piece of code is running in user mode, which means that it can't issue any I/O instructions, that it can't execute certain priviledged instructions, that it can only do things within its own little world. If this piece of code wants to perform an I/O operation (or, in general, communiate out of its little world), it would typically issue an SVC to transfer control to the operating system, which would begin executing in supervisor mode. The operating system would verify that the user has the authority to perform the requested I/O function (e.g., he's writing into his dataset, and not over writing someone elses data, etc.). It would then perform the I/O operation (which it can since its running in supervisor mode), and finally return to the user in user mode. I'm told that the 80x86 has similar functions (where X>''). On the S/360 (and successors), any interrupt, whether it's a SVC or a hardware interrupt, causes the current PSW (Program Status Word) to be stashed in low memory at a certain address, and a new PSW to be loaded. The PSW contains the address of the program being executed (program counter for those more familar with microprocessors), and additionally contains flags which indicate the user/supervisor mode, and other control information. This new PSW has the address of a First Level Interrupt Handler (FLIH). Execution begins in the FLIH program, and this program determines what's to be done. Typically this includes saving the machine state (general registers, control registers, floating point registers, access registers, etc.) so that it may be restored when control returns to where the processor was running when the interrupt happened. As for types of interrupts, there are two basic types, software and hardware. Software interrupts are caused by executing an instruction (SVC on the S/360 family, and INT on the 80x86 family). Hardware interrupts are caused by a hardware device sending a signal into a special pin on the processor chip. Certain exception conditions (numeric overflow, divide-by-zero, etc.) may also be handled like an interrupt. On certain processors, there may be a multiple levels of hardware interrupts. This allows a priority system, whereby one I/O device can interrupt the routine servicing another device. Also, some processors have maskable interrupts and non-maskable interrupts. This allows the processor to suppress maskable interrupts if it's running code which can't be interrupted. However, certain interrupts (e.g., parity errors, or other hardware failure) must be processed immediately when they occur, and can not be suppressed or delayed. Dave P.S. Standard Disclaimer: I work for them, but I don't speak for them. ###### Newsgroups: alt.folklore.computers References: <7od7t9$kin@netaxs.com> Reply-To: sarr@umich.edu Organization: University of Michigan Subject: Re: Early interupts on mainframes From: sarr@stick.us.itd.umich.edu (Sarr J. Blumson) Lines: 26 Message-ID: Date: Fri, 06 Aug 1999 17:13:09 GMT NNTP-Posting-Host: 141.211.165.85 X-Trace: news.itd.umich.edu 933959589 141.211.165.85 (Fri, 06 Aug 1999 13:13:09 EDT) NNTP-Posting-Date: Fri, 06 Aug 1999 13:13:09 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news.eecs.umich.edu!news.itd.umich.edu!sarr In article <7od7t9$kin@netaxs.com>, Lisa or Jeff wrote: [Other folks have talked about interrupts] >On the 7090, was SABRE the only online application it carried, >or did other users have online applications as well? IIRC the 7090 was originally built to support the US Ballistic Missile Early Warning System. MIT's Compatible Time Sharing System ran on a 7090. There were many others. >What kind of terminals and online controllers did the 7090 have? >Were IBM's Selectric typewriter terminals available for it? > >In 1965-66 my bank put in computer terminals to service passbook >accounts. I'm think they were the 1040 (it used a Selectric ball.) >I always wondered if they had a 7090 or S/360 behind it--this was >still very early in the S/360 era. 1050 maybe? A thing that looked kind of like a Selectric typewriter but several times larger. -- -------- Sarr Blumson sarr@umich.edu voice: +1 734 764 0253 home: +1 734 665 9591 ITD, University of Michigan http://www-personal.umich.edu/~sarr/ ###### From: jgd@alpha3.csd.uwm.edu (John G Dobnick) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: 6 Aug 1999 19:53:52 GMT Organization: University of Wisconsin - Milwaukee Lines: 30 Message-ID: <7ofegg$udh$1@uwm.edu> References: <37AA6F54.F904FEE3@iedu.org> Reply-To: jgd@alpha3.csd.uwm.edu NNTP-Posting-Host: 129.89.7.203 Originator: jgd@alpha3.csd.uwm.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news0.de.colt.net!colt.net!newsfeed.icl.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!uwm.edu!alpha3.csd.uwm.edu!jgd From article <37AA6F54.F904FEE3@iedu.org>, by Morris Dovey : > > Classical misunderstanding. On /some/ systems applications could execute an > instruction which would generate an interrupt signal (like the SVC > instruction on the S/360 or the RST instruction on the Intel 8080) once the > interrupt had been generated, it was typically handled (by the hardware) > just as if it had been generated by an I/O device. One of the common uses > for such program-generated interrupts was to request kernel/supervisor > services without having to know the address of the service routine. Also, certain "exceptional conditions" (arithmetic overflow, divide by zero, address out of limits, memory-protect violation, etc.) are implemented as interrupts on some systems. (These are sometimes called "traps" by some manufacturers, "exceptions" by others, and "interrupts" by still others.) They are, however, still program generated. And then there are "hardware exceptions", as in memory parity/fault detection, CPU internal errors detection, etc. These also can generate "fault interrupts", and are _not_ I/O or program related. Exactly _what_ is detected and reported is highly implementation dependent. [Does that just about cover everything?] -- John G Dobnick "Knowing how things work is the basis Information & Media Technologies for appreciation, and is thus a University of Wisconsin - Milwaukee source of civilized delight." jgd@uwm.edu ATTnet: (414) 229-5727 -- William Safire ###### From: jvarela@mind-spring.com (John Varela) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: 6 Aug 1999 20:28:59 GMT Organization: MindSpring Enterprises Lines: 22 Message-ID: References: <7od7t9$kin@netaxs.com> NNTP-Posting-Host: a5.f7.44.f2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Newsreader: ProNews/2 Version 1.50 Beta 1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newscore.gigabell.net!newscore.ipf.de!dca1-hub1.news.digex.net!intermedia!hermes.visi.com!news-out.visi.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!not-for-mail On Thu, 5 Aug 1999 23:48:57, hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: > Let's look back at the 7090, IBM's old big machine. Before the 7090 there was the AN/FSQ-7, the SAGE computer. It was a real-time system and did NOT have interrupts. Everything worked on a cyclic basis. The cycle was called a "frame", each frame divided into three subframes of 5, 5, and 5 and a fraction seconds. Some programs executed every subframe, some only in the third subframe, and still others only when some other program had set the work-waiting bit for them in the "sequence parameters". An interrupt capability was installed on the FSQ-7 prototype at MITRE (XD-1) sometime in 1962 or 63. All I recall about it is that someone wrote a memo proposing ways of using it, but the whole support facility at MITRE was decommissioned not long after. Whether an interrupt capability was ever installed in the field I do not know. -- John Varela to e-mail, remove - between mind and spring ###### From: alex*@*rockvax.rockefeller.edu (Alexandre Pechtchanski) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Organization: Rockefeller University Hospital (GCRC), New York Message-ID: <37ac4e52.26099899@Rockyd> References: <7od7t9$kin@netaxs.com> <7oenfh$aq1$1@top.mitre.org> X-Newsreader: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 27 Date: Fri, 06 Aug 1999 21:08:24 GMT NNTP-Posting-Host: 129.85.24.56 X-Trace: rockyd.rockefeller.edu 933973753 129.85.24.56 (Fri, 06 Aug 1999 17:09:13 EDT) NNTP-Posting-Date: Fri, 06 Aug 1999 17:09:13 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newspeer.monmouth.com!newsfeed.nyu.edu!rockyd.rockefeller.edu!not-for-mail On 6 Aug 1999 13:20:49 GMT, jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) wrote: [ snip ] >More correctly, the use of interrupts makes polling unnecessary. In >this situation you have an *asynchronous interrupt;" that is, one >that occurs as a result of some event external to the currently- >running task. Typically this might be the completion of an I/O >event, the expiration of a timer, or the detection of a hardware >failure in the computer itself. > >In general, the arrival of an asynchronous interrupt is handled >by identifying the cause of the interrupt, performing any >appropriate actions on the associated task, possibly initiating >an I/O action, and either returning control of the computer to >the interrupted task or causing a task switch. > >Does anyone notice that this is a description of a classic >"object-oriented" environment? Mainframe operating systems >programmers were doing OO long before the name was invented. Just the error I made the other day! This is a description of _event-driven_ programming, which is usually, but not necessarily, implemented in object-oriented code. [ When replying, remove *'s from address ] Alexandre Pechtchanski, Systems Manager, RUH, NY ###### From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Fri, 06 Aug 1999 21:10:37 GMT Organization: PowerSurfr - High Speed Internet Lines: 49 Message-ID: <37ab4da7.21075502@news.prosurfr.com> References: <7od7t9$kin@netaxs.com> NNTP-Posting-Host: c9169-003.v-wave.com X-Trace: dagger.videotron.ab.ca 933973755 2214 24.108.21.103 (6 Aug 1999 21:09:15 GMT) X-Complaints-To: abuse@powersurfr.com NNTP-Posting-Date: 6 Aug 1999 21:09:15 GMT X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newscore.gigabell.net!newscore.ipf.de!unlisys!news.snafu.de!newsfeed.germany.net!newsfeed.berkeley.edu!newsfeed.direct.ca!news.tac.net!news.videotron.ab.ca!not-for-mail hancock4@bbs.cpcn.com (Lisa or Jeff) wrote, in part: >This came up before, but I remain confused on the concept of a >computer "interupt" and how it worked on older machines. >First a definition: As I understand a CPU "interupt" today (either >mainframe or PC), the CPU will automatically cease work on a >problem program when an interupt signal is generated. The CPU >has, in essence, a secondary input source beyond that of the application >program, that senses the interupt signal, and then switches control >to handle the interupt. The application program has to wait until >the interupt is serviced. >On the mainframe, this concepts allows multiprogramming. When a >program needs CPU service, it issues an interupt. The CPU's supervisor >program then kicks in to service the interupt and switch control around >as necessary. This is all very close (of course, non-running programs don't issue interrupts, as someone noted) but it misses the essentials of how such a thing can even work. A signal - possibly from an external device needing service, perhaps also a regular signal from a real-time clock - signals the computer that it is to interrupt what it is doing. The computer finishes executing the instruction it is performing. (If it has a pipeline or a cache, it puts those things in a tidy state too.) Then it does a special kind of subroutine call to the interrupt service routine applicable to that particular interrupt. This special subroutine call saves the complete machine state, so that any program - with the exception of certain hardware drivers, which run in supervisor state, and are allowed to turn interrupts off - interrupted after any arbitrary instruction, will run perfectly after return from that special subroutine call. If the machine has separate user and supervisor states, an interrupt will often put the machine in supervisor state. This is allowed because the memory location that contains the pointer to the interrupt service routine is protected from tampering. For mainframe multiprogramming, when a program needs to do I/O, it does a subroutine call, and the operating system then sets that program aside until its I/O is finished. Otherwise, a program just doing CPU work gets interrupted by a clock interrupt, and at that point the operating system switches to the next program able to use the CPU. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm ###### From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Fri, 06 Aug 1999 21:12:07 GMT Organization: PowerSurfr - High Speed Internet Lines: 12 Message-ID: <37ab4f66.21522337@news.prosurfr.com> References: <7od7t9$kin@netaxs.com> <37aa51a7.40124388@news.shuswap.net> <37AA6F54.F904FEE3@iedu.org> NNTP-Posting-Host: c9169-003.v-wave.com X-Trace: dagger.videotron.ab.ca 933973846 2214 24.108.21.103 (6 Aug 1999 21:10:46 GMT) X-Complaints-To: abuse@powersurfr.com NNTP-Posting-Date: 6 Aug 1999 21:10:46 GMT X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!cyclone.bc.net!newsfeed.direct.ca!news.tac.net!news.videotron.ab.ca!not-for-mail Morris Dovey wrote, in part: >Classical misunderstanding. On /some/ systems applications could execute an >instruction which would generate an interrupt signal (like the SVC >instruction on the S/360 or the RST instruction on the Intel 8080) Yes, but a program that isn't running can't execute an SVC instruction or any other. Instead, transfer of control to a non-running program takes place when a running program either requests I/O, or is interrupted by a *clock* interrupt. John Savard ( teneerf<- ) http://www.ecn.ab.ca/~jsavard/crypto.htm ###### From: bernie@fantasyfarm.com (Bernie Cosell) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Sat, 07 Aug 1999 00:08:35 GMT Organization: Fantasy Farm Fibers Lines: 36 Message-ID: <37ac7888.608454027@news.remarq.com> References: <7od7t9$kin@netaxs.com> <37aa51a7.40124388@news.shuswap.net> <37AA6F54.F904FEE3@iedu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: 933984943 ZVVAZMJVB392DB781 usenet50.supernews.com X-Complaints-To: newsabuse@remarQ.com X-Newsreader: Forte Agent 1.5/32.452 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.ntr.net!remarQ60!rQdQ!supernews.com!remarQ.com!remarQ69!not-for-mail Morris Dovey wrote: } Gene Wirchenko wrote: } } > hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: } > } > >On the mainframe, this concepts allows multiprogramming. When a } > >program needs CPU service, it issues an interupt. The CPU's supervisor } > >program then kicks in to service the interupt and switch control around } > >as necessary. } > } > NO! } > } > If a program doesn't have the CPU, how could it do anything? } > } > If you substitute "I/O device" for "program", you have an } > accurate statement. } } Classical misunderstanding. On /some/ systems applications could execute an } instruction which would generate an interrupt signal (like the SVC } instruction on the S/360 or the RST instruction on the Intel 8080) once the } interrupt had been generated, it was typically handled (by the hardware) } just as if it had been generated by an I/O device. One of the common uses } for such program-generated interrupts was to request kernel/supervisor } services without having to know the address of the service routine. Indeed: this was precisely the mechanism they used on the PDP6/10: basically, there was an illegal instruction code and its trap effected a "system call", and then the rest of the instruction was used to say "which system call" and such... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- ###### From: bernie@fantasyfarm.com (Bernie Cosell) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Sat, 07 Aug 1999 00:10:52 GMT Organization: Fantasy Farm Fibers Lines: 22 Message-ID: <37ad794b.608648923@news.remarq.com> References: <7od7t9$kin@netaxs.com> X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Agent 1.5/32.452 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newscore.gigabell.net!newscore.ipf.de!news0.de.colt.net!colt.net!newsfeed.icl.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.ntr.net!remarQ60!rQdQ!supernews.com!remarQ.com!news.supernews.com!not-for-mail sarr@stick.us.itd.umich.edu (Sarr J. Blumson) wrote: } In article <7od7t9$kin@netaxs.com>, Lisa or Jeff wrote: } } [Other folks have talked about interrupts] } } >On the 7090, was SABRE the only online application it carried, } >or did other users have online applications as well? } } IIRC the 7090 was originally built to support the US Ballistic Missile Early } Warning System. MIT's Compatible Time Sharing System ran on a 7090. There } were many others. Didn't CTSS run on a 7094? I haven't seen the manuals in decades, but I thought that the '94 was a '90 with some hacks added to it to _permit_ it to run as a timeshared system rather than a batch processor... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- ###### From: Dennis Ritchie Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Sat, 07 Aug 1999 02:07:50 +0100 Organization: Bell Labs, Lucent Technologies Lines: 15 Message-ID: <37AB86E6.1722@bell-labs.com> References: <7od7t9$kin@netaxs.com> <37ad794b.608648923@news.remarq.com> Reply-To: dmr@bell-labs.com NNTP-Posting-Host: cebu.cs.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!uunet!nyc.uu.net!ffx.uu.net!nntphub.cb.lucent.com!news Bernie Cosell asked, > Didn't CTSS run on a 7094? I haven't seen the manuals in decades, but I > thought that the '94 was a '90 with some hacks added to it to _permit_ it > to run as a timeshared system rather than a batch processor... Yes, it did, but not on a stock 7094, which was basically an upgraded and faster version of the 7090. CTSS (the influential MIT time-sharing system) required some heavy, special RPQs, most notably an extra 32KW bank of core memory, memory protection, and a supervisor mode, which plain 7094s did not have. See http://www.multicians.org/7094.html for Tom Van Vleck's account (it has other links). Dennis ###### From: genew@shuswap.net (Gene Wirchenko) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Sat, 07 Aug 1999 04:35:14 GMT Organization: Okanagan Internet Junction Lines: 42 Message-ID: <37ab9ad1.45098381@news.shuswap.net> References: <7od7t9$kin@netaxs.com> <37aa51a7.40124388@news.shuswap.net> <37AA6F54.F904FEE3@iedu.org> Reply-To: genew@shuswap.net NNTP-Posting-Host: salmonarm1-00.shuswap.net X-Trace: news.junction.net 934000254 9908 206.87.124.128 (7 Aug 1999 04:30:54 GMT) X-Complaints-To: abuse@junction.net NNTP-Posting-Date: 7 Aug 1999 04:30:54 GMT X-Newsreader: Forte Free Agent 1.1/32.230 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!cyclone.bc.net!news.junction.net!not-for-mail Morris Dovey wrote: >Gene Wirchenko wrote: > >> hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: >> >> >On the mainframe, this concepts allows multiprogramming. When a >> >program needs CPU service, it issues an interupt. The CPU's supervisor >> >program then kicks in to service the interupt and switch control around >> >as necessary. >> >> NO! >> >> If a program doesn't have the CPU, how could it do anything? >> >> If you substitute "I/O device" for "program", you have an >> accurate statement. > >Classical misunderstanding. On /some/ systems applications could execute an >instruction which would generate an interrupt signal (like the SVC >instruction on the S/360 or the RST instruction on the Intel 8080) once the >interrupt had been generated, it was typically handled (by the hardware) >just as if it had been generated by an I/O device. One of the common uses >for such program-generated interrupts was to request kernel/supervisor >services without having to know the address of the service routine. Meaning that the program would be requesting OS/whatever services *not* the CPU as you stated. RST 8H was used on the Radio Shack TRS-80 Model I as a compact (one byte instead of three) call to the tokenizing routine. I suppose it must have been called in many places though I don't know why it would have been. Anyone? Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ###### Newsgroups: alt.folklore.computers From: ehrice@his.com (Edward Rice) Subject: Re: Early interupts on mainframes Message-ID: Organization: NDS Date: Sat, 07 Aug 1999 04:42:02 -0400 References: <7od7t9$kin@netaxs.com> NNTP-Posting-Host: pm9-174.his.com Lines: 144 X-Authenticated-User: ehrice Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.frontiernet.net!nntp.gctr.net!news4.his.com!user In article <7od7t9$kin@netaxs.com>, hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: > First a definition: As I understand a CPU "interupt" today (either > mainframe or PC), the CPU will automatically cease work on a > problem program when an interupt signal is generated. The CPU > has, in essence, a secondary input source beyond that of the application > program, that senses the interupt signal, and then switches control > to handle the interupt. The application program has to wait until > the interupt is serviced. Honeywell used a slightly different but very useful terminology. An /interrupt/ was something external to the CPU-box that caused the processor to stop what it was doing, save state, and go elsewhere to perform a function. A /fault/ was something that the processor itself did (i.e., the cause was internal to the CPU box) that caused it to stop what it was doing, save state, and go elsewhere to perform a function. In that terminology, I/O finishing and things like the power to the CPU getting flakey would produce interrupts. A program needing a service or a timer in the CPU running out would produce faults. A fault-generating instruction (MME on the G-600 series, SVC on the IBM 360, etc.) is essentially an illegal instruction that has been designed into the machine to be specially treated -- a special interrupt/fault vector address is provided, etc. But the behavior is basically the same as executing an illegal op-code. GE placed two such instructions into the 600 series, the MME (Master Mode Entry) and the DRL (Derail). In general use, a time-sharing application running encapsulated under TSS would issue DRLs to get services from the timesharing executive; and any program (including TSS) would then issue MMEs to obtain services from the real operating system. But there's no overwhelming reason that TSS couldn't, if DRL didn't exist, have used a zero opcode (which was non-executable) as its opcode for requests. And the supervisor was programmed to abort any program that issued a DRL to it, but could just as easily have been programmed to provide a set of services for various DRL requests. (Later in the life of GCOS, DRLs were used to deliver requests to a database management system, so that complex DBMS requests were issued by programs just the same way simple I/O requests were issued.) Application programs do not have to wait for services to complete before proceeding. Starting asynchronous I/O is a perfect example of a program issuing a request but not waiting for completion before it could continue. > On the mainframe, this concepts allows multiprogramming. When a > program needs CPU service, it issues an interupt. The CPU's supervisor > program then kicks in to service the interupt and switch control around > as necessary. In a multiprocessor environment, it is very often (but not always!) the case that an interrupt results in a service being provided to a process that was not the one currently running while a fault results in a service being provided to the process that was currently running. The same is true, except for the specific terminology, on IBM systems. > This concept also allows more efficient "polling". Instead of the > CPU constantly executing a program loop to test an indicator to see > if the situation changed, the CPU may freely do other work (such as > an application program without any such tests). If say an online > terminal needs service, the interput is generated and the CPU will > notice it and take appropriate action. > > So that's the definition. Uh... polling is generally very inefficient and is avoided whenever possible. An interrupt system (including faults) is designed into a system to /avoid/ polling, not to perform more efficient polling. > Let's look back at the 7090, IBM's old big machine. Did that > machine have true "interupt" handling, or did all application programs > have to follow a shop convention of testing some indicator on every loop > cycle, then taking some action on a hit? (And of course all programmers > including the action logic in their programs). The 7094 had true interrupts. You could ask for the processor to be interrupted when an I/O completed, and a fault-type of interrupt was taken when the timer clock overflowed. There may have been one or two others as well. However, the interrupt structure was very, very simple. It did permit the user (or the system) to start multiple I/O operations using those dandy independently-operating data channels, and then wait for the first one to complete to announce its completion by interrupt. > On the 7090, was SABRE the only online application it carried, > or did other users have online applications as well? SABRE was special hardware, special software, and basically had nothing to do with the rest of the IBM product line. It wasn't the start of timesharing, it didn't have what you'd consider a user interface, and it was really not comparable to anything else. There's a Saber Group web page located at: http://www.sabre.com/ I can recall a special-purpose interface being implemented, about 1968, so that users throughout a university could set up programs on paper tape, send the contents of their tape to the computing center by phone line, and have their jobs executed on the 7094 located there. They had to come to the computing center to pick up their printed-on-regular-paper output. I know that no consideration whatever was given to creating this facility to feed directly into the 7094 -- instead, a special-purpose box that fed a stand-alone tape drive would answer the phone and copy records to the tape. Periodically, the tape would be fed into AFBIC, the 7094's batch BASIC processor, to execute. > What kind of terminals and online controllers did the 7090 have? It didn't, as I recall. It was, in most computing centers, what we'd consider a "compute server." Smaller machines were arrayed around it (logically around, physically wherever) to feed it and take away the output, but the main goal of the computing structure was to keep cranking jobs through the 709x as fast as possible. Tying it up by making it deal with character input from terminals would have been highly counterproductive. > Were IBM's Selectric typewriter terminals available for it? They had not yet been invented when the 7094 design was finished. > In 1965-66 my bank put in computer terminals to service passbook > accounts. I'm think they were the 1040 (it used a Selectric ball.) > I always wondered if they had a 7090 or S/360 behind it--this was > still very early in the S/360 era. Possibly a 1401 or 1410. A 1401 could have two communications adapters and, if properly coded, could deal with both terminals at the same time. In 1965-66 you might have been seeing an early S/360 application. I'd really think that maybe the recollection is off by a few years -- in 1965-66 this would have been a really unusual thing to see, while by four years later it would have been not uncommon. There were some unusual "DCOS" (Direct-Coupled Operating System) 7094 sites. IBM had some special hardware that let a 7044 and a 7094 share memory, and the 7044 could talk to terminals or a good array of peripherals. I know that Yale University ran DCOS to keep their 7094 busy, for a number of years, and I suspect other universities did also. I'm not aware of a DCOS application to serve businesses like the bank you mention, but I think it could physically have been done. The cost effectiveness is a different issue -- in the 7094 era, the cost of putting a terminal online to an IBM mainframe was terribly high, while in the 360 era that cost dropped by probably two orders of magnitude. That's another reason I'd expect an online banking system to be a few years later -- banks required reliability and in the 1965-66 period, the 360 wasn't reliable. ###### From: "donald tees" Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Sat, 7 Aug 1999 11:53:16 -0400 Organization: IGS - Information Gateway Services Lines: 36 Message-ID: <7ohklo$raf$2@news.igs.net> References: <37AA6F54.F904FEE3@iedu.org> <7ofegg$udh$1@uwm.edu> NNTP-Posting-Host: ttyd19.kw.igs.net X-Trace: news.igs.net 934041080 27983 216.58.99.185 (7 Aug 1999 15:51:20 GMT) X-Complaints-To: abuse@igs.net NNTP-Posting-Date: 7 Aug 1999 15:51:20 GMT X-Newsreader: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!hermes.visi.com!news-out.visi.com!news.maxwell.syr.edu!newsfeed.cwix.com!206.191.82.230!prairie.attcanada.net!newsfeed.attcanada.net!216.58.1.11!nntp.igs.net!news.igs.net!not-for-mail John G Dobnick wrote in message <7ofegg$udh$1@uwm.edu>... >From article <37AA6F54.F904FEE3@iedu.org>, by Morris Dovey : >> >> Classical misunderstanding. On /some/ systems applications could execute an >> instruction which would generate an interrupt signal (like the SVC >> instruction on the S/360 or the RST instruction on the Intel 8080) once the >> interrupt had been generated, it was typically handled (by the hardware) >> just as if it had been generated by an I/O device. One of the common uses >> for such program-generated interrupts was to request kernel/supervisor >> services without having to know the address of the service routine. > > Also, certain "exceptional conditions" (arithmetic overflow, divide > by zero, address out of limits, memory-protect violation, etc.) are > implemented as interrupts on some systems. (These are sometimes > called "traps" by some manufacturers, "exceptions" by others, and > "interrupts" by still others.) They are, however, still program > generated. > > And then there are "hardware exceptions", as in memory parity/fault > detection, CPU internal errors detection, etc. These also can > generate "fault interrupts", and are _not_ I/O or program related. > Exactly _what_ is detected and reported is highly implementation > dependent. > > [Does that just about cover everything?] Coffee breaks? ;<) ###### From: jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: 7 Aug 1999 16:56:54 GMT Organization: The MITRE Corporation Lines: 48 Message-ID: <7ohogm$5r3$1@top.mitre.org> References: <7od7t9$kin@netaxs.com> Reply-To: jcmorris@linus.mitre.org NNTP-Posting-Host: jmorris-pc.mitre.org X-Trace: top.mitre.org 934045014 5987 128.29.251.13 (7 Aug 1999 16:56:54 GMT) X-Complaints-To: usenet@news.mitre.org NNTP-Posting-Date: 7 Aug 1999 16:56:54 GMT X-Newsreader: NN version 6.5.0 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sunqbc.risq.qc.ca!News.Dal.Ca!usenet.logical.net!news.tufts.edu!blanket.mitre.org!news.mitre.org!jmorris-pc.MITRE.ORG!jcmorris ehrice@his.com (Edward Rice) writes: >A fault-generating instruction (MME on the G-600 series, SVC on the IBM >360, etc.) is essentially an illegal instruction that has been designed >into the machine to be specially treated -- a special interrupt/fault >vector address is provided, etc. But the behavior is basically the same as >executing an illegal op-code. [...] > But there's no overwhelming reason that TSS couldn't, if DRL >didn't exist, have used a zero opcode (which was non-executable) as its >opcode for requests. Using an opcode not defined in the hardware specs for this purpose could be an invitation to later trouble, as some S/360 programmers discovered when previously undefined S/360 opcodes became defined in the S/370 architecture. The same problem could occur with using any normally irrelevent hardware option; I was bit by this because I used the ASCII bit in the PSW as a flag for a hardware-level monitoring device, and one of the operators inadvertently started the program on one of the early S/370 systems (that bit was redefined in the S/370 to switch between basic (real) and extended (virtual) modes). Thankfully by the time the S/370 arrived the hardware monitor was gone and the program had been retired. The VM/370 design ran along the edge of this problem, by conscripting the DIAGNOSE command as the communications link between the code running in a virtual machine and the VM supervisor. (Remember that under VM, the entire memory address space was owned by the user, and so no normal program interface could be used for this purpose.) The DIAGNOSE instruction caused a privileged-operation interrupt in the real hardware because it is valid only in supervisor mode, and all users under VM run in user (unprivileged) mode. Of course, one had to be careful to avoid accidentally issuing a DIAGNOSE from within the VM kernel itself since it ran in real supervisor mode -- and the results of accidentally issuing a DIAGNOSE could be quite messy. > > Were IBM's Selectric typewriter terminals available for it? >They had not yet been invented when the 7094 design was finished. ...which doesn't mean that they weren't used with a 709x later. I'm not at all sure that I agree with this chronology in any case, but I don't have any documentation to support either position. Anyone? Joe Morris ###### Sender: lynn@LYNNPC Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> <7ohogm$5r3$1@top.mitre.org> Reply-To: Anne & Lynn Wheeler From: Anne & Lynn Wheeler Message-ID: Organization: Wheeler&Wheeler Lines: 56 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Aug 1999 18:12:43 GMT NNTP-Posting-Host: 209.63.28.138 X-Complaints-To: support@adcomsys.net X-Trace: news-west.eli.net 934049563 209.63.28.138 (Sat, 07 Aug 1999 12:12:43 MDT) NNTP-Posting-Date: Sat, 07 Aug 1999 12:12:43 MDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newsfeed.stanford.edu!logbridge.uoregon.edu!xmission!news.inconnect.com!news-west.eli.net!not-for-mail one of the reasons that diagnose was chosen ... was that it was a supervisor instruction and the architecture book defined it as machine dependent ... i.e. it was unlikely to be used by any ... but very special purpose software ... and we could claim that a "virtual" machine was a specific kind of machine ... and therefor we were within the architecture book's "rules & regulations" when we claimed that a "virtual" machine was a specific kind of machine and had the latitude to define the operation of the diagnose instruction in the "virtual" machine environment. mostly the use of diagnose instruction in CP/67 was to return time information (this was before s/370 which had a store clock instruction). one of the path length profiles that I had done as an undergraduate was in i/o simulation and ccw translation. Since all of CMS's disk I/O was very predictable ... seek/search/tic/read-write, etc. I had implementated an "immediate" x'FF" CCW that would expand into the whole operation; and since CMS's disk supervisor was simulated syncronous ... control wouldn't return to the SIO until the disk I/o was complete ... and would store CC=1, csw stored (i.e. as if it was an immediate CCW I/O operation). The 360 SIO (start I/O) could return cc=0 (operation succesfully started), cc=1 (csw stored, effectively some sort of immediate operation), cc=2 (subchannel busy), cc=3 (device not available). Simulating a cc=1 ... allowed the operation to look immediate, eliminating the necessity for CMS to do a bunch of programming to enter wait state ... and then take a subsequent I/O interrupt. the pathlength stuff I had done for MFT was only partial benefit to the CMS environment ... since CMS had very low priviledge instruction ratio ... except for I/O. The x'FF" CCW cut the ccw translation overhead as well as bunch of tasking, idle PSW loading, and subsequent interrupt simulation, etc. which showed significant improvement in CMS intensive environment. The development group converted this to custom simulation with a diagnose instruction (but effectively the same semantics) ... in part since x'FF" CCW op-code wasn't protected in any way ... but essentially had a sanctioned "charter" based on what was in the rules & regulations set down in the 360/370 architecture red book. rather than repeat ... now have urls http://www.garlic.com/~lynn/94.html#18 http://www.garlic.com/~lynn/94.html#20 http://www.garlic.com/~lynn/94.html#21 http://www.garlic.com/~lynn/94.html#27 -- -- Anne & Lynn Wheeler | lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn ###### Newsgroups: alt.folklore.computers From: ehrice@his.com (Edward Rice) Subject: Re: Early interupts on mainframes Message-ID: Organization: NDS Date: Sat, 07 Aug 1999 18:14:47 -0400 References: <7od7t9$kin@netaxs.com> <37aa51a7.40124388@news.shuswap.net> <37AA6F54.F904FEE3@iedu.org> <37ab4f66.21522337@news.prosurfr.com> NNTP-Posting-Host: pm8-239.his.com Lines: 28 X-Authenticated-User: ehrice Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!tank.news.pipex.net!pipex!remarQ-easT!supernews.com!remarQ.com!news.lightlink.com!news4.his.com!user In article <37ab4f66.21522337@news.prosurfr.com>, jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: > Yes, but a program that isn't running can't execute an SVC instruction or any > other. Instead, transfer of control to a non-running program takes place when a > running program either requests I/O, or is interrupted by a *clock* interrupt. Depending on the OS and the I/O system, there are exceptions to your "can't" statement above. A program could do the following, for instance: set the countdown timer, which will generate a fault when it has counted down to zero and underflows, to a few ticks short of zero, with the address to handle the timer runout provided to the operating system do a hard block, waiting for external conditions to awaken the program At this point, the program is /not/ running, and within a few ticks of the time an interrupt (what I earlier termed a "fault," an internal interrupt) will be taken and cause the program to run. There are other cases, such as starting an I/O and then doing a hard block. ###### From: cjt&trefoil Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Sun, 08 Aug 1999 12:59:27 -0500 Organization: Prodigy Internet http://www.prodigy.com Lines: 26 Message-ID: <37ADC57F.2D9C@prodigy.net> References: <7od7t9$kin@netaxs.com> Reply-To: cheljuba@prodigy.net NNTP-Posting-Host: austb104-15.splitrock.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: newssvr03-int.news.prodigy.com 934135142 2709921 209.253.18.111 (8 Aug 1999 17:59:02 GMT) X-Complaints-To: abuse@prodigy.net NNTP-Posting-Date: 8 Aug 1999 17:59:02 GMT X-Mailer: Mozilla 3.04 (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newscon05!prodigy.com!not-for-mail Edward Rice wrote: > > IBM had some special hardware that let a 7044 and a 7094 share > memory, and the 7044 could talk to terminals or a good array of > peripherals. I know that Yale University ran DCOS to keep their 7094 busy, > for a number of years, and I suspect other universities did also. I'm not > aware of a DCOS application to serve businesses like the bank you mention, > but I think it could physically have been done. The cost effectiveness is a > different issue -- in the 7094 era, the cost of putting a terminal online > to an IBM mainframe was terribly high, while in the 360 era that cost > dropped by probably two orders of magnitude. That's another reason I'd > expect an online banking system to be a few years later -- banks required > reliability and in the 1965-66 period, the 360 wasn't reliable. While the cost of adding terminals dropped, it was still fairly high in absolute terms. At the University of Michigan, a DEC minicomputer was put into service in the late 60's as a "Data Concentrator" to help handle I/O, as I recall. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> <7ohogm$5r3$1@top.mitre.org> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 08 Aug 1999 12:54:33 -0700 Message-ID: Lines: 12 X-Newsreader: Gnus v5.5/Emacs 20.3 NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 8 Aug 1999 13:12:03 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!news.sgi.com!news.spies.com!ruckus.brouhaha.com > > > Were IBM's Selectric typewriter terminals available for it? > >They had not yet been invented when the 7094 design was finished. jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes: > ...which doesn't mean that they weren't used with a 709x later. I'm > not at all sure that I agree with this chronology in any case, but I > don't have any documentation to support either position. Anyone? As I understand it, the first I/O Selectric was shipped with the Los Alamos STRETCH in 1961, but that they weren't offered as a standard product for use with other systems until at least a year later. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> <37ab4da7.21075502@news.prosurfr.com> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 08 Aug 1999 13:01:23 -0700 Message-ID: X-Newsreader: Gnus v5.5/Emacs 20.3 NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 8 Aug 1999 13:18:54 -0800, ruckus.brouhaha.com Lines: 21 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newscore.gigabell.net!newscore.ipf.de!unlisys!news.snafu.de!newsfeed.nacamar.de!dispose.news.demon.net!demon!nntp.primenet.com!nntp.gctr.net!enews.sgi.com!news.sgi.com!news.spies.com!ruckus.brouhaha.com > This came up before, but I remain confused on the concept of a > computer "interupt" and how it worked on older machines. First used on the IBM STRETCH computer. Described in the book _Planning a Computer System: Project STRETCH_, edited by Werner Buchholz, one of the designers. A hardware device that needs service, because it has data ready to be read, or needs more data to store or transmit, or has an exceptional condition (such as a card jam or a head crash) asserts an interrupt. Assuming that software hasn't disabled the interrupt, it causes the processor to execute one or more instructions from the "interrupt handler", out of the normal program sequence. In the STRETCH (and similarly in some later processors such as the DEC PDP-6, PDP-10, and some modern DSP chips including the Motorola 56K family), for each possible interrupt there is a specific memory location that contains a single-instruction handler. However, that single instruction may be a subroutine call, in which case the entire subroutine is executed before control is returned to the suspended program. ###### From: jmfbahciv@aol.com Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Mon, 09 Aug 99 11:21:05 GMT Organization: UltraNet Communications, Inc. Lines: 53 Message-ID: <7omkm6$h20$1@autumn.news.rcn.net> References: <37AA6F54.F904FEE3@iedu.org> <7ofegg$udh$1@uwm.edu> <7ohklo$raf$2@news.igs.net> X-Trace: AyZu1yFwdayOvZ27pFu7uHDm5hvtMU+0ACb6m61Q+34= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 9 Aug 1999 13:22:14 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!d14 In article <7ohklo$raf$2@news.igs.net>, "donald tees" wrote: > >John G Dobnick wrote in message <7ofegg$udh$1@uwm.edu>... >>From article <37AA6F54.F904FEE3@iedu.org>, by Morris Dovey >: >>> >>> Classical misunderstanding. On /some/ systems applications could execute >an >>> instruction which would generate an interrupt signal (like the SVC >>> instruction on the S/360 or the RST instruction on the Intel 8080) once >the >>> interrupt had been generated, it was typically handled (by the hardware) >>> just as if it had been generated by an I/O device. One of the common uses >>> for such program-generated interrupts was to request kernel/supervisor >>> services without having to know the address of the service routine. >> >> Also, certain "exceptional conditions" (arithmetic overflow, divide >> by zero, address out of limits, memory-protect violation, etc.) are >> implemented as interrupts on some systems. (These are sometimes >> called "traps" by some manufacturers, "exceptions" by others, and >> "interrupts" by still others.) They are, however, still program >> generated. >> >> And then there are "hardware exceptions", as in memory parity/fault >> detection, CPU internal errors detection, etc. These also can >> generate "fault interrupts", and are _not_ I/O or program related. >> Exactly _what_ is detected and reported is highly implementation >> dependent. >> >> [Does that just about cover everything?] > > >Coffee breaks? >;<) Those weren't on-line interrupts. The HW-10* in our machine room was close to the computers but not connected to them. *HW-10: The name given to the bubbler that also had a hot water generator so TW and JMF could make coffee. Hot water availability was something that made them very, very happy for very little money. A coffee maker hot water source was not acceptable because the guys would forget and burn pots or they couldn't figure out how to make hot water with those makers. /BAH Subtract a hundred and four for e-mail. ###### From: prs@gol.com (Peter Stephenson) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Message-ID: <37b6cb0e.8438281@nnrp.gol.com> References: <7od7t9$kin@netaxs.com> X-Newsreader: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 7 Date: Mon, 09 Aug 1999 13:01:21 GMT NNTP-Posting-Host: 203.216.42.40 X-Complaints-To: abuse@gol.com X-Trace: nnrp.gol.com 934203681 203.216.42.40 (Mon, 09 Aug 1999 22:01:21 JST) NNTP-Posting-Date: Mon, 09 Aug 1999 22:01:21 JST Organization: Global Online Japan Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!bignews.mediaways.net!newsfeed.germany.net!newsfeed.nyu.edu!newsfeed.gol.com!203.216.70.8.MISMATCH!POSTED.nnrp.gol.com!not-for-mail On Sat, 07 Aug 1999 04:42:02 -0400, ehrice@his.com (Edward Rice) wrote: As I recall, the 80xx chip loaded the PC with an address 8*interupt number (where there was typically a jump to the ISR). Do the current Intel chips still do similar? (I'm fully expecting the follow up message to just say RTFM). ###### From: bernie@fantasyfarm.com (Bernie Cosell) Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Mon, 09 Aug 1999 17:40:11 GMT Organization: Fantasy Farm Fibers Lines: 19 Message-ID: <37b30e37.160037695@news.remarq.com> References: <7od7t9$kin@netaxs.com> <37ab4da7.21075502@news.prosurfr.com> X-Complaints-To: newsabuse@supernews.com X-Newsreader: Forte Agent 1.5/32.452 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!nntp-relay.ihug.net!ihug.co.nz!remarQ60!rQdQ!supernews.com!remarQ.com!news.supernews.com!not-for-mail Eric Smith wrote: } > This came up before, but I remain confused on the concept of a } > computer "interupt" and how it worked on older machines. } } First used on the IBM STRETCH computer. Described in the book } _Planning a Computer System: Project STRETCH_, edited by Werner Buchholz, } one of the designers. What was the date on that? The PDP-1 had a quite good interrupt system [dating from 1961 or 1962]. I didn't think the stretch [the 7030] was that old... It was called 'Sequence break' in the PDP-1, but it was the same thing. Anyone know if the TX-0 or -2 had something like that even earlier? /Bernie\ -- Bernie Cosell Fantasy Farm Fibers bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- ###### From: John Ahlstrom Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Mon, 09 Aug 1999 15:10:12 -0700 Organization: Cisco Systems Lines: 9 Message-ID: <37AF51C4.2FC82957@cisco.com> References: <7od7t9$kin@netaxs.com> <37ab4da7.21075502@news.prosurfr.com> <37b30e37.160037695@news.remarq.com> X-Complaints-To: newsabuse@supernews.com X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cache-Post-Path: sj-nntpcache-1.cisco.com!unknown@dhcp-vm21-85-213.cisco.com X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newsfeed.stanford.edu!remarQ73!rQdQ!supernews.com!remarQ.com!corp.supernews.com!not-for-mail I have heard without attribution that the Univac 1103 was the first computer to have an (IO?) interrupt. JKA -- Any system of neural organization complex enough to generate the axioms of arithmetic is too complex to be understood by itself. Kaekel's Conjecture ###### From: "Don Chiasson" Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes Date: Mon, 9 Aug 1999 18:41:58 -0400 Organization: UUNET Canada News Transport Lines: 21 Message-ID: <7onn4d$cti$1@nntp3.uunet.ca> References: <7od7t9$kin@netaxs.com> NNTP-Posting-Host: 209.167.85.20 X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newspeer.monmouth.com!cyclone.bc.net!news.uunet.ca!not-for-mail Edward Rice wrote in message ... >.......... > >Uh... polling is generally very inefficient and is avoided whenever >possible. An interrupt system (including faults) is designed into a system >to /avoid/ polling, not to perform more efficient polling. > There can be other problems. In real time systems driven by hardware interrupts if a device goes awry and generates a contunuous stream of interrupts, the whole system may hang because no program can get any processor time. Alternate scenario: interrupts are often handled by pushing machine status on a stack. If the interrupt rate is high or errors happen with errors the stack may overflow and crash the system. With a polling system, the program would test the device, note that it is not working and then go on to the next device. In a benign world these things do not happen. Don ###### Sender: lynn@LYNNPC Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> <7onn4d$cti$1@nntp3.uunet.ca> Reply-To: Anne & Lynn Wheeler From: Anne & Lynn Wheeler Message-ID: Organization: Wheeler&Wheeler Lines: 59 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 02:52:56 GMT NNTP-Posting-Host: 209.63.28.138 X-Complaints-To: support@adcomsys.net X-Trace: news-west.eli.net 934253576 209.63.28.138 (Mon, 09 Aug 1999 20:52:56 MDT) NNTP-Posting-Date: Mon, 09 Aug 1999 20:52:56 MDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newsfeed.stanford.edu!logbridge.uoregon.edu!xmission!news.inconnect.com!news-west.eli.net!not-for-mail "Don Chiasson" writes: > Edward Rice wrote in message ... > >.......... > > > >Uh... polling is generally very inefficient and is avoided whenever > >possible. An interrupt system (including faults) is designed into a system > >to /avoid/ polling, not to perform more efficient polling. > > > There can be other problems. In real time systems driven by > hardware interrupts if a device goes awry and generates a contunuous > stream of interrupts, the whole system may hang because no program > can get any processor time. Alternate scenario: interrupts are often > handled by pushing machine status on a stack. If the interrupt rate is > high or errors happen with errors the stack may overflow and crash the > system. > With a polling system, the program would test the device, note that it > is not working and then go on to the next device. In a benign world these > things do not happen. > Don > > > actually I did a variation on this for 370 cache machines in the mid-70s. critical sections of the kernel ran disabled for all interrupts. prior to selecting some non-disabled work for execution I inserted a pair of instructions that enabled/disabled for interrups. This eliminated the uneccesary overhead of selecting and dequeueing some piece of work when there was interrupts pending that required other work. recognizing that high rate of interrupts did terrible things to cache locality ... would monitor the I/O interrupt rate and if it exceeded some threshold for the machine ... the code dynamically switched normal workload from being enabled for all interrupts to being enabled for interrupts except I/O (and scheduled a timer event interrupt). strategy that some I/O interrupts would be delayed for a small interval (than they would have been if normal workload ran enabled for all interrupts) ... and then the system would accept all pending I/O interrupts effectively in a batch. This would only kick-in when interrupts exceeded a threshold ... where the batch processing actually improved both the thruput of I/O interrupt handling as well as thruput of the workload processing (by improving the cache hit characteristics of both). this was separate from the work done to "bullet-proof" I/O supervisor from things like hot interrupts as well as lost interrupt ... i.e. http://www.garlic.com/~lynn/95.html#3 http://www.garlic.com/~lynn/99.html#31 -- -- Anne & Lynn Wheeler | lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.folklore.computers Subject: Re: Early interupts on mainframes References: <7od7t9$kin@netaxs.com> <37ab4da7.21075502@news.prosurfr.com> <37b30e37.160037695@news.remarq.com> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 10 Aug 1999 12:57:16 -0700 Message-ID: Lines: 20 X-Newsreader: Gnus v5.5/Emacs 20.3 NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 10 Aug 1999 13:15:35 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!europa.netcrusader.net!128.32.206.55!newsfeed.berkeley.edu!enews.sgi.com!news.sgi.com!news.spies.com!ruckus.brouhaha.com I wrote about the history of interrupts: > First used on the IBM STRETCH computer. Described in the book > _Planning a Computer System: Project STRETCH_, edited by Werner Buchholz, > one of the designers. bernie@fantasyfarm.com (Bernie Cosell) writes: > What was the date on that? The PDP-1 had a quite good interrupt system > [dating from 1961 or 1962]. I didn't think the stretch [the 7030] was that > old... It was called 'Sequence break' in the PDP-1, but it was the same > thing. Anyone know if the TX-0 or -2 had something like that even earlier? Customer acceptance of the first STRETCH machine (not called a 7030) occurred in May 1961. However, STRETCH was in design and development for a long time, and AFAIK the earliest publication describing interrupts was a paper on STRETCH published in 1959. It's entirely possible that other machines having interrupts may have been designed later but shipped earlier. When was the first customer shipment of the PDP-1?