From: Hans B Pufal Newsgroups: alt.sys.pdp10 Subject: Help understanding interrupt processing Date: Tue, 30 Jan 2001 05:58:49 +0100 Organization: Wanadoo, l'internet avec France Telecom Lines: 85 Message-ID: <3A764A09.8FEE136B@digiweb.com> NNTP-Posting-Host: agrenoble-101-2-1-165.abo.wanadoo.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: wanadoo.fr 980831049 20875 193.251.69.165 (30 Jan 2001 05:04:09 GMT) X-Complaints-To: abuse@wanadoo.fr NNTP-Posting-Date: 30 Jan 2001 05:04:09 GMT X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!surfnet.nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!news.tele.dk!195.25.12.36!oleane.net!oleane!wanadoo.fr!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2791 Hi everyone, As you know I am working on Daniel Seagraves KL emulator, anyone is welcome to join in, the water is nice and warm. We need implementations of the floating point and string handlng instructions - any volounteers? I have a problem understanding the proper execution with one of the tests in DFKAA I have snipped the test out of the DFKAA.SEQ file, the line number is 47212 and the test starts in memory at address 64022. ;TEST THAT AOSE DOES NOT DISMISS INTERRUPTS, OR SKIP WHEN EXECUTED AS ;AN INTERRUPT INSTRUCTION. CLRBTH^ CLRAPR CLRPI^ HALTPI ;FILL INTERRUPT LOCATIONS WITH HALTS MOVE [AOSE 0] ;PI TRAP INSTRUCTION MOVEM Y ;INTO TRAP LOCATION MOVE [JSP 1,..0130] ;SECOND TRAP INSTRUCTION MOVEM Y+1 ;INTO SECOND PI INSTRUCTION MOVEI 1 ;SET AC TO NON ZERO CONO PI,REQSET!PION!CHNON!X ;REQUEST INTERRUPT ON CH X ;IF WE FALL THROUGH THEN THE INTERRUPT WAS DISMISSED ; WHEN THE AOS FAILED WATINT^ MOVEI 13,1000 ;SET UP LOOP OF TEN TO WAIT FOR INT. SOJG 13,. ;AND WAIT^ STOP^ HALT .+1 ;INSTRUCTION FAILED REPLACE JRST .+1 ;WITH JRST BACK^ ..0130: CLRBTH^ CLRAPR CLRPI^ CAIE 2 ;ONLY ONE AOSE PREFORMED? STOP^ HALT .+1 ;INSTRUCTION FAILED REPLACE JRST .+1 ;WITH JRST BACK^ OK, I think I understand that when an AOSE (or any other skip instruction) is executed as an interrupt instruction then the PC is not altered under any circumstances i.e. a skip can never happen. My emulator takes an interrupt, and executes the AOSE instruction, no skip happens anyway because the value in the accumulator starts at 1 and is incremented to 2. After the execution of the AOSE as an interrupt instruction, the emulator returns to the interrupted code sequence, the SOJG instruction which eventually drops out to the HALT. It seems like the test wants to execute the jump to ..130 after the AOSE instruction but I do not understand the mechanism involved. It is the comment about AOSE not dimissing the interrupt that confuses me. What should happen after the AOSE if the interrupt is not dismissed? Regards, -- Hans B Pufal ###### Message-ID: <3A7D0848.29678A56@mail.bcpl.net> From: Ken McMonigal X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 138 Date: Sun, 04 Feb 2001 02:44:08 -0500 NNTP-Posting-Host: 208.242.126.48 X-Complaints-To: abuse@bcpl.net X-Trace: news.abs.net 981272472 208.242.126.48 (Sun, 04 Feb 2001 02:41:12 EST) NNTP-Posting-Date: Sun, 04 Feb 2001 02:41:12 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!surfnet.nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!news.abs.net!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2856 "Alan H. Martin" wrote: > > Hans B Pufal wrote: > > > I have a problem understanding the proper execution with one of the > > tests in DFKAA > > *KL* emulator, eh? > > I *think* the below means that the KI ascribed fancy semantics to AOSE > which the KL abandoned, and I guess the > > " > DECsystem-10 > DECSYSTEM-20 > Processor Reference Manual > AA-H391A-TK > > July 1980 > > ... > CHAPTER 3 > KL10 SYSTEM OPERATIONS > ... > Interrupt Instructions. An instruction executed in response to an > > > > OK, I think I understand that when an AOSE (or any other skip > > instruction) is executed > > as an interrupt instruction then the PC is not altered under any > > circumstances i.e. a skip can never happen. > > > > My emulator takes an interrupt, and executes the AOSE instruction, no > > skip happens anyway because the value in the accumulator starts at 1 and > > is incremented to 2. After the execution of the AOSE as an interrupt > > instruction, the emulator returns to the interrupted code sequence, the > > SOJG instruction which eventually drops out to the HALT. > > > > It seems like the test wants to execute the jump to ..130 after the AOSE > > instruction but I do not understand the mechanism involved. It is the > > comment about AOSE not dimissing the interrupt that confuses me. What > > should happen after the AOSE if the interrupt is not dismissed? > > On a KI, executing an AOSE (whose EA points to a word that does not > contain -1) would indeed just AOS EA, dismiss the interrupt, and > resume the interrupted code. On a KA, the same situation would AOS EA, > and resume the interrupted code *as if it were an interrupt routine* > (I hadn't realized that, either). On a KL, the effect of such a > situation is undefined, but apparently the author of the diagnostics > expected the KL to not dismiss the interrupt and fall into the JSP. > /AHM > -- > Alan Howard Martin AMartin@MA.UltraNet.Com The above is very informative. However, since I never programmed in assembler on the -10, the only thing I could do was try pulling out some documentation on the -10 & compare its functionality with the machines I was more familiar with. One text I referenced was "Multiprocessors & Parallel Processors", editted by Enslow of COMTRE Corp. The brief description (6 pages) touched on the modes & submodes of the KA-10 vs. the KI-10. As well, it mentioned that the KI-10 had instruction look-ahead. My thoughts/questions are addressed to anyone who wishes to reply & are only meant to get some juices flowing & help with my understanding of the project. I apologize in advance for the rather long post. Questions are: 1) Will instruction look-ahead affect the emulator? As I ask this, I am working on trying to find available on-line docs (for the -10) as well as my on-disk files on interrupts/exceptions/pipelines for non -10 systems. Are the instructions that are being sent to the emulator assumed to be executed without invoking look-ahead? And how does/did the hardware handle it? Is an interrupt generated? Since "interrupt" is generally used to describe asynchronous I/O requests, this would seem to be more like an exception in a x86 when an arithmetic error occurs. Did the KI-10 have an instruction pipeline & will flushing of it be necessary? 2) As I have never written an emulator, I was wondering how true to the initial product the user is expecting it to be? When one uses an in-circuit emulator with a host & target, there is typically no expectation of real-time interaction, partly because both machines are typically similar. There is a lot of overhead involved. But because the host (PC clone) is so much faster than the emulated target (the -10) due to current technology, that consideration might be eliminated. However, IMHO, it seems that the emulation is dependent on both the hardware platform as well as the software (OS & language). Will the final Unix/PC clone run like the other emulations that are mentioned in a -10 website (Solaris mentioned)? I was wondering whether the fact that Unix/Linux/W98 are not true "hard real-time" OS'es will affect the emulation. I mention that because I have seen UNIX & Linux products with extensions to provide real-time control. And theoretically, Windows NT is supposed to be real-time, but I was under the impression that it had some constructs but did not again provide "hard real-time". For a discussion of Linux hard real-time, see: http://www.lineo.com/file_index/w/white_papers/comparing.html (I have no connection with them of any kind.) Does any of this apply or am I off-base? Should we just consider the fact that Mr. Seagraves' emulator has gotten far enough in emulation of a working system that it proves that I am worrying about nothing? 3) It seems like the initial phase of the emulator will have very controlled execution of programs as well as I/O data rates. Then it would seem that random testing by a computer-sim of jobs & batches would be done. Or it could possibly be a Telnet experiment with people in this newsgroups testing it all at the same time. This would result in a second round of debugging to resolve dynamic problems. But maybe I'm totally off the mark on this, as well. TIA for your help & comments, Ken P.S> (proud owner of TENEX USERS GUIDE - 1st Revision - January 1973) P.P.S. Above GUIDE was compiled by Leavitt, Strollo, & Shapiro. Were they ex-DEC people? ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Mon, 05 Feb 01 09:04:38 GMT Organization: UltraNet Communications, Inc. Lines: 29 Message-ID: <95lun5$204$1@bob.news.rcn.net> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> X-Trace: UmFuZG9tSVZKbuXVaGa6QewItsrPT0hySTm6K0xoduEM4mk+cqIvvspwqaKWdxJM X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 5 Feb 2001 10:19:17 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!isdnet!diablo.theplanet.net!newsfeed.icl.net!netnews.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!207-172-216-246 Xref: chonsp.franklin.ch alt.sys.pdp10:2875 In article <95lkti$15d3$1@nntp1.ba.best.com>, inwap@best.com (Joe Smith) wrote: >In article <3A7D0848.29678A56@mail.bcpl.net>, >Ken McMonigal wrote: >>Questions are: >> >>1) Will instruction look-ahead affect the emulator? As I ask this, I >>am working on trying to find available on-line docs (for the -10) as >>well as my on-disk files on interrupts/exceptions/pipelines for >>non -10 systems. How does/did the hardware handle it? > >The PDP-10 (as sold by DEC) had no pipeline. >Instructions were executed one at a time. Per CPU. In a master/slave or SMP configuration, each CPU could execute instructions one at a time. Also, a CPU could "interrupt" another CPU via the doorbell in SMP. I'm not sure what happened in a master/slave configuration. Since all I/O was done via CPU0, aka the master, I think that a job running on CPU1 that needed I/O done would be put on a list that CPU0 would look at for I/O (but I can't think what that was called). /BAH Subtract a hundred and four for e-mail. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Tue, 06 Feb 01 08:56:18 GMT Organization: UltraNet Communications, Inc. Lines: 45 Message-ID: <95oijq$3nc$1@bob.news.rcn.net> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A7EAB71.58EC9F5A@mail.bcpl.net> <3A7F3031.EC5A10F8@prescienttech.com> X-Trace: UmFuZG9tSVarVdYYTLKsrVbaNxtHflA/5tWMbaYe8+lI3S6pkKxw3U1OzHa7MPzZ X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 6 Feb 2001 10:11:06 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.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xfer13.netnews.com!netnews.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!207-172-245-253 Xref: chonsp.franklin.ch alt.sys.pdp10:2879 In article <3A7F3031.EC5A10F8@prescienttech.com>, "Carl R. Friend" wrote: >Ken McMonigal wrote: >> >> 2) The accompanying structural chart showed both processors hanging >> off the main bus with memory and I/O. In addition, >> card reader/printer/tapes/terminals hung off a back bus of one of the >> processors. The other processor had no back bus. >> Unfortunately, the author did not identify the master & slave on the >> chart, but I think that Barb's comments clarify this point. > > This is "classic" master/slave, not SMP. In master/slave, the CPU >with the I/O bus (for external peripherals other than the RTC) was the >master; the one with only a memory interface was the slave (and there >could be more than one). > > The problem with master/slave was that the slave ran fine on any >given job so long as I/O calls weren't made; those needed the >attention of the master. So the scheme didn't scale well for real- >world jobs which usually do a fair amount of I/O. They did work OK >for heavily compute-bound tasks, but those tend to be the exception >rather than the rule. Right. And the recommended command for those jobs that were compute-bound was to say SET CPU ONLY CPU1 but the user had to be very careful that the job really was CPU bound. A lot of jobs only seemed CPU bound when we shipped a newer faster disk drive/controller. > > In SMP, both (or more) CPUs have I/O connections; this, of course, >leads to some interesting scheduling issues (what disk cylinder is the >drive on _now_ and did it change since I last controlled it?) and >some equally interesting process scheduling problems. The monitor wouldn't have that problem if the device driver and controller code was reentrant :-). Remember there was only one copy of the monitor in core. I do remember that TW had a bitch of a time reworking his code to be reentrant but it got done. /BAH Subtract a hundred and four for e-mail. ###### From: inwap@best.com (Joe Smith) Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: 5 Feb 2001 07:32:02 GMT Organization: Chez Inwap Lines: 42 Message-ID: <95lkti$15d3$1@nntp1.ba.best.com> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> NNTP-Posting-Host: shell3.ba.best.com X-Trace: nntp1.ba.best.com 981358322 38307 206.184.139.134 (5 Feb 2001 07:32:02 GMT) X-Complaints-To: abuse@best.com NNTP-Posting-Date: 5 Feb 2001 07:32:02 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!rcn!news2.best.com!nntp1.ba.best.com!inwap Xref: chonsp.franklin.ch alt.sys.pdp10:2880 In article <3A7D0848.29678A56@mail.bcpl.net>, Ken McMonigal wrote: >Questions are: > >1) Will instruction look-ahead affect the emulator? As I ask this, I >am working on trying to find available on-line docs (for the -10) as >well as my on-disk files on interrupts/exceptions/pipelines for >non -10 systems. How does/did the hardware handle it? The PDP-10 (as sold by DEC) had no pipeline. Instructions were executed one at a time. Concepts like conditional execution and branch prediction are totally foreign. On the KA, the fastest way to search for a string in a text buffer was to use self-modifying code. If the inner loop could be implemented in fewer than 12 instructions, the code would be loaded into the accumulators ("Fast Memory") and the program would jump into the accumulators (where the Program Counter has a value between 0 and 17 inclusive). > Are the instructions that are being sent to the >emulator assumed to be executed without invoking look-ahead? In order to run with the existing TOPS-10 or TOPS-20 Monitors, it would have to be done in such as way that the page-fault handler and interrupt handler would not be able to see any affects of look-ahead. >Since "interrupt" is generally used to describe asynchronous >I/O requests, this would seem to be more like an exception >in a x86 when an arithmetic error occurs. Did the KI-10 have an >instruction pipeline & will flushing of it be necessary? No pipeline. No flushing. >2) As I have never written an emulator, I was wondering how true >to the initial product the user is expecting it to be? 100%. Should be able to run any and all of the user-mode diagnostics and most of the kernel-mode ones. -Joe -- See http://www.inwap.com/ for PDP-10 and "ReBoot" pages. ###### From: Mark Garrett Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Organization: Garetech Computer Solutions Lines: 23 Message-ID: References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 05 Feb 2001 09:28:48 GMT NNTP-Posting-Host: 144.132.244.163 X-Complaints-To: news@bigpond.net.au X-Trace: news-server.bigpond.net.au 981365328 144.132.244.163 (Mon, 05 Feb 2001 20:28:48 EST) NNTP-Posting-Date: Mon, 05 Feb 2001 20:28:48 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!kanja.arnes.si!news-hub.siol.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!intgwpad.nntp.telstra.net!news-server.bigpond.net.au!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2883 in article 95lkti$15d3$1@nntp1.ba.best.com, Joe Smith at inwap@best.com wrote on 05/02/2001 18:32: > In article <3A7D0848.29678A56@mail.bcpl.net>, > Ken McMonigal wrote: >> Questions are: >> >> 1) Will instruction look-ahead affect the emulator? As I ask this, I >> am working on trying to find available on-line docs (for the -10) as >> well as my on-disk files on interrupts/exceptions/pipelines for >> non -10 systems. How does/did the hardware handle it? > > The PDP-10 (as sold by DEC) had no pipeline. > Instructions were executed one at a time. > Concepts like conditional execution and branch prediction are totally foreign. The closest a KL got to modern processor tricks was memory pre-fetches. JUPITER that got cancelled was meant to have more than one micro engine and pipelined instruction fetch and execute. Some other non-DEC KL equivalents IIRC did have pipelines there name escapes me ATM. Cheers Mark ;) ###### Message-ID: <3A7EA309.7B128B2@mail.bcpl.net> From: Ken McMonigal X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 66 Date: Mon, 05 Feb 2001 07:56:41 -0500 NNTP-Posting-Host: 207.19.142.56 X-Complaints-To: abuse@bcpl.net X-Trace: news.abs.net 981377624 207.19.142.56 (Mon, 05 Feb 2001 07:53:44 EST) NNTP-Posting-Date: Mon, 05 Feb 2001 07:53:44 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!Amsterdam.Infonet!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!news.abs.net!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2872 Joe Smith wrote: > > In article <3A7D0848.29678A56@mail.bcpl.net>, > Ken McMonigal wrote: > >Questions are: > > > >1) Will instruction look-ahead affect the emulator? As I ask this, I > >am working on trying to find available on-line docs (for the -10) as > >well as my on-disk files on interrupts/exceptions/pipelines for > >non -10 systems. How does/did the hardware handle it? > > The PDP-10 (as sold by DEC) had no pipeline. > Instructions were executed one at a time. > Concepts like conditional execution and branch prediction are totally foreign. > > On the KA, the fastest way to search for a string in a text buffer was > to use self-modifying code. If the inner loop could be implemented in > fewer than 12 instructions, the code would be loaded into the accumulators > ("Fast Memory") and the program would jump into the accumulators (where > the Program Counter has a value between 0 and 17 inclusive). > > > Are the instructions that are being sent to the > >emulator assumed to be executed without invoking look-ahead? > > In order to run with the existing TOPS-10 or TOPS-20 Monitors, it would > have to be done in such as way that the page-fault handler and interrupt > handler would not be able to see any affects of look-ahead. > > >Since "interrupt" is generally used to describe asynchronous > >I/O requests, this would seem to be more like an exception > >in a x86 when an arithmetic error occurs. Did the KI-10 have an > >instruction pipeline & will flushing of it be necessary? > > No pipeline. No flushing. > > >2) As I have never written an emulator, I was wondering how true > >to the initial product the user is expecting it to be? > > 100%. Should be able to run any and all of the user-mode diagnostics > and most of the kernel-mode ones. > -Joe > > -- > See http://www.inwap.com/ for PDP-10 and "ReBoot" pages. Thanks for the info, Joe, as well as taking the time to wander through a rather long post. As always, you are very informative. I had not seen that technique of running in the accumulators before & think it is probably worthy of posting in alt.folklore.comp. Of course, today, with structured programming, self-modifying code is frowned upon. Also, with the newer architectures, it probably can cause ram cache misses and slow things up. I'm thinking of going through my old Univac-1108 assembler stuff to see if any equivalent technique as you described could occur. At our company, around 1974-1983, we used our own version of the the HP-2100 (micro-coded). We employed self-modifying code, although very rarely. One example that comes to mind was a shift or rotate command to properly normalize numbers for subsequent multiplication to ensure that overflows didn't occur. Of course, self-modifying code made for really fun debugging sessions! :) ###### Message-ID: <3A7EAB71.58EC9F5A@mail.bcpl.net> From: Ken McMonigal X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 53 Date: Mon, 05 Feb 2001 08:32:33 -0500 NNTP-Posting-Host: 207.19.142.56 X-Complaints-To: abuse@bcpl.net X-Trace: news.abs.net 981379775 207.19.142.56 (Mon, 05 Feb 2001 08:29:35 EST) NNTP-Posting-Date: Mon, 05 Feb 2001 08:29:35 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.abs.net!news.abs.net!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2874 jmfbahciv@aol.com wrote: > > In article <95lkti$15d3$1@nntp1.ba.best.com>, > inwap@best.com (Joe Smith) wrote: > >In article <3A7D0848.29678A56@mail.bcpl.net>, > >Ken McMonigal wrote: > >>Questions are: > >> > >>1) Will instruction look-ahead affect the emulator? As I ask this, I > >>am working on trying to find available on-line docs (for the -10) as > >>well as my on-disk files on interrupts/exceptions/pipelines for > >>non -10 systems. How does/did the hardware handle it? > > > >The PDP-10 (as sold by DEC) had no pipeline. > >Instructions were executed one at a time. > > Per CPU. In a master/slave or SMP configuration, each > CPU could execute instructions one at a time. > > Also, a CPU could "interrupt" another CPU via the doorbell in > SMP. I'm not sure what happened in a master/slave configuration. > Since all I/O was done via CPU0, aka the master, I think that > a job running on CPU1 that needed I/O done would be put on > a list that CPU0 would look at for I/O (but I can't think > what that was called). > > > > /BAH > > Subtract a hundred and four for e-mail. Again referencing "Multiprocessors & Parallel Processors", editted by Enslow of COMTRE Corp., January 1974, two systems were mention - DECSystem-1055 (KA-10) & DECSystem-1077 (KI-10). Two point: 1) As mentioned in the text, two processors are connected to the same memory & execute the same copy of the operating system. In addition the primary processor has control of all I/O devices & processes all requests to the operating system. 2) The accompanying structural chart showed both processors hanging off the main bus with memory and I/O. In addition, card reader/printer/tapes/terminals hung off a back bus of one of the processors. The other processor had no back bus. Unfortunately, the author did not identify the master & slave on the chart, but I think that Barb's comments clarify this point. Ken ###### From: "Carl R. Friend" Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Mon, 05 Feb 2001 17:58:57 -0500 Organization: as little as possible! Lines: 43 Message-ID: <3A7F3031.EC5A10F8@prescienttech.com> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A7EAB71.58EC9F5A@mail.bcpl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaU6EbWGDzV6IxBzD46KA7nL4PZRdNoSPW8Bn2NBtsgXOVnwE1K9kZW X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 5 Feb 2001 22:58:57 GMT X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.29 i586) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!kanja.arnes.si!news-hub.siol.net!feed.cgocable.net!xfer13.netnews.com!netnews.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2887 Ken McMonigal wrote: > > 2) The accompanying structural chart showed both processors hanging > off the main bus with memory and I/O. In addition, > card reader/printer/tapes/terminals hung off a back bus of one of the > processors. The other processor had no back bus. > Unfortunately, the author did not identify the master & slave on the > chart, but I think that Barb's comments clarify this point. This is "classic" master/slave, not SMP. In master/slave, the CPU with the I/O bus (for external peripherals other than the RTC) was the master; the one with only a memory interface was the slave (and there could be more than one). The problem with master/slave was that the slave ran fine on any given job so long as I/O calls weren't made; those needed the attention of the master. So the scheme didn't scale well for real- world jobs which usually do a fair amount of I/O. They did work OK for heavily compute-bound tasks, but those tend to be the exception rather than the rule. In SMP, both (or more) CPUs have I/O connections; this, of course, leads to some interesting scheduling issues (what disk cylinder is the drive on _now_ and did it change since I last controlled it?) and some equally interesting process scheduling problems. However, SMP yields a much better scalability number than master/slave for real- world applications. On pipelining in the KI-10: the KI did provide very limited facilities for setting up the address of the next instruction on the memory bus, but did not (IIRC) initiate the actual fetch (the iron is, technically, capable of it, but the capacity was never used (how do you do guaranteed-atomic test-and-jumps with a pre- fetch unless you can toss the pre-fetch without losing a beat?). -- +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:crfriend@ma.ultranet.com +---------------------+ | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+ ###### From: "Chuck O'Toole" Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Mon, 5 Feb 2001 19:38:19 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A7EAB71.58EC9F5A@mail.bcpl.net> <3A7F3031.EC5A10F8@prescienttech.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Complaints-To: newsabuse@supernews.com Lines: 68 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!feeder.qis.net!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2888 Carl R. Friend wrote in message news:3A7F3031.EC5A10F8@prescienttech.com... > Ken McMonigal wrote: > > > > 2) The accompanying structural chart showed both processors hanging > > off the main bus with memory and I/O. In addition, > > card reader/printer/tapes/terminals hung off a back bus of one of the > > processors. The other processor had no back bus. > > Unfortunately, the author did not identify the master & slave on the > > chart, but I think that Barb's comments clarify this point. > > This is "classic" master/slave, not SMP. In master/slave, the CPU > with the I/O bus (for external peripherals other than the RTC) was the > master; the one with only a memory interface was the slave (and there > could be more than one). > > The problem with master/slave was that the slave ran fine on any > given job so long as I/O calls weren't made; those needed the > attention of the master. So the scheme didn't scale well for real- > world jobs which usually do a fair amount of I/O. They did work OK > for heavily compute-bound tasks, but those tend to be the exception > rather than the rule. > > In SMP, both (or more) CPUs have I/O connections; this, of course, > leads to some interesting scheduling issues (what disk cylinder is the > drive on _now_ and did it change since I last controlled it?) and > some equally interesting process scheduling problems. However, SMP > yields a much better scalability number than master/slave for real- > world applications. Well, in the -10 case, the cpus had I/O connections but not to the same bus. CPU0 could not control the mass bus controllers on CPU1. The real advantage of SMP over Master/Slave (M/S) was that you didn't need to context switch to the primary/master cpu just because some job issued a MUUO. M/S worked great if you always had some moby compute bound jobs to run on the slave. Otherwise, you ended up with a processor that sat idle because all the jobs were marked as "needs master's attention". The real benefit of SMP was due to how deep into the FILSER or other system modules before you had to switch to the right cpu to "tickle the hardware registers" that started I/O. Buffer management and other things could be done by either CPU with sufficient locks and cache management. The 2nd (and subsequent) I/O bus was just gravy, gave you access to more devices for unit record gear or to dual path disks/tapes. On 1026/1042, 1042 had all the RSX20-F gear, terminals, lpt11, cdr11 while1026 had the traditional LPT1 and DC76. Net (DN20s) were spread around. It wasn't until the BI bus VAXen (8300(scorpio), 8700(nautalis)) did I see the cpus actively sharing the same I/O bus (never played with a 782, obsolete before I got around to VAXen). I think the 9000(aquarius) cpus shared the same I/O bus too. Of course, write-through caches and having the memory logic monitor the bus so cache was automatically invalidated when I/O writes went by helped enormously. /cdo ###### Message-ID: <3A7F488C.D4A27ACE@mail.bcpl.net> From: Ken McMonigal X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A7EAB71.58EC9F5A@mail.bcpl.net> <3A7F3031.EC5A10F8@prescienttech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 93 Date: Mon, 05 Feb 2001 19:42:52 -0500 NNTP-Posting-Host: 208.242.126.176 X-Complaints-To: abuse@bcpl.net X-Trace: news.abs.net 981419994 208.242.126.176 (Mon, 05 Feb 2001 19:39:54 EST) NNTP-Posting-Date: Mon, 05 Feb 2001 19:39:54 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!nntp.abs.net!news.abs.net!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2873 "Carl R. Friend" wrote: > > Ken McMonigal wrote: > > > > 2) The accompanying structural chart showed both processors hanging > > off the main bus with memory and I/O. In addition, > > card reader/printer/tapes/terminals hung off a back bus of one of the > > processors. The other processor had no back bus. > > Unfortunately, the author did not identify the master & slave on the > > chart, but I think that Barb's comments clarify this point. > > This is "classic" master/slave, not SMP. In master/slave, the CPU > with the I/O bus (for external peripherals other than the RTC) was the > master; the one with only a memory interface was the slave (and there > could be more than one). > > The problem with master/slave was that the slave ran fine on any > given job so long as I/O calls weren't made; those needed the > attention of the master. So the scheme didn't scale well for real- > world jobs which usually do a fair amount of I/O. They did work OK > for heavily compute-bound tasks, but those tend to be the exception > rather than the rule. > > In SMP, both (or more) CPUs have I/O connections; this, of course, > leads to some interesting scheduling issues (what disk cylinder is the > drive on _now_ and did it change since I last controlled it?) and > some equally interesting process scheduling problems. However, SMP > yields a much better scalability number than master/slave for real- > world applications. > Thanks for the input on that. As I looked at the chart showing the master with all the disk/drum, a "bell" did ring in my head about the bottlenecks. But when Barb started talking about the "doorbell" in SMP, I found too many interesting thread possibilities (no pun intended) & thought I should try to read up on some PDP-10 specific stuff before I commented further on this area. What I'm really interested in is the applications of the end users. Of course you had universities & commercial sites running time-sharing but I was wondering if the -10 was used in manufacturing, etc.? That might give some clues on the points you made above. > On pipelining in the KI-10: the KI did provide very limited > facilities for setting up the address of the next instruction on > the memory bus, but did not (IIRC) initiate the actual fetch (the > iron is, technically, capable of it, but the capacity was never > used (how do you do guaranteed-atomic test-and-jumps with a pre- > fetch unless you can toss the pre-fetch without losing a beat?). > > -- > +------------------------------------------------+---------------------+ > | Carl Richard Friend (UNIX Sysadmin) | West Boylston | > | Minicomputer Collector / Enthusiast | Massachusetts, USA | > | mailto:crfriend@ma.ultranet.com +---------------------+ > | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | > +------------------------------------------------+---------------------+ So possibly the setting-up was a small speed gain where the address had settled on lines leading to the core & a read pulse had not yet been written? I'm speculating that if it turned out that a different address was needed, then a different address could be written, followed by the read pulse. However, I have no -10 hardware timing diagrams & no (or very faint) experience with core memory. I know that there is a huge -10 schematic out there but I was reluctant to tie down the server. Let's see, as to core memory, there's this flat doughnut with 3 wires... ? Thanks for your helpful comments. Ken P.S. As for this: -- > +------------------------------------------------+---------------------+ > | Carl Richard Friend (UNIX Sysadmin) | West Boylston | > | Minicomputer Collector / Enthusiast | Massachusetts, USA | > | mailto:crfriend@ma.ultranet.com +---------------------+ > | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | > +------------------------------------------------+---------------------+ I really enjoyed your web-site months (?) before this message. And if I understand the right part of above, I'm 30 miles from the big computer/decoder-ring guys. (I put it that way instead of the initials so "special software" wouldn't pick it up. (ha-ha) When I was a kid, we would drive to my grandfather's & go past a NIKE site (next to a retired submarine). ###### From: "Carl R. Friend" Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Mon, 05 Feb 2001 20:45:40 -0500 Organization: as little as possible! Lines: 53 Message-ID: <3A7F5744.16D375B3@prescienttech.com> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A7EAB71.58EC9F5A@mail.bcpl.net> <3A7F3031.EC5A10F8@prescienttech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbRdskJrjy8tFtTtYkuvMJzJUZYI5GllV/8ZfHevbXCQxKxvwXVZTUC X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 6 Feb 2001 01:45:42 GMT X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.29 i586) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!news.idt.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2885 Chuck O'Toole wrote: > > Well, in the -10 case [of SMP], the cpus had I/O connections but not > to the same bus. CPU0 could not control the mass bus controllers on > CPU1. True, given that there was no multi-master arbitration on the I/O bus (which was still PDP-6 style logic). However, the heavy-hitters are usually disk drives, and most of those were dual-ported allowing an RH-10/DF-10 pair on one CPU and a similar pair on another both access to any given disk. > The real advantage of SMP over Master/Slave (M/S) was that you didn't > need to context switch to the primary/master cpu just because some > job issued a MUUO. Exactly. > M/S worked great if you always had some moby compute bound jobs > to run on the slave. Otherwise, you ended up with a processor that > sat idle because all the jobs were marked as "needs master's > attention". We agree precisely on this. > The real benefit of SMP was due to how deep into the FILSER or other > system modules before you had to switch to the right cpu to "tickle > the hardware registers" that started I/O. With dual-ported disks, and channel controllers for each, a non- policy CPU could complete I/O calls without aid from the policy CPU. > Buffer management and other things could be done by either CPU > with sufficient locks and cache management. Cache-management was a completely different ball of wax, and I'm still amazed that they were able to pull it off with multiple CPUs, each with their own private caches! > The 2nd (and subsequent) I/O bus was just gravy, gave you access to > more devices for unit record gear or to dual path disks/tapes. UR gear wasn't a heavy-hitter in any of the apps I saw, and our terminal interface, save for the consoles for each of the CPUs, was done in shared memory. -- +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:crfriend@ma.ultranet.com +---------------------+ | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+ ###### From: "Don Chiasson" Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Mon, 5 Feb 2001 19:05:49 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Complaints-To: newsabuse@supernews.com Lines: 49 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!Amsterdam.Infonet!News.Amsterdam.UnisourceCS!skynet.be!207.126.101.73.MISMATCH!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2899 Joe Smith wrote in message <95lkti$15d3$1@nntp1.ba.best.com>... > >100%. Should be able to run any and all of the > user-mode diagnostics >and most of the kernel-mode ones. Writing comprehensive diagnostics is a difficult task. Consider a multiply instruction. An exhaustive test would be impossible, but the realistic test would cover +/- extremes, zeroes, all ones and all zeroes, probably an assortment of alternating ones and zeroes, error situations (overflow, underflow, illegal or undefined numbers), asymmetry in twos complement signed integer operations, effects of page faults or other traps while instructions are happening, and so on. Repeat for all computer instructions. And so far, I'm only discussing user instructions: no memory mapping, multiple processors, peripheral devices, bus problems, etc. Memory can be vexatious, particularly with memory mapping and cache considerations. Bit patterns were the most common tests: ones, zeroes, alternating ones and zeroes, alternating zeroes and ones, write the address to the location for all memory then read it back. Make the memory diagnostic automatically relocate so all memory is tested. Finally, in the days of core memory, certain patterns caused heating problems so another set of very memory specific tests was needed. OK, the vast majority of problems were not that obscure and could be found by simple tests. Usually it was the hardware designers who needed the powerful diagnostics. But every now and then, something arcane would pop up - often an intermittent - and the techs needed comprehensive tools. Don ###### Message-ID: <3A80B382.1EDE5C17@bellatlantic.net> From: StrangeBrew X-Mailer: Mozilla 4.75 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A7EAB71.58EC9F5A@mail.bcpl.net> <3A7F3031.EC5A10F8@prescienttech.com> <3A7F488C.D4A27ACE@mail.bcpl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 98 Date: Wed, 07 Feb 2001 02:29:14 GMT NNTP-Posting-Host: 138.88.75.166 X-Complaints-To: newsadmin@bellatlantic.net X-Trace: typhoon2.ba-dsg.net 981512954 138.88.75.166 (Tue, 06 Feb 2001 21:29:14 EST) NNTP-Posting-Date: Tue, 06 Feb 2001 21:29:14 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!feed2.onemain.com!feed1.onemain.com!xfer13.netnews.com!netnews.com!newsfeed.skycache.com!Cidera!cyclone2.ba-dsg.net!typhoon2.ba-dsg.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2896 Ken McMonigal wrote: > > "Carl R. Friend" wrote: > > > > Ken McMonigal wrote: > > > > > > 2) The accompanying structural chart showed both processors hanging > > > off the main bus with memory and I/O. In addition, > > > card reader/printer/tapes/terminals hung off a back bus of one of the > > > processors. The other processor had no back bus. > > > Unfortunately, the author did not identify the master & slave on the > > > chart, but I think that Barb's comments clarify this point. > > > > This is "classic" master/slave, not SMP. In master/slave, the CPU > > with the I/O bus (for external peripherals other than the RTC) was the > > master; the one with only a memory interface was the slave (and there > > could be more than one). > > > > The problem with master/slave was that the slave ran fine on any > > given job so long as I/O calls weren't made; those needed the > > attention of the master. So the scheme didn't scale well for real- > > world jobs which usually do a fair amount of I/O. They did work OK > > for heavily compute-bound tasks, but those tend to be the exception > > rather than the rule. > > > > In SMP, both (or more) CPUs have I/O connections; this, of course, > > leads to some interesting scheduling issues (what disk cylinder is the > > drive on _now_ and did it change since I last controlled it?) and > > some equally interesting process scheduling problems. However, SMP > > yields a much better scalability number than master/slave for real- > > world applications. > > > > Thanks for the input on that. As I looked at the chart showing the > master with all the disk/drum, a "bell" did ring in my head about > the bottlenecks. But when Barb started talking about the "doorbell" > in SMP, I found too many interesting thread possibilities > (no pun intended) & thought I should try to read up on some > PDP-10 specific stuff before I commented further on this area. > > What I'm really interested in is the applications of the end users. > Of course you had universities & commercial sites running time-sharing > but I was wondering if the -10 was used in manufacturing, etc.? > That might give some clues on the points you made above. We used the 10 for simulations, CAD, layout - that could be really tough in some of the crap we did - at least some of the stuff I did. Routing the paths for layout was a bear.. > > > On pipelining in the KI-10: the KI did provide very limited > > facilities for setting up the address of the next instruction on > > the memory bus, but did not (IIRC) initiate the actual fetch (the > > iron is, technically, capable of it, but the capacity was never > > used (how do you do guaranteed-atomic test-and-jumps with a pre- > > fetch unless you can toss the pre-fetch without losing a beat?). > > > > -- > > +------------------------------------------------+---------------------+ > > | Carl Richard Friend (UNIX Sysadmin) | West Boylston | > > | Minicomputer Collector / Enthusiast | Massachusetts, USA | > > | mailto:crfriend@ma.ultranet.com +---------------------+ > > | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | > > +------------------------------------------------+---------------------+ > > So possibly the setting-up was a small speed gain where the address had > settled on lines leading to the core & a read pulse had not yet > been written? I'm speculating that if it turned out that a different > address > was needed, then a different address could be written, followed by the > read pulse. > > However, I have no -10 hardware timing diagrams & no (or very > faint) experience with core memory. I know that there is a huge > -10 schematic out there but I was reluctant to tie down the server. > > Let's see, as to core memory, there's this flat doughnut with 3 wires... > ? > > Thanks for your helpful comments. > > Ken > > P.S. As for this: > -- > > +------------------------------------------------+---------------------+ > > | Carl Richard Friend (UNIX Sysadmin) | West Boylston | > > | Minicomputer Collector / Enthusiast | Massachusetts, USA | > > | mailto:crfriend@ma.ultranet.com +---------------------+ > > | http://www.ultranet.com/~crfriend/museum | ICBM: 42:22N 71:47W | > > +------------------------------------------------+---------------------+ > > I really enjoyed your web-site months (?) before this message. > And if I understand the right part of above, I'm 30 miles from the big > computer/decoder-ring guys. (I put it that way instead of the initials > so "special software" wouldn't pick it up. (ha-ha) > > When I was a kid, we would drive to my grandfather's & go past a > NIKE site (next to a retired submarine). ###### Message-ID: <3A80B47C.46E2190A@bellatlantic.net> From: StrangeBrew X-Mailer: Mozilla 4.75 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 18 Date: Wed, 07 Feb 2001 02:33:09 GMT NNTP-Posting-Host: 138.88.75.166 X-Complaints-To: newsadmin@bellatlantic.net X-Trace: typhoon2.ba-dsg.net 981513189 138.88.75.166 (Tue, 06 Feb 2001 21:33:09 EST) NNTP-Posting-Date: Tue, 06 Feb 2001 21:33:09 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!Amsterdam.Infonet!News.Amsterdam.UnisourceCS!skynet.be!newsfeed.skycache.com!Cidera!cyclone1.ba-dsg.net!typhoon2.ba-dsg.net.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.sys.pdp10:2895 Don Chiasson wrote: > <> > OK, the vast majority of problems were not that obscure > and could be found by simple tests. Usually it was the > hardware designers who needed the powerful diagnostics. But > every now and then, something arcane would pop up - often an > intermittent - and the techs needed comprehensive tools. can you say race condition? Yep, go back to KV8i, intermittent counter problem with the point plotting. A bear to find. Counter was set up to feed the next stage, and min/max prop delays were not considered, as it got hotter, it changed its timing but within spec. I won't mention any other ones!! bob > > Don ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Sun, 11 Feb 01 09:23:01 GMT Organization: UltraNet Communications, Inc. Lines: 58 Message-ID: <965q3a$m64$1@bob.news.rcn.net> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A859F62.4E6D22B@MA.UltraNet.Com> X-Trace: UmFuZG9tSVZ9qX4B3exu6a6cQrQ5SBRNZnVQuZ0pDTFWUF0ZKJ5K73ywFKUIA/CD X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 11 Feb 2001 10:38:34 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.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!207-172-216-126 Xref: chonsp.franklin.ch alt.sys.pdp10:2933 In article <3A859F62.4E6D22B@MA.UltraNet.Com>, "Alan H. Martin" wrote: >jmfbahciv@aol.com wrote: > >> Also, a CPU could "interrupt" another CPU via the doorbell in >> SMP. I'm not sure what happened in a master/slave configuration. >> Since all I/O was done via CPU0, aka the master, I think that >> a job running on CPU1 that needed I/O done would be put on >> a list that CPU0 would look at for I/O (but I can't think >> what that was called). > >In 6.03, jobs executing a UUO that couldn't be done on the slave would >be marked as unrunnable on CPU1, and some other job would be scheduled >to run. The scheduler on CPU0 would notice that it could run the job >and do so. I haven't looked at the fine details of the scheduler for >this. > >I assume that even in master/slave systems, AOSE LOCK/JRST .-1 spinlocks >would let CPU wait for another CPU to kick it with a SETOM LOCK. I'm >not set up to see whether that was actually used, instead of some other >mechanism. IIRC, the JMF invented the spinlocks to solve an SMP problem, namely the pesky non-write through cache. But CDO could talk about this more accurately than I ever could since he was a part of the design conversations that JMF had. > > >However ... Could someone take a look at the list of 7.04 ANF monitor >source files at: > >http://pdp-10.trailing-edge.com/pdp-10/TOPS10_704_MONITORANF_BB-X140C-SB.H TML > >and *please* tell me where all the SMP code lives? CPNSER.MAC was the "driver" for SMP. > I see references to >DXRUN (GO CHECK IF JOB IS RUNNABLE ON THIS PROCESSOR), SETSJ0 (MAKE SURE >JOB IN .CPJOB DOESN'T RUN ELSEWHERE IF NXTJOB UNLOCKS THE SCHEDULER TO >SERVICE THE SWAPPER(SCHED1-CKJB6)), etc., but I can't figure out what >source file they all live in. I can only see the litany of CPOPJ's in >COMMON.MAC for SMP functionality on a single-CPU system. The module was >CP1SER.MAC in 6.03, and comments seem to indicate it was CPNSER.MAC by >7.04, but there's no such extracted file visible. I hope it's just that >someone split the SMP code into several modules and just never fixed all >the comments. I don't know where latter-day sources to the SMP mechanism >would be, otherwise. CPNSER was unbundled. I don't know if it has survived the purge. So far, I've not been able to find out if it exists anymore. /BAH Subtract a hundred and four for e-mail. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing Date: Sun, 11 Feb 01 09:23:53 GMT Organization: UltraNet Communications, Inc. Lines: 25 Message-ID: <965q4u$m64$2@bob.news.rcn.net> References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A859F62.4E6D22B@MA.UltraNet.Com> <3A85EC42.D2118443@MA.UltraNet.Com> X-Trace: UmFuZG9tSVYoa3iptRM5jK8yRibl2GOw3QPLhEEmdeh33vpUOsw6FiVkEBVhfsey X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 11 Feb 2001 10:39:26 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!enews.sgi.com!news.idt.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!207-172-216-126 Xref: chonsp.franklin.ch alt.sys.pdp10:2935 In article <3A85EC42.D2118443@MA.UltraNet.Com>, "Alan H. Martin" wrote: >Eric Smith wrote: >> >> "Alan H. Martin" writes: >> >... Could someone take a look at the list of 7.04 ANF monitor >> > source files at: >> > >> > http://pdp-10.trailing-edge.com/pdp-10/TOPS10_704_MONITORANF_BB-X140C-SB.HT ML >> > >> > and *please* tell me where all the SMP code lives? ... >> >> It lives in SMPSER.MAC, which was unbundled. >> AFAIK, no one has turned up a copy. :-( > >Dang, that sucks. One of the things I mourn the most is that a lot of JMF's and TW's work is just plain gone. /BAH Subtract a hundred and four for e-mail. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.sys.pdp10 Subject: Re: Help understanding interrupt processing References: <3A764A09.8FEE136B@digiweb.com> <3A78E586.8864B7C7@MA.UltraNet.Com> <3A7D0848.29678A56@mail.bcpl.net> <95lkti$15d3$1@nntp1.ba.best.com> <95lun5$204$1@bob.news.rcn.net> <3A859F62.4E6D22B@MA.UltraNet.Com> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 10 Feb 2001 15:10:52 -0800 Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 10 Feb 2001 15:11:14 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!news.spies.com!ruckus.brouhaha.com Xref: chonsp.franklin.ch alt.sys.pdp10:2941 "Alan H. Martin" writes: > However ... Could someone take a look at the list of 7.04 ANF monitor > source files at: > > http://pdp-10.trailing-edge.com/pdp-10/TOPS10_704_MONITORANF_BB-X140C-SB.HTML > > and *please* tell me where all the SMP code lives? I see references to It lives in SMPSER.MAC, which was unbundled. AFAIK, no one has turned up a copy. :-(