From: Lord Isildur Newsgroups: alt.sys.pdp10 Subject: advice on setting up pdp-10 emulator Date: Mon, 3 Nov 2003 12:14:49 -0500 (EST) Organization: Carnegie Mellon, Pittsburgh, PA Lines: 14 Message-ID: NNTP-Posting-Host: smtp2.andrew.cmu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: bb3.andrew.cmu.edu 1067879690 17401 128.2.10.82 (3 Nov 2003 17:14:50 GMT) X-Complaints-To: advisor@andrew.cmu.edu NNTP-Posting-Date: 3 Nov 2003 17:14:50 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.news2me.com!canoe.uoregon.edu!logbridge.uoregon.edu!usenet01.sei.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14108 hello all, so, as part of a general retrocomputing theme, i am interested in setting up one or two emulated pdp10s (using simh of course) , one to run ITS and one to rup TOPS-[12]0, for public use at the CMU computer club. (i'm also planning to put up either a real or emulated pdp11). There seems to be a small but active dec10 community out there.. does anyone have disk images or words of advice for doing this? i am very unfamiliar with pdp10 style machines, i'm a vax and alpha type myself- the closest thing to a dec10 i've ever used was a lisp machine. thanks in advance, isildur ###### From: dfevans@bcr10.uwaterloo.ca (David Evans) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Mon, 3 Nov 2003 17:51:07 +0000 (UTC) Organization: University of Waterloo Lines: 15 Message-ID: References: NNTP-Posting-Host: bcr10.uwaterloo.ca X-Trace: rumours.uwaterloo.ca 1067881867 4014 129.97.34.125 (3 Nov 2003 17:51:07 GMT) X-Complaints-To: abuse@uwaterloo.ca NNTP-Posting-Date: Mon, 3 Nov 2003 17:51:07 +0000 (UTC) X-Newsreader: trn 4.0-test72 (19 April 1999) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!skynet.be!skynet.be!nntp.cs.ubc.ca!torn!news.uwaterloo.ca!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14109 In article , Lord Isildur wrote: > >does anyone have disk images or words of advice >for doing this? This is likely the best place for you to start: http://www.aracnet.com/~healyzh/pdp10emu.html -- David Evans dfevans@bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual ###### From: dfevans@bcr10.uwaterloo.ca (David Evans) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Mon, 3 Nov 2003 17:51:07 +0000 (UTC) Organization: University of Waterloo Lines: 15 Message-ID: References: NNTP-Posting-Host: bcr10.uwaterloo.ca X-Trace: rumours.uwaterloo.ca 1067881867 4014 129.97.34.125 (3 Nov 2003 17:51:07 GMT) X-Complaints-To: abuse@uwaterloo.ca NNTP-Posting-Date: Mon, 3 Nov 2003 17:51:07 +0000 (UTC) X-Newsreader: trn 4.0-test72 (19 April 1999) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!skynet.be!skynet.be!nntp.cs.ubc.ca!torn!news.uwaterloo.ca!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14109 In article , Lord Isildur wrote: > >does anyone have disk images or words of advice >for doing this? This is likely the best place for you to start: http://www.aracnet.com/~healyzh/pdp10emu.html -- David Evans dfevans@bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual ###### From: Lord Isildur Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Mon, 3 Nov 2003 13:46:58 -0500 (EST) Organization: Carnegie Mellon, Pittsburgh, PA Lines: 14 Message-ID: References: NNTP-Posting-Host: smtp3.andrew.cmu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: bb3.andrew.cmu.edu 1067885219 19265 128.2.10.83 (3 Nov 2003 18:46:59 GMT) X-Complaints-To: advisor@andrew.cmu.edu NNTP-Posting-Date: 3 Nov 2003 18:46:59 GMT In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!cycny01.gnilink.net!cyclone1.gnilink.net!canoe.uoregon.edu!logbridge.uoregon.edu!usenet01.sei.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14111 ok, that i did not know. as both of these systems are basically the stuff of legend to me, what are the differences? what are some of the primary features of each? (usually im on the answering side of questions, but thats in vaxland) thanks, isildur On Mon, 3 Nov 2003, Rich Alderson wrote: > > As with most Vax people, you are conflating two systems that are essentially > unrelated, Tops-10 and Tops-20. These two operating systems share no code-- > in truth, they do not even share a design philosophy. So if you're going to > set up multiple systems, set up *three*. ###### From: Rich Alderson Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 04 Nov 2003 18:17:07 -0500 Organization: Systems Administration, XKL LLC, Redmond WA 98052 Lines: 76 Sender: alderson+news@panix5.panix.com Message-ID: References: NNTP-Posting-Host: panix5.panix.com X-Trace: reader2.panix.com 1067987827 4742 166.84.1.5 (4 Nov 2003 23:17:07 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Tue, 4 Nov 2003 23:17:07 +0000 (UTC) X-Newsreader: Gnus v5.7/Emacs 20.7 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.mathworks.com!panix!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14137 Lord Isildur writes (bottom-posting reversed): > On Mon, 3 Nov 2003, Rich Alderson wrote: >> As with most Vax people, you are conflating two systems that are >> essentially unrelated, Tops-10 and Tops-20. These two operating >> systems share no code--in truth, they do not even share a design >> philosophy. So if you're going to set up multiple systems, set up >> *three*. > ok, that i did not know. > as both of these systems are basically the stuff of legend to me, > what are the differences? what are some of the primary features of > each? Memory management: Until late in its life, Tops-10 used a purely swapping scheduler (with smarts WRT segmented programs). Tops-20 started in life as an experiment in demand- paged virtual memory, with a working-set model for swapping. I *believe*, but am prepared to be wrong, that Tops-10 v. 7.01 or 7.02 moved to a Tops-20 style paging model. File system: The Tops-10 filesystem would look very familiar to a VMS Files-11 programmer, with Master File Directory/User File Directories named by project-programmer numbers; late in life, Sub-File Directories named by SIXBIT strings were added, giving up to 7 levels of subdirectory capability. On-disk block size is IIRC 128 words. The Tops-20 filesystem is a hierarchical directory-tree structure, similar to various flavours of Unix, or later versions of VMS. On-disk block size is a 512-word page. System calls: Tops-10 utilizes a series of illegal instructions (UnUsed Operations, later re- christened Unimplemented User Operations, or UUOs) for system calls as well as for user programs: If the opcode is 001 to 037, a user UUO handler routine in the user program is called; if the opcode is 040 to 077, control is passed to the monitor by very much the same mechanism. Depending on the monitor UUO, args are passed in a number of ways. (Note that ITS uses the same mechanism, though the particular calls are very different.) Tops-20 allows the use of user UUOs, though they are less commonly used than in Tops-10 programs, but the system call is a single instruction, 104 (JSYS = Jump to SYStem), with an immediate argument in the range 001 to 777 which selects the desired function; args are passed via accumulators 1 to 4--long arg blocks are passed by reference in the ACs. (The Tops-20 monitor implements a single Tops-10 monitor call, the GETTAB CALLI function which tells the user program what operating system is running, allowing OS-specific programs to exit more cleanly than simply dying.) Command processor: The Tops-10 command processor is built into the monitor itself, and one of the scheduler's tasks is to check each running job for new command input. Tops-20, on the other hand, uses a user-mode program, EXEC, which communicates with the monitor by JSYS calls, similarly to the relation between the Unix kernel and a shell program. (In theory, different shells could be written for Tops-20, but I don't know of any serious effort ever being made; as an experiment, we once tried bash on a Toad-1, and it didn't die even if it blew badly.) Summary: They are very, very different; I've only scratched the surface. (I'm a Tops-20 systems programmer by training, and am learning Tops-10 in fits and starts as I need to. I know almost as much about Tops-10 as I do about ITS, which I've used much more often, at MIT.) -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ###### From: aek@spies.com (Al Kossow) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Tue, 4 Nov 2003 15:45:26 -0800 (PST) Organization: Spies In the Wire Lines: 15 Message-ID: References: NNTP-Posting-Host: spies.com X-Trace: 4 Nov 2003 15:45:56 -0800, spies.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!newsfeed.jpl.nasa.gov!news.spies.com!unknown!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14138 >> ok, that i did not know. >> as both of these systems are basically the stuff of legend to me, >> what are the differences? what are some of the primary features of >> each? A lot of scanned documentation can be found at www.bitsavers.org/pdf/dec/pdp10 on both systems. Dan Murphy's "Origins and Development of TOPS-20" is also a must read if you want to know the history of Tenex. It is unfortunate that the institutional memory of 36 bit DEC systems appears to have been lost at CMU. CMU, Stanford, and MIT were centers of PDP10 knowledge at one time. ###### From: Lord Isildur Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Tue, 4 Nov 2003 19:19:28 -0500 (EST) Organization: Carnegie Mellon, Pittsburgh, PA Lines: 30 Message-ID: References: NNTP-Posting-Host: smtp2.andrew.cmu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: bb3.andrew.cmu.edu 1067991568 26162 128.2.10.82 (5 Nov 2003 00:19:28 GMT) X-Complaints-To: advisor@andrew.cmu.edu NNTP-Posting-Date: 5 Nov 2003 00:19:28 GMT In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.news.ucla.edu!usenet01.sei.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14139 sadly, almost any trace of pdp10s had been expurgated from this place before i got here. a few memories rattle around in the corners, some folks from back in the day will tell tales of them from time to time, but they were pushed aside at cmu by the andrew project and later the mach project, so its been a long, long time since the dec10s were a major part of the systems here. probably not since around 1990 or so. isildur On Tue, 4 Nov 2003, Al Kossow wrote: > >> ok, that i did not know. > >> as both of these systems are basically the stuff of legend to me, > >> what are the differences? what are some of the primary features of > >> each? > > A lot of scanned documentation can be found at www.bitsavers.org/pdf/dec/pdp10 > on both systems. Dan Murphy's "Origins and Development of TOPS-20" is also a > must read if you want to know the history of Tenex. > > It is unfortunate that the institutional memory of 36 bit DEC systems appears > to have been lost at CMU. > > CMU, Stanford, and MIT were centers of PDP10 knowledge at one time. > > > ###### From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Tue, 4 Nov 2003 16:23:27 -0800 Organization: Networks & Distributed Computing Lines: 22 Sender: mrc@ndcms.cac.washington.edu Message-ID: References: NNTP-Posting-Host: nntp6.u.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 1067991857 43628 (None) 140.142.17.40 X-Complaints-To: help@cac.washington.edu In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!takemy.news.telefonica.de!telefonica.de!newsfeed.gamma.ru!Gamma.RU!newsfeed.media.kyoto-u.ac.jp!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!news.u.washington.edu!140.142.17.34.MISMATCH!news.u.washington.edu!Tomobiki-Cho.CAC.Washington.EDU!MRC Xref: redlance.franklin.ch alt.sys.pdp10:14140 On Tue, 4 Nov 2003, Al Kossow wrote: > It is unfortunate that the institutional memory of 36 bit DEC systems appears > to have been lost at CMU. > CMU, Stanford, and MIT were centers of PDP10 knowledge at one time. It has been at least 12 years since the plug was pulled on the last machines at these three institutions. Many of the people there have moved on. Some preserved what we could and waited for better days. It is truly amazing how much from the TOPS-20 world has been preserved, and how well TOPS-20 continues to work on the Internet today. Much of the erstwhile Stanford crew is now in the Seattle area, where at least three entities run 24/7 TOPS-20 systems: XKL, Vulcan (Paul Allen), and Panda. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 04 Nov 2003 16:53:17 -0800 Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 4 Nov 2003 16:54:03 -0800, ruckus.brouhaha.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!takemy.news.telefonica.de!telefonica.de!news.belwue.de!news.tu-darmstadt.de!newsfeed.freenet.de!newsfeed.news2me.com!elnk-nf2-pas!elnk-pas-nf1!newsfeed.earthlink.net!newsfeed.jpl.nasa.gov!news.spies.com!ruckus.brouhaha.com Xref: redlance.franklin.ch alt.sys.pdp10:14141 Rich Alderson writes: > Until late in its life, Tops-10 used a purely swapping scheduler (with > smarts WRT segmented programs). Tops-20 started in life as an > experiment in demand- paged virtual memory, with a working-set model > for swapping. I *believe*, but am prepared to be wrong, that Tops-10 > v. 7.01 or 7.02 moved to a Tops-20 style paging model. TOPS-10 6.xx had demand paging, but on a KL it used the KI-style paging rather than KL-style. The System Reference Manual calls these TOPS-10 Paging and TOPS-20 Paging, but that was written before the TOPS-10 7.xx monitors. TOPS-10 had the really cool feature that a user could write his own page fault handler. With most operating systems this can't be done without hacking the kernel (or whatever you call the privileged system code). ###### From: healyzh@aracnet.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 5 Nov 2003 04:39:52 GMT Organization: Aracnet Lines: 15 Message-ID: References: NNTP-Posting-Host: p-773.newsdawg.com User-Agent: tin/1.6.0-20030714 ("Vatersay") (UNIX) (Linux/2.4.20-18.9smp (i686)) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!tiscali!newsfeed1.ip.tiscali.net!feed.news.nacamar.de!news.maxwell.syr.edu!news.he.net!cyclone-sf.pbi.net!129.250.175.17!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14142 Lord Isildur wrote: > so, as part of a general retrocomputing theme, i am interested in setting up > one or two emulated pdp10s (using simh of course) , one to run ITS and one One bit of advice is to take a look at KLH10 in addition to SIMH. Personally I prefer to run TOPS-10 on SIMH, and TOPS-20 on KLH10. The SIMH emulation is limited to KS10, so you can only run TOPS-20 V4.1. OTOH, KLH10 can run TOPS-20 V7.0 and includes TCP/IP support. As has been suggested, take a look at http://www.aracnet.com/~healyzh/pdp10emu.html it was created to make it easy to find all the pieces that are needed. Unfortunatly there might be some dead links to stuff as I've not had time to verify links in a *LONG* time. Zane ###### Sender: CStacy@BOHR Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: From: cstacy@dtpq.com (Christopher C. Stacy) Message-ID: Lines: 94 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Nov 2003 08:04:27 GMT NNTP-Posting-Host: 68.163.138.194 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc03.gnilink.net 1068019467 68.163.138.194 (Wed, 05 Nov 2003 03:04:27 EST) NNTP-Posting-Date: Wed, 05 Nov 2003 03:04:27 EST Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller.gnilink.net!nwrddc03.gnilink.net.POSTED!53ab2750!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14147 >>>>> On 04 Nov 2003 18:17:07 -0500, Rich Alderson ("Rich") writes: Rich> System calls: Rich> Tops-10 utilizes a series of illegal instructions [...] Rich> (Note that ITS uses the same mechanism, though the particular Rich> calls are very different.) Rich> Tops-20 allows the use of user UUOs, though they are less commonly used than in Rich> Tops-10 programs, but the system call is a single instruction, 104 (JSYS = Jump Rich> to SYStem), with an immediate argument in the range 001 to 777 which selects Rich> the desired function; args are passed via accumulators 1 to 4--long arg blocks Rich> are passed by reference in the ACs. ITS started out using UUOs (since that what that machine feature was for), and continued to support a bunch of them through its lifetime (some for backwards compatability, and some because UUOs were convenient and cheap). But modern ITS programs generally invoked the system services through the single UUO named ".CALL", which did a "symbolic" call. (CALL is similar to, but predates, and is maybe more flexible than the JSYS UUO of TOPS-20. On ITS, accumulators were not reserved for .CALL'ed services - you could put your arguments and values anywhere you wanted.) The .CALL UUO specified AC 0, and the memory part of the word pointed to a control block. The idea was to give a regular syntax for executing all system calls. The control block contained the SIXBIT name of the operation to be performed, and opcode-operand pairs that described control bits and immediate or referenced parameters (such as AC or memory sources and destinations, data lengths, channel numbers, etc.) Most system calls were written using a macro like this: DEFINE SYSCAL NAME,ARGS .CALL [SETZ ? SIXBIT /NAME/ ? ARGS ((SETZ))] TERMIN (Those SETZs are magic cookies that bound the control block.) Here's an example of opening an output channel on the user's TTY: SYSCAL OPEN,[%CLBIT,,.UAO ? %CLIMM,,TTYO ? [SIXBIT /TTY/]] .LOSE %LSFIL This is a generic OPEN call: the first arg is giving control bits, the second arg is an immediate operand giving the channel number (symbolically defined somewhere as TTYO), and the last parameter is giving the device name. The call above is followed by a .LOSE UUO call; all .CALL calls skip on success. The .LOSE UUO is the standard way to signal a fatal program error. The job's PC is pointed to the preceeding instruction (ie., the failing system call), the job's return value is set to the indicated magic bits, and the job is given an interrupt. The upshot of all that is that the user is returned to the command shell (DDT) and the magic bits are used to provide the information needed to know how to construct a nice error message. %LSFIL refers to a file operation, so the shell would generate the error message from the failed call's error code, looking in the call's control block to find the relevent file name. Here's a random example from an application's interrupt handler: IOCINT: .SUSET [.RBCHN,,A] ;See which channel is erring. CAIE A,DSKO ;If it is not the disk output channel JSR AUTPSY ; we are in trouble. SYSCAL STATUS,[A ? %CLOUT,,B] JSR AUTPSY LDB A,[330500,,B] ;Get the error code. Note the use of the SUSET UUO to read the job's own status variables. Although there were (usually more featureful) symbolic versions of all or just about all the old UUOs, sometimes it was just convenient to call the functionality in the old way. Notice also the sad lack of a defined symbol for the byte pointer to get the error code out of the STATUS call's result (which we asked to be placed in B), sigh. Speaking of style and optimization, though... IFNDEF NOP,NOP=: Anyway, in this example program, the AUTPSY routine is a fancy fatal error handler, which eventually would do something like: SYSCAL LOSE,[%CLIMM,,%LSFIL ? AUTPSY] ;Else say what went wrong. NOP .LOGOUT 1, In that case, we're using the symbolic (not UUO) version of the "LOSE" system call; it lets us specofy the failing PC to analyze (as opposed to the normal PC-minus-1). The .LOGOUT UUO just does what you think: terminates the job. ###### From: Andreas Davour Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 05 Nov 2003 10:18:40 +0100 Organization: Update Computer Club Lines: 31 Sender: ante@update.uu.se Message-ID: References: NNTP-Posting-Host: Tempo.Update.UU.SE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: Tempo.Update.UU.SE 1068023920 32203 2001:6b0:b:fff0::11 (5 Nov 2003 09:18:40 GMT) X-Complaints-To: newsmaster@Update.UU.SE NNTP-Posting-Date: Wed, 5 Nov 2003 09:18:40 +0000 (UTC) User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed3.funet.fi!newsfeed1.funet.fi!newsfeeds.funet.fi!newsfeed.sunet.se!news01.sunet.se!puffinus.its.uu.se!news.Update.UU.SE!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14148 Rich Alderson writes: > Lord Isildur writes (bottom-posting reversed): > >> On Mon, 3 Nov 2003, Rich Alderson wrote: > >>> As with most Vax people, you are conflating two systems that are >>> essentially unrelated, Tops-10 and Tops-20. These two operating >>> systems share no code--in truth, they do not even share a design >>> philosophy. So if you're going to set up multiple systems, set up >>> *three*. > >> ok, that i did not know. >> as both of these systems are basically the stuff of legend to me, >> what are the differences? what are some of the primary features of >> each? [a of lot interesting stuff cut] > Summary: > > They are very, very different; I've only scratched the surface. (I'm a Tops-20 > systems programmer by training, and am learning Tops-10 in fits and starts as I > need to. I know almost as much about Tops-10 as I do about ITS, which I've > used much more often, at MIT.) Since ITS is so talked about I wouldn't mind if you would like to share some similar thoughts like the one above on ITS. Much interesting stuff, that was! /andreas ###### From: Andreas Davour Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 05 Nov 2003 11:41:12 +0100 Organization: Update Computer Club Lines: 30 Sender: ante@update.uu.se Message-ID: References: NNTP-Posting-Host: Tempo.Update.UU.SE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: Tempo.Update.UU.SE 1068028872 9420 2001:6b0:b:fff0::11 (5 Nov 2003 10:41:12 GMT) X-Complaints-To: newsmaster@Update.UU.SE NNTP-Posting-Date: Wed, 5 Nov 2003 10:41:12 +0000 (UTC) User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed3.funet.fi!newsfeed1.funet.fi!newsfeeds.funet.fi!nntp.inet.fi!inet.fi!news-stoc.telia.net!news-stoa.telia.net!telia.net!newsfeed.sunet.se!news01.sunet.se!puffinus.its.uu.se!news.Update.UU.SE!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14149 cstacy@dtpq.com (Christopher C. Stacy) writes: >>>>>> On 04 Nov 2003 18:17:07 -0500, Rich Alderson ("Rich") writes: > Rich> System calls: > Rich> Tops-10 utilizes a series of illegal instructions > [...] > Rich> (Note that ITS uses the same mechanism, though the particular > Rich> calls are very different.) > > Rich> Tops-20 allows the use of user UUOs, though they are less commonly used than in > Rich> Tops-10 programs, but the system call is a single instruction, 104 (JSYS = Jump > Rich> to SYStem), with an immediate argument in the range 001 to 777 which selects > Rich> the desired function; args are passed via accumulators 1 to 4--long arg blocks > Rich> are passed by reference in the ACs. > > ITS started out using UUOs (since that what that machine feature was for), > and continued to support a bunch of them through its lifetime (some for > backwards compatability, and some because UUOs were convenient and cheap). > > But modern ITS programs generally invoked the system services > through the single UUO named ".CALL", which did a "symbolic" call. > (CALL is similar to, but predates, and is maybe more flexible than > the JSYS UUO of TOPS-20. On ITS, accumulators were not reserved > for .CALL'ed services - you could put your arguments and values > anywhere you wanted.) So the UUO is part of the hardware, as is JSYS, and the different systems just used them differently? Or have I misunderstood completely? /andreas ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 05 Nov 03 11:30:45 GMT Organization: UltraNet Communications, Inc. Lines: 49 Message-ID: References: X-Trace: UmFuZG9tSVbmr9CNmqGYT7gXQq0OuZcKkksoNKPAbLs3KhRYSHqRWjNVR7hTEFjU X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 5 Nov 2003 12:33:42 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!logbridge.uoregon.edu!feed1.news.rcn.net!rcn!feed3.news.rcn.net!208-59-181-24 Xref: redlance.franklin.ch alt.sys.pdp10:14152 In article , Andreas Davour wrote: >cstacy@dtpq.com (Christopher C. Stacy) writes: > >>>>>>> On 04 Nov 2003 18:17:07 -0500, Rich Alderson ("Rich") writes: >> Rich> System calls: >> Rich> Tops-10 utilizes a series of illegal instructions >> [...] >> Rich> (Note that ITS uses the same mechanism, though the particular >> Rich> calls are very different.) >> >> Rich> Tops-20 allows the use of user UUOs, though they are less commonly used than in >> Rich> Tops-10 programs, but the system call is a single instruction, 104 (JSYS = Jump >> Rich> to SYStem), with an immediate argument in the range 001 to 777 which selects >> Rich> the desired function; args are passed via accumulators 1 to 4--long arg blocks >> Rich> are passed by reference in the ACs. >> >> ITS started out using UUOs (since that what that machine feature was for), >> and continued to support a bunch of them through its lifetime (some for >> backwards compatability, and some because UUOs were convenient and cheap). >> >> But modern ITS programs generally invoked the system services >> through the single UUO named ".CALL", which did a "symbolic" call. >> (CALL is similar to, but predates, and is maybe more flexible than >> the JSYS UUO of TOPS-20. On ITS, accumulators were not reserved >> for .CALL'ed services - you could put your arguments and values >> anywhere you wanted.) > >So the UUO is part of the hardware, as is JSYS, and the different >systems just used them differently? Or have I misunderstood completely? They're instruction codes. Find a copy of the "decsystem10 SYSTEM REFERENCE CARD". I'm looking at the one designed after the KI-10 was developed. Part number DEC-10-XSRCA-B-D. Look on the logical last page of the card. It lays out the meaning of the values in bits 0-8 of the word format. You can find the word formats on logical page 1 and 2 of the card (I'm counting the title page as page 0). /BAH Subtract a hundred and four for e-mail. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 05 Nov 03 11:35:38 GMT Organization: UltraNet Communications, Inc. Lines: 49 Message-ID: References: X-Trace: UmFuZG9tSVZX3eFV9oYjF7mNwiMUjWZ3yqCWbkMo2DkNPObW0d48MKAas4/QcO7C X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 5 Nov 2003 12:38:34 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!solnet.ch!solnet.ch!newspeer1.nwr.nac.net!newspeer.monmouth.com!logbridge.uoregon.edu!feed1.news.rcn.net!rcn!feed3.news.rcn.net!208-59-181-24 Xref: redlance.franklin.ch alt.sys.pdp10:14153 In article , Andreas Davour wrote: >cstacy@dtpq.com (Christopher C. Stacy) writes: > >>>>>>> On 04 Nov 2003 18:17:07 -0500, Rich Alderson ("Rich") writes: >> Rich> System calls: >> Rich> Tops-10 utilizes a series of illegal instructions >> [...] >> Rich> (Note that ITS uses the same mechanism, though the particular >> Rich> calls are very different.) >> >> Rich> Tops-20 allows the use of user UUOs, though they are less commonly used than in >> Rich> Tops-10 programs, but the system call is a single instruction, 104 (JSYS = Jump >> Rich> to SYStem), with an immediate argument in the range 001 to 777 which selects >> Rich> the desired function; args are passed via accumulators 1 to 4--long arg blocks >> Rich> are passed by reference in the ACs. >> >> ITS started out using UUOs (since that what that machine feature was for), >> and continued to support a bunch of them through its lifetime (some for >> backwards compatability, and some because UUOs were convenient and cheap). >> >> But modern ITS programs generally invoked the system services >> through the single UUO named ".CALL", which did a "symbolic" call. >> (CALL is similar to, but predates, and is maybe more flexible than >> the JSYS UUO of TOPS-20. On ITS, accumulators were not reserved >> for .CALL'ed services - you could put your arguments and values >> anywhere you wanted.) > >So the UUO is part of the hardware, as is JSYS, and the different >systems just used them differently? Or have I misunderstood completely? I would guess that ITS' .CALL was similar to our CALLI. but the monitor didn't blast the user ACs anymore than it had to. The line of communication between the user program and the monitor was the calling AC set plus the flavor of the return. Some UUOs didn't have a skip return (which evolved into signifying "no errors detected"). I always had culture shock (I was a newbie w.r.t. programming PDP-10s) when I'd encounter a monitor call that didn't skip. /BAH Subtract a hundred and four for e-mail. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 05 Nov 03 13:44:51 GMT Organization: UltraNet Communications, Inc. Lines: 53 Message-ID: References: X-Trace: UmFuZG9tSVbgtjaJCBgrzTcAZ4qMmu1CbhSJS/OYrOOFC9b2JbulHHzDU5DQp+TK X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 5 Nov 2003 14:47:47 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!feed3.news.rcn.net!207-172-97-242 Xref: redlance.franklin.ch alt.sys.pdp10:14157 In article , Andreas Davour wrote: >jmfbahciv@aol.com writes: > >>>So the UUO is part of the hardware, as is JSYS, and the different >>>systems just used them differently? Or have I misunderstood completely? >> >> They're instruction codes. Find a copy of the "decsystem10 SYSTEM >> REFERENCE CARD". I'm looking at the one designed after the KI-10 >> was developed. Part number DEC-10-XSRCA-B-D. >> >> Look on the logical last page of the card. It lays out the meaning >> of the values in bits 0-8 of the word format. You can find the word >> formats on logical page 1 and 2 of the card (I'm counting the title >> page as page 0). > >That ref card isn't that easy to find these days... What?!!! I thought Al has them scanned in. > >Maybe I am dense but I didn't understood much of that explanation. That's OK. I'm not very good at explaining this stuff. That's why I pointed you at the card. It is an amazing little piece of cardboard just chocked full of information that could fill a library. The people who designed this should take kudos a bow, and know that they're work was oft appreciated by hardware challenged people like me. > ... If >they are "instruction codes", they are both part of the "wiring" of the >CPU, right? Kindof. The way I understand (which isn't much) is that this range of instructions trapped so that the monitor was forced to deal with them. They were a way to extend an instruction into a legal execution of monitor code by the user program. If the only exposure you to user/exec code is the drivel out of Redmond, then you will be confused. -10 philosophy kept very strict segregation between user and monitor. I think, based on what people told me, Multics took this to an extreme because its goal was security. > >I'm more of a pdp fan than much of a computer architecht kind of guy... That's OK. As long as you play with it :-). Besides, what we think is clear may not be to somebody who hasn't met a real machine. All the byte addressing business...muttering emoticon fades away. /BAH Subtract a hundred and four for e-mail. ###### From: Andreas Davour Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 05 Nov 2003 14:45:28 +0100 Organization: Update Computer Club Lines: 23 Sender: ante@update.uu.se Message-ID: References: NNTP-Posting-Host: Tempo.Update.UU.SE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: Tempo.Update.UU.SE 1068039929 2788 2001:6b0:b:fff0::11 (5 Nov 2003 13:45:29 GMT) X-Complaints-To: newsmaster@Update.UU.SE NNTP-Posting-Date: Wed, 5 Nov 2003 13:45:29 +0000 (UTC) User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed3.funet.fi!newsfeed1.funet.fi!newsfeeds.funet.fi!newsfeed.sunet.se!news01.sunet.se!puffinus.its.uu.se!news.Update.UU.SE!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14154 jmfbahciv@aol.com writes: >>So the UUO is part of the hardware, as is JSYS, and the different >>systems just used them differently? Or have I misunderstood completely? > > They're instruction codes. Find a copy of the "decsystem10 SYSTEM > REFERENCE CARD". I'm looking at the one designed after the KI-10 > was developed. Part number DEC-10-XSRCA-B-D. > > Look on the logical last page of the card. It lays out the meaning > of the values in bits 0-8 of the word format. You can find the word > formats on logical page 1 and 2 of the card (I'm counting the title > page as page 0). That ref card isn't that easy to find these days... Maybe I am dense but I didn't understood much of that explanation. If they are "instruction codes", they are both part of the "wiring" of the CPU, right? I'm more of a pdp fan than much of a computer architecht kind of guy... /andreas ###### From: Lars Brinkhoff Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 05 Nov 2003 14:58:19 +0100 Organization: nocrew Lines: 11 Sender: lars@junk.nocrew.org Message-ID: <85y8uuhq84.fsf@junk.nocrew.org> References: NNTP-Posting-Host: junk.nocrew.org (213.242.147.30) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.uni-berlin.de 1068040848 47282463 213.242.147.30 (16 [140306]) X-Orig-Path: junk.nocrew.org!not-for-mail User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!fu-berlin.de!uni-berlin.de!junk.nocrew.ORG!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14156 Andreas Davour writes: > jmfbahciv@aol.com writes: > > Find a copy of the "decsystem10 SYSTEM REFERENCE CARD". > That ref card isn't that easy to find these days... Try this: http://www.inwap.com/pdp10/opcodes.html -- Lars Brinkhoff, Services for Unix, Linux, PDP-10, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/ ###### From: Lars Brinkhoff Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 05 Nov 2003 14:58:19 +0100 Organization: nocrew Lines: 11 Sender: lars@junk.nocrew.org Message-ID: <85y8uuhq84.fsf@junk.nocrew.org> References: NNTP-Posting-Host: junk.nocrew.org (213.242.147.30) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.uni-berlin.de 1068040848 47282463 213.242.147.30 (16 [140306]) X-Orig-Path: junk.nocrew.org!not-for-mail User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!fu-berlin.de!uni-berlin.de!junk.nocrew.ORG!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14156 Andreas Davour writes: > jmfbahciv@aol.com writes: > > Find a copy of the "decsystem10 SYSTEM REFERENCE CARD". > That ref card isn't that easy to find these days... Try this: http://www.inwap.com/pdp10/opcodes.html -- Lars Brinkhoff, Services for Unix, Linux, PDP-10, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/ ###### Sender: CStacy@BOHR Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: From: cstacy@dtpq.com (Christopher C. Stacy) Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Nov 2003 19:39:04 GMT NNTP-Posting-Host: 68.163.138.194 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc01.gnilink.net 1068061144 68.163.138.194 (Wed, 05 Nov 2003 14:39:04 EST) NNTP-Posting-Date: Wed, 05 Nov 2003 14:39:04 EST Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!snoopy.risq.qc.ca!in.100proofnews.com!in.100proofnews.com!cycny01.gnilink.net!cyclone1.gnilink.net!spamkiller.gnilink.net!nwrddc01.gnilink.net.POSTED!53ab2750!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14166 >>>>> On Wed, 05 Nov 2003 11:41:12 +0100, Andreas Davour ("Andreas") writes: Andreas> So the UUO is part of the hardware, as is JSYS, and the Andreas> different systems just used them differently? Or have I Andreas> misunderstood completely? You understand exactly correctly. UUOs are several machine instructions that all do essentially the same thing: jump to a particular (hardwired) location in memory, and store some information about what instruction caused the jump. It is up to the operating system to put some code there to decide what to do about it. The OS then looks at the instruction (and looks at anything else it wants to), and does whatever it wants. The protocol was generally that the AC and Memory fields of the instruction were set by the user to specify more detail about the desired service. (For example, in a UUO to read a character, the AC field might be the AC that contains the IO channel number, and the Memory field might be a pointer to an input buffer.) On ITS and TOPS-20, rather than use a bunch of different UUOs to mean different things, they decided to just pick one UUO to mean "general purpose request for system service". The desired operation itself, as well as the parameters, were indicated by some protocol (looking at the instruction, or looking at some predefined ACs, or whatever). ###### Sender: CStacy@BOHR Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: From: cstacy@dtpq.com (Christopher C. Stacy) Message-ID: Lines: 4 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Nov 2003 19:45:52 GMT NNTP-Posting-Host: 68.163.138.194 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc01.gnilink.net 1068061552 68.163.138.194 (Wed, 05 Nov 2003 14:45:52 EST) NNTP-Posting-Date: Wed, 05 Nov 2003 14:45:52 EST Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!nwrddc01.gnilink.net.POSTED!53ab2750!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14167 Just to clarify this: the UUOs (particular machine instructions) each had an assembler mneumonic, but that varied from OS to OS. On TOPS 20, one of them was picked and named "JSYS", and on ITS, one of them was named ".CALL". ###### From: Rich Alderson Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 05 Nov 2003 19:19:16 -0500 Organization: Systems Administration, XKL LLC, Redmond WA 98052 Lines: 25 Sender: alderson+news@panix5.panix.com Message-ID: References: NNTP-Posting-Host: panix5.panix.com X-Trace: reader2.panix.com 1068077956 3309 166.84.1.5 (6 Nov 2003 00:19:16 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Thu, 6 Nov 2003 00:19:16 +0000 (UTC) X-Newsreader: Gnus v5.7/Emacs 20.7 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!newsfeed.mathworks.com!panix!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14168 cstacy@dtpq.com (Christopher C. Stacy) writes: > On ITS and TOPS-20, rather than use a bunch of different UUOs to mean > different things, they decided to just pick one UUO to mean "general > purpose request for system service". The desired operation itself, > as well as the parameters, were indicated by some protocol (looking > at the instruction, or looking at some predefined ACs, or whatever). The same can be said about Tops-10 and the CALLI UUO. There was a large number of named CALLI's, where the effective address was a positive value. User sites could define "negative CALLI's", in which bit 18 was set, for local functionality. (This was standardized early enough that one of the primary differences from a base DEC monitor and any of WAITS, TYMCOM-X, and the CompuServe monitor was the presence of numerous "negative CALLI's". Of course, the base monitor differed for each.) However, several other UUO's were also used, just as in ITS. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ###### From: Rich Alderson Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 05 Nov 2003 19:23:58 -0500 Organization: Systems Administration, XKL LLC, Redmond WA 98052 Lines: 16 Sender: alderson+news@panix5.panix.com Message-ID: References: NNTP-Posting-Host: panix5.panix.com X-Trace: reader2.panix.com 1068078238 3309 166.84.1.5 (6 Nov 2003 00:23:58 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Thu, 6 Nov 2003 00:23:58 +0000 (UTC) X-Newsreader: Gnus v5.7/Emacs 20.7 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!takemy.news.telefonica.de!telefonica.de!news.tiscali.de!feed.news.nacamar.de!uio.no!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.mathworks.com!panix!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14169 cstacy@dtpq.com (Christopher C. Stacy) writes: > Just to clarify this: the UUOs (particular machine instructions) > each had an assembler mneumonic, but that varied from OS to OS. > On TOPS 20, one of them was picked and named "JSYS", and on ITS, > one of them was named ".CALL". But the ITS .CALL UUO was, IIRC, in the usual UUO range (040-077), while JSYS is opcode 104. This was chosen by the TENEX developers so as not to conflict with the UUO's in their original development environment, a DEC monitor. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ###### From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 5 Nov 2003 17:05:11 -0800 Organization: Networks & Distributed Computing Lines: 16 Sender: mrc@ndcms.cac.washington.edu Message-ID: References: NNTP-Posting-Host: nntp4.u.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 1068080836 46988 (None) 140.142.17.38 X-Complaints-To: help@cac.washington.edu In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.mathworks.com!arclight.uoregon.edu!hammer.uoregon.edu!logbridge.uoregon.edu!news.u.washington.edu!140.142.17.34.MISMATCH!news.u.washington.edu!Tomobiki-Cho.CAC.Washington.EDU!MRC Xref: redlance.franklin.ch alt.sys.pdp10:14171 On Wed, 5 Nov 2003, Rich Alderson wrote: > But the ITS .CALL UUO was, IIRC, in the usual UUO range (040-077), while JSYS > is opcode 104. This was chosen by the TENEX developers so as not to conflict > with the UUO's in their original development environment, a DEC monitor. JSYS was a machine instruction on KA10s with the BBN pager. User JSYS (E>777) was executed in the hardware, and exec JSYS (E<1000) dispatched directly through a dispatch table and entered exec mode. On the KL and KS, JSYS (including user JSYS) was an MUUO. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ###### From: "Glen Herrmannsfeldt" Newsgroups: alt.sys.pdp10 References: Subject: Re: advice on setting up pdp-10 emulator Lines: 38 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: <7bhqb.87041$9E1.439868@attbi_s52> NNTP-Posting-Host: 12.228.234.203 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s52 1068080963 12.228.234.203 (Thu, 06 Nov 2003 01:09:23 GMT) NNTP-Posting-Date: Thu, 06 Nov 2003 01:09:23 GMT Organization: Comcast Online Date: Thu, 06 Nov 2003 01:09:23 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!snoopy.risq.qc.ca!msc1.onvoy!onvoy.com!hammer.uoregon.edu!logbridge.uoregon.edu!nntp-server.caltech.edu!attla2!ip.att.net!attbi_feed3!attbi.com!attbi_s52.POSTED!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14170 "Christopher C. Stacy" wrote in message news:uwuae4nc7.fsf@dtpq.com... > >>>>> On Wed, 05 Nov 2003 11:41:12 +0100, Andreas Davour ("Andreas") writes: > > Andreas> So the UUO is part of the hardware, as is JSYS, and the > Andreas> different systems just used them differently? Or have I > Andreas> misunderstood completely? > > You understand exactly correctly. I would have said that they were not in the hardware, which is what made them special, but the distinction is subtle. Most machines with a protected architecture ( user/supervisor mode, memory protection, etc.) have some kind of trap for executing an opcode that doesn't match a valid instruction. I would have said that UUO's are just invalid instructions to the hardware, and the OS processes them. I am not sure I understand JSYS, though. Consider that IBM S/360 has a specific instruction, SVC, with its own interrupt vector to signal the OS that a user program needs some service from the OS. (SVC has an eight bit operand which is supplied to the OS.) On the other hand, VM/CMS use the DIAGNOSE instruction, defined to be machine dependent and guaranteed to be a privileged instruction so that CP can trap it. The only opcode that S/360 and successors guarantee will always be invalid is X'00'. If each UUO had its own vector, or if all UUO's had a different vector than any other undefined instruction, then I would say that they have hardware support. The PDP-10 has nine bit opcodes, so twice as many as usual for eight bit machines. -- glen ###### From: budd@csa.bu.edu (Phil Budne) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Followup-To: alt.sys.pdp10 Date: 6 Nov 2003 01:44:18 GMT Organization: Boston University Computer Science Dept. Lines: 38 Message-ID: References: X-Trace: news3.bu.edu 1068083058 10301 128.197.12.3 (6 Nov 2003 01:44:18 GMT) X-Complaints-To: news@bu.edu Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!snoopy.risq.qc.ca!elk.ncren.net!news.bu.edu!budd Xref: redlance.franklin.ch alt.sys.pdp10:14172 In article , wrote: >I would guess that ITS' .CALL was similar to our CALLI. ITS .CALL was slightly more like the "CALL" UUO (opcode 40) than CALLI (opcode 47). I've very rarely seen CALL used in code. That is; CALL [SIXBIT /EXIT/] instead of; CALLI 12 CALL support is present in 7.04, see label UCALL in http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/01/10,7/mon/uuocon.mac.html CALL's "Y" (right half(*)) field points to a word containing the sixbit name of the function, and CALLI's "Y" field was an immediate value for the function code. For both, AC field indicates an AC which contains arguments (or a pointer to arguments), except when it doesn't (when the EXIT CALL(I), takes a "1" in the AC field, it acts differently). ITS' .CALL UUO argument block contains both the name of the function, and the arguments. Something hidden in CStacey's example is that the instructions MOVE, MOVEI and MOVEM "happened" to include the right bit patterns for "input", "immediate" and "output" arguments descriptors: .CALL [SETZ ? SIXBIT/LOAD/ ? MOVEI -1 ? SETZI DKIC] ITS CALLs did not require having a free AC at all, while the TOPS-20 JSYS calls were wired to use ACs 1 and up for arguments. (*) the right half after address calculations are performed, and the result is stored in monitor low core (or the User Page Table). I don't recall ever seeing anyone use indexing or the indirect bit on a CALLI, but it was common practice on LUUO's -- opcodes 0-37 which trapped thru location 40 of the user address space. ###### Message-ID: <3FA9FF17.DB3EC340@comcast.net> From: Charles Richmond Reply-To: richmond@nospam.plano.net Organization: Canine Computer Center X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 32 NNTP-Posting-Host: 24.1.126.198 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s02 1068098569 24.1.126.198 (Thu, 06 Nov 2003 06:02:49 GMT) NNTP-Posting-Date: Thu, 06 Nov 2003 06:02:49 GMT Date: Thu, 06 Nov 2003 06:02:49 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!attbi_s02.POSTED!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14173 "Christopher C. Stacy" wrote: > > >>>>> On Wed, 05 Nov 2003 11:41:12 +0100, Andreas Davour ("Andreas") writes: > > Andreas> So the UUO is part of the hardware, as is JSYS, and the > Andreas> different systems just used them differently? Or have I > Andreas> misunderstood completely? > > You understand exactly correctly. > > UUOs are several machine instructions that all do essentially > the same thing: jump to a particular (hardwired) location in memory, > and store some information about what instruction caused the jump. > It is up to the operating system to put some code there to decide > what to do about it. The OS then looks at the instruction (and > looks at anything else it wants to), and does whatever it wants. > The protocol was generally that the AC and Memory fields of the > instruction were set by the user to specify more detail about > the desired service. (For example, in a UUO to read a character, > the AC field might be the AC that contains the IO channel number, > and the Memory field might be a pointer to an input buffer.) > This idea was *not* lost on more modern processors. The Motorola 68000 family has the "line A" and "line F" instructions, which also branch to an address stored at a specific location in lower memory. This allowed "instructions" to be defined that actually executed a subroutine to perform the task... -- +----------------------------------------------------------------+ | Charles and Francis Richmond richmond at plano dot net | +----------------------------------------------------------------+ ###### Sender: CStacy@BOHR Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: <7bhqb.87041$9E1.439868@attbi_s52> From: cstacy@dtpq.com (Christopher C. Stacy) Message-ID: Lines: 73 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Nov 2003 06:19:14 GMT NNTP-Posting-Host: 68.163.138.194 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc01.gnilink.net 1068099554 68.163.138.194 (Thu, 06 Nov 2003 01:19:14 EST) NNTP-Posting-Date: Thu, 06 Nov 2003 01:19:14 EST Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!takemy.news.telefonica.de!telefonica.de!news.tiscali.de!feed.news.nacamar.de!tiscali!newsfeed1.ip.tiscali.net!news-xfer2.atl.newshosting.com!63.218.45.10.MISMATCH!newshosting.com!news-xfer1.atl.newshosting.com!216.166.71.118.MISMATCH!small1.nntp.aus1.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!nwrddc01.gnilink.net.POSTED!53ab2750!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14174 >>>>> On Thu, 06 Nov 2003 01:09:23 GMT, Glen Herrmannsfeldt ("Glen") writes: Glen> "Christopher C. Stacy" wrote in message Glen> news:uwuae4nc7.fsf@dtpq.com... >> >>>>> On Wed, 05 Nov 2003 11:41:12 +0100, Andreas Davour ("Andreas") Glen> writes: >> Andreas> So the UUO is part of the hardware, as is JSYS, and the Andreas> different systems just used them differently? Or have I Andreas> misunderstood completely? >> >> You understand exactly correctly. Glen> I would have said that they were not in the hardware, which is Glen> what made them special, but the distinction is subtle. Glen> I would have said that UUO's are just invalid instructions to Glen> the hardware, and the OS processes them. I am not sure I Glen> understand JSYS, though. No, UUOs are are not "just invalid", and it is by no means some hack or happy accident that they cause processor traps that are used to call the operating system. UUO stands for "Unimplemented User Operation"; this is not referring to an invalid opcode. The intended purpose of UUOs is for jumping into functional handlers provided either by the user or by the operating system. UUO trapping behaviour is well defined and is carefully designed for this specific purpose. In effect, this allows the user or the OS to extend the machine instruction set by providing meanings to a designated reserved set of opcodes. Opcodes 001 - 037 are reserved for user-defined routines, while opcodes 040 - 077 are called MUUOs and are for system routines. Both kinds of UUOs do the same thing: the processor stores the instruction in location 40 and then executes whatever instruction it finds in location 41. Whether this is done in EXEC mode or USER mode depends on whether it was an MUUO or a regular UUO. (If you want to get technical, it stores a modified version of the instruction, after computing the EA and zapping the XI parts. And there are some other wrinkles that I've left out, but none of that is really important for this discussion.) JSYS, opcode 120, was was not defined on early PDP-10s. I'm not sure exactly how the later hardware handles this opcode and I don't have the TOPS-20 Monitor sources to look at. I expect that MRC could supply the details if it mattered. I think that the JSYS opcode was assigned for TENEX and TOPS-20, rather than just designating some existing MUUO opcode, because the details of the trapping are different (eg. doubtless having to do with microcode support for TOPS-20 process tables), and also perhaps so that the MUUO space would be available for some other purpose or for some other in/compatability reason. The hardware/microcode determines what happens when any kind of privileged, illegal, or UUO instruction is executed. The operating system software works in conjunction with that processor behaviour to determine the meaning of the UUOs. If you execute an illegal opcode, the processor does something a little bit different than what UUOs do. (The details depend on what the instruction was and on what model processor you're talking about.) And of course, some of those illegal opcodes could mean something someday (as did JSYS), so you can't go around writing code that just does any old random illegal opcode and hope that you'll get UUO trapping behaviour. By contrast, the UUO opcodes and (on later CPUs) the JSYS opcode are specifically intended for the purpose of doing a certain kind of function calling. They are just as valid opcodes as JRST is. ###### From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Wed, 5 Nov 2003 22:46:35 -0800 Organization: University of Washington Lines: 27 Message-ID: References: <7bhqb.87041$9E1.439868@attbi_s52> NNTP-Posting-Host: shiva0.cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 1068101197 47048 (None) 140.142.17.39 X-Complaints-To: help@cac.washington.edu In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newspeer.monmouth.com!logbridge.uoregon.edu!news.u.washington.edu!140.142.17.34.MISMATCH!news.u.washington.edu!shiva0.cac.washington.edu!mrc Xref: redlance.franklin.ch alt.sys.pdp10:14175 On Thu, 6 Nov 2003, Christopher C. Stacy wrote: > Opcodes 001 - 037 are reserved for user-defined routines, while > opcodes 040 - 077 are called MUUOs and are for system routines. > Both kinds of UUOs do the same thing: the processor stores the > instruction in location 40 and then executes whatever instruction > it finds in location 41. Whether this is done in EXEC mode or > USER mode depends on whether it was an MUUO or a regular UUO. More precisely, LUUOs (001-037) trap to 40/41 in user space. On the PDP-6 and KA10, MUUOs (040-077) trap to 40/41 in exec space. On the later processors, MUUOs and illegal instructions trap through a vector of 8 locations in the UPT, depending upon whether it is a trap or no-trap, and kernel/supervisor/public/concealed mode. > JSYS, opcode 120, was was not defined on early PDP-10s. ^^^ 104 On the KA10 with BBN pager, JSYS was implemented in hardware. On other processors, it's implemented in software. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Thu, 06 Nov 03 11:04:05 GMT Organization: UltraNet Communications, Inc. Lines: 70 Message-ID: References: X-Trace: UmFuZG9tSVZfGmZsjHr4H8xZGS2sTUx3OKmuNPZx8JoiY0Wx8MQTljMAUpOkYnRN X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 6 Nov 2003 12:07:15 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!feed3.news.rcn.net!208-59-181-221 Xref: redlance.franklin.ch alt.sys.pdp10:14176 In article , budd@csa.bu.edu (Phil Budne) wrote: >In article , wrote: >>I would guess that ITS' .CALL was similar to our CALLI. > >ITS .CALL was slightly more like the "CALL" UUO (opcode 40) than CALLI >(opcode 47). I've very rarely seen CALL used in code. That's because CALL was limited. When more thingies were seen to be needed the CALLI was invented so that adding a new CALL was a matter of adding and address to the end of the CALLI table and writing a routine that at that stored address. So, instead of adding a CALL (which was becoming a rare resource) programmers used the CALLI format and dispatch mechanisms. > ..That is; > > CALL [SIXBIT /EXIT/] > >instead of; > > CALLI 12 > >CALL support is present in 7.04, see label UCALL in >http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/01/10,7/ mon/uuocon.mac.html > >CALL's "Y" (right half(*)) field points to a word containing the >sixbit name of the function, and CALLI's "Y" field was an immediate >value for the function code. For both, AC field indicates an AC which >contains arguments (or a pointer to arguments), except when it doesn't >(when the EXIT CALL(I), takes a "1" in the AC field, it acts differently). > >ITS' .CALL UUO argument block contains both the name of the function, >and the arguments. Something hidden in CStacey's example is that the >instructions MOVE, MOVEI and MOVEM "happened" to include the right bit >patterns for "input", "immediate" and "output" arguments descriptors: > > .CALL [SETZ ? SIXBIT/LOAD/ ? MOVEI -1 ? SETZI DKIC] > >ITS CALLs did not require having a free AC at all, while the TOPS-20 >JSYS calls were wired to use ACs 1 and up for arguments. > >(*) the right half after address calculations are performed, and the >result is stored in monitor low core (or the User Page Table). I >don't recall ever seeing anyone use indexing or the indirect bit on a >CALLI, but it was common practice on LUUO's -- opcodes 0-37 which >trapped thru location 40 of the user address space. It had to be common that way. If you didn't indirect through 0-37 a site was limited to only that many calls. By having the indirect point to a table of dispatch addresses, the site now had 0-37 classes of calls. The reason there was a CALLI to match a CALL was to provide a way for user mode programs, most of which we had no control over, to "move" over to the new kind of calls. We did the same kind of transformation when we designed the FILOP. I/O calls. It was a lot easier to implement extension if the argument list for a UUO could be in memory rather than the ACs. There were only 17 of them and we envisioned arg lists to become longer. Generally, I would say that, if you see two kinds of the same UUO in TOPS-10, you will find a change in the standards when it was discovered that the UUO arguments were not extensible. /BAH Subtract a hundred and four for e-mail. ###### From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Thu, 6 Nov 2003 07:58:50 -0800 Organization: University of Washington Lines: 42 Message-ID: References: NNTP-Posting-Host: shiva0.cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 1068134332 41636 (None) 140.142.17.39 X-Complaints-To: help@cac.washington.edu In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!logbridge.uoregon.edu!news.u.washington.edu!140.142.17.34.MISMATCH!news.u.washington.edu!shiva0.cac.washington.edu!mrc Xref: redlance.franklin.ch alt.sys.pdp10:14177 On Thu, 6 Nov 2003 jmfbahciv@aol.com wrote: > >ITS .CALL was slightly more like the "CALL" UUO (opcode 40) than CALLI > >(opcode 47). I've very rarely seen CALL used in code. > That's because CALL was limited. Actually, I think that it's because CALL in the DEC monitor did a linear search for the SIXBIT name, which clearly would not scale as the number of calls got large. .CALL on ITS did a binary search which was much faster. The reason why JSYS was the way it was is that it originally was a machine instruction. JSYS 320 (the SWTCH JSYS) on Tenex would would dispatch through the 320th location of the JSYS dispatch table (location 1320), which contained FPC,,.SWTCH . This in turn stored the JSYS PC+1 in FPC, entered exec mode, and jumped to .SWTCH. That code consisted of: .SWTCH: DATAI APR,1 XCT MJRSTF MJRSTF normally contained JRSTF @FPC which would enter user mode and jump to the location after the JSYS. The important thing is that all the steps up to and including the jump to .SWTCH were implemented in hardware on the KA10 with BBN pager. User JSYS (E >= 1000) was also implemented by the hardware, but this time E was an address rather than an offset in a dispatch table, and it did not enter exec mode. Put another way, JSYS was somewhat like XJRSTF, only it used a dispatch table and entered exec mode if E<1000. TOPS-20 inherited that design, even though on the KL10 it was implemented entirely in software and thus would seem totally bizarre as a system call design. One of the great mysteries was why it was never implemented in microcode, even when they had space to do it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ###### From: dfevans@bcr10.uwaterloo.ca (David Evans) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Thu, 6 Nov 2003 16:46:19 +0000 (UTC) Organization: University of Waterloo Lines: 20 Message-ID: References: <3FA9FF17.DB3EC340@comcast.net> NNTP-Posting-Host: bcr10.uwaterloo.ca X-Trace: rumours.uwaterloo.ca 1068137179 27610 129.97.34.125 (6 Nov 2003 16:46:19 GMT) X-Complaints-To: abuse@uwaterloo.ca NNTP-Posting-Date: Thu, 6 Nov 2003 16:46:19 +0000 (UTC) X-Newsreader: trn 4.0-test72 (19 April 1999) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!cycny01.gnilink.net!cyclone1.gnilink.net!chi1.webusenet.com!news.webusenet.com!snoopy.risq.qc.ca!torn!news.uwaterloo.ca!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14178 In article <3FA9FF17.DB3EC340@comcast.net>, Charles Richmond wrote: >This idea was *not* lost on more modern processors. The Motorola >68000 family has the "line A" and "line F" instructions, which >also branch to an address stored at a specific location in lower >memory. This allowed "instructions" to be defined that actually >executed a subroutine to perform the task... > However, the "line A" and "line F"-style instructions are a little weird in that they are in fact implemented in hardware on some 68k-series CPUs. If code is not running on one of those CPUs then some software needs to emulate the instructions' operation. The TRAP instruction, on the other hand, always generates an exception. -- David Evans dfevans@bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual ###### From: shoppa@trailing-edge.com (Tim Shoppa) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: 6 Nov 2003 10:19:06 -0800 Organization: http://groups.google.com Lines: 20 Message-ID: References: <3FA9FF17.DB3EC340@comcast.net> NNTP-Posting-Host: 170.121.15.35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1068142747 1215 127.0.0.1 (6 Nov 2003 18:19:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 6 Nov 2003 18:19:07 +0000 (UTC) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews1.google.com!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14179 Charles Richmond wrote in message news:<3FA9FF17.DB3EC340@comcast.net>... > This idea was *not* lost on more modern processors. The Motorola > 68000 family has the "line A" and "line F" instructions, which > also branch to an address stored at a specific location in lower > memory. This allowed "instructions" to be defined that actually > executed a subroutine to perform the task... Surely they do more than "branch", they store a return address and probably some context somewhere too, right? The 8080 had RST 0-7, which were (both conceptually and naming-wise) halfway between "calls" and "software interrupts" (hadware interrupts consisted of jamming a RST instruction onto the bus). I think RST nominally stood for "restart" although "call" or "interrupt" would be more appropriate. ... not sure what the 8008 had, off the top of my head, but it must've had something similar. Tim. ###### From: dfevans@bcr10.uwaterloo.ca (David Evans) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Thu, 6 Nov 2003 18:25:33 +0000 (UTC) Organization: University of Waterloo Lines: 22 Message-ID: References: <3FA9FF17.DB3EC340@comcast.net> NNTP-Posting-Host: bcr10.uwaterloo.ca X-Trace: rumours.uwaterloo.ca 1068143133 30793 129.97.34.125 (6 Nov 2003 18:25:33 GMT) X-Complaints-To: abuse@uwaterloo.ca NNTP-Posting-Date: Thu, 6 Nov 2003 18:25:33 +0000 (UTC) X-Newsreader: trn 4.0-test72 (19 April 1999) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!news.cambrium.nl!news.cambrium.nl!news.cambrium.nl!amsnews01.chello.com!newsfeed1!bredband!snoopy.risq.qc.ca!torn!news.uwaterloo.ca!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14180 In article , Tim Shoppa wrote: >Charles Richmond wrote in message >news:<3FA9FF17.DB3EC340@comcast.net>... >> This idea was *not* lost on more modern processors. The Motorola >> 68000 family has the "line A" and "line F" instructions, which >> also branch to an address stored at a specific location in lower >> memory. This allowed "instructions" to be defined that actually >> executed a subroutine to perform the task... > >Surely they do more than "branch", they store a return address and >probably some context somewhere too, right? > Yes. All of that sort of thing is stored in an "exception stack frame" on the supervisor stack. -- David Evans dfevans@bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual ###### From: "Glen Herrmannsfeldt" Newsgroups: alt.sys.pdp10 References: <7bhqb.87041$9E1.439868@attbi_s52> Subject: Re: advice on setting up pdp-10 emulator Lines: 82 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: NNTP-Posting-Host: 12.228.234.203 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s53 1068160393 12.228.234.203 (Thu, 06 Nov 2003 23:13:13 GMT) NNTP-Posting-Date: Thu, 06 Nov 2003 23:13:13 GMT Organization: Comcast Online Date: Thu, 06 Nov 2003 23:13:13 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.space.net!feed.news.nacamar.de!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s53.POSTED!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14181 "Christopher C. Stacy" wrote in message news:uk76e3tp9.fsf@dtpq.com... > >>>>> On Thu, 06 Nov 2003 01:09:23 GMT, Glen Herrmannsfeldt ("Glen") writes: > Glen> "Christopher C. Stacy" wrote in message > Glen> news:uwuae4nc7.fsf@dtpq.com... > >> >>>>> On Wed, 05 Nov 2003 11:41:12 +0100, Andreas Davour ("Andreas") > Glen> writes: > >> > Andreas> So the UUO is part of the hardware, as is JSYS, and the > Andreas> different systems just used them differently? Or have I > Andreas> misunderstood completely? > >> > >> You understand exactly correctly. > > Glen> I would have said that they were not in the hardware, which is > Glen> what made them special, but the distinction is subtle. > > Glen> I would have said that UUO's are just invalid instructions to > Glen> the hardware, and the OS processes them. I am not sure I > Glen> understand JSYS, though. > > No, UUOs are are not "just invalid", and it is by no means > some hack or happy accident that they cause processor traps > that are used to call the operating system. > UUO stands for "Unimplemented User Operation"; this is not > referring to an invalid opcode. The intended purpose of UUOs > is for jumping into functional handlers provided either by the > user or by the operating system. UUO trapping behaviour is > well defined and is carefully designed for this specific purpose. > In effect, this allows the user or the OS to extend the machine > instruction set by providing meanings to a designated reserved > set of opcodes. > Opcodes 001 - 037 are reserved for user-defined routines, while > opcodes 040 - 077 are called MUUOs and are for system routines. > Both kinds of UUOs do the same thing: the processor stores the > instruction in location 40 and then executes whatever instruction > it finds in location 41. Whether this is done in EXEC mode or > USER mode depends on whether it was an MUUO or a regular UUO. "All UUO's are equal, but some are more equal than others." (I think that paraphrases a famous saying.) (snip) > If you execute an illegal opcode, the processor does something > a little bit different than what UUOs do. (The details depend > on what the instruction was and on what model processor you're > talking about.) And of course, some of those illegal opcodes > could mean something someday (as did JSYS), so you can't go > around writing code that just does any old random illegal > opcode and hope that you'll get UUO trapping behaviour. I am not sure what the "little bit different is". > By contrast, the UUO opcodes and (on later CPUs) the JSYS opcode > are specifically intended for the purpose of doing a certain kind > of function calling. They are just as valid opcodes as JRST is. Well, intent is important, but I was only considering it from the point of view of the hardware itself. Say someone was given a PDP-10 box, without any software, and reverse engineered it. Would that person find that UUO's were special, or not? I don't know. There is much in the hardware documentation that isn't actually special about the hardware. IBM hardware manuals explain that with three exclusive OR instructions one can swap the contents of two registers without storing into memory. I don't believe, though, that anything special went into the hardware to do that, but it is a natural property of the exclusive OR operator. Now, documenting the intent so that future processors don't redefine them for a different purpose is useful. So what do other illegal operations do? Also, what do 000-037 do in EXEC mode? -- glen ###### From: "Glen Herrmannsfeldt" Newsgroups: alt.sys.pdp10 References: <3FA9FF17.DB3EC340@comcast.net> Subject: Re: advice on setting up pdp-10 emulator Lines: 26 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: NNTP-Posting-Host: 12.228.234.203 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s53 1068160591 12.228.234.203 (Thu, 06 Nov 2003 23:16:31 GMT) NNTP-Posting-Date: Thu, 06 Nov 2003 23:16:31 GMT Organization: Comcast Online Date: Thu, 06 Nov 2003 23:16:31 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!feed.news.nacamar.de!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newspump.monmouth.com!newspeer.monmouth.com!newsfeed.mathworks.com!wn13feed!wn11feed!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s53.POSTED!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14182 "David Evans" wrote in message news:bodtsr$quq$1@rumours.uwaterloo.ca... > In article <3FA9FF17.DB3EC340@comcast.net>, > Charles Richmond wrote: > >This idea was *not* lost on more modern processors. The Motorola > >68000 family has the "line A" and "line F" instructions, which > >also branch to an address stored at a specific location in lower > >memory. This allowed "instructions" to be defined that actually > >executed a subroutine to perform the task... > > > > However, the "line A" and "line F"-style instructions are a little weird > in that they are in fact implemented in hardware on some 68k-series CPUs. > If code is not running on one of those CPUs then some software needs to > emulate the instructions' operation. The TRAP instruction, on the other > hand, always generates an exception. I thought there was some general system for co-processors, with the 68881 FPU one of the first to be defined. The 68851 MMU may have had its own special instructions, too. I do remember wondering about the possibility of putting two 68881's on the same 68020. -- glen ###### From: dfevans@bcr10.uwaterloo.ca (David Evans) Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Thu, 6 Nov 2003 23:27:56 +0000 (UTC) Organization: University of Waterloo Lines: 40 Message-ID: References: <3FA9FF17.DB3EC340@comcast.net> NNTP-Posting-Host: bcr10.uwaterloo.ca X-Trace: rumours.uwaterloo.ca 1068161276 7859 129.97.34.125 (6 Nov 2003 23:27:56 GMT) X-Complaints-To: abuse@uwaterloo.ca NNTP-Posting-Date: Thu, 6 Nov 2003 23:27:56 +0000 (UTC) X-Newsreader: trn 4.0-test72 (19 April 1999) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!nntp.cs.ubc.ca!torn!news.uwaterloo.ca!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14183 In article , Glen Herrmannsfeldt wrote: > >"David Evans" wrote in message >news:bodtsr$quq$1@rumours.uwaterloo.ca... >> However, the "line A" and "line F"-style instructions are a little weird >> in that they are in fact implemented in hardware on some 68k-series CPUs. >> If code is not running on one of those CPUs then some software needs to >> emulate the instructions' operation. The TRAP instruction, on the other >> hand, always generates an exception. > >I thought there was some general system for co-processors, with the 68881 >FPU one of the first to be defined. There is. I haven't read all of the details, but here's a little excerpt from the part of the 68881/68882 book that talks about it: All coprocessor operations are based on the F-line operation codes . . . which instruct the MPU to call upon a coprocessor for execution of the instruction. >The 68851 MMU may have had its own >special instructions, too. I don't think that I have the 68851 book so I can't check anything to do with those. >I do remember wondering about the possibility of >putting two 68881's on the same 68020. > It looks like it should be possible with some glue, but I don't know whether you could get them both working in parallel. -- David Evans dfevans@bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual ###### From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Thu, 6 Nov 2003 16:18:12 -0800 Organization: Networks & Distributed Computing Lines: 58 Sender: mrc@ndcms.cac.washington.edu Message-ID: References: <7bhqb.87041$9E1.439868@attbi_s52> NNTP-Posting-Host: nntp2.u.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 1068164301 13358 (None) 140.142.17.39 X-Complaints-To: help@cac.washington.edu In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!takemy.news.telefonica.de!telefonica.de!news.tiscali.de!feed.news.nacamar.de!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.mathworks.com!arclight.uoregon.edu!hammer.uoregon.edu!logbridge.uoregon.edu!news.u.washington.edu!140.142.17.34.MISMATCH!news.u.washington.edu!Shimo-Tomobiki.Panda.COM!MRC Xref: redlance.franklin.ch alt.sys.pdp10:14184 On Thu, 6 Nov 2003, Glen Herrmannsfeldt wrote: > Say someone was given a PDP-10 box, without any software, and reverse > engineered it. Would that person find that UUO's were special, or not? It depends upon the processor. For a KL or KS processor, "without any software" means "without microcode", and without microcode it isn't a PDP-10. > So what do other illegal operations do? It depends upon the processor. > Also, what do 000-037 do in EXEC mode? It depends upon the processor. :-) The only thing that can be said in general is: Opcodes 001-037 are "local UUOs" (LUUOs), which user application programs can define and use for their own purposes without misinterpretation as a system call. Similarly, the kernel can use them for internal purposes without fear that an application program can invoke them. Opcodes 040-077 are "monitor UUOs" (MUUOs) which the kernel can define and make available to application programs as system calls; similarly the kernel can call them itself. Opcode 104 is a hardware instruction on KA10 processors with BBN pager, and an MUUO on all other processors. Opcode 000 is an unassigned instruction. It, and other unassigned instructions, traps as an MUUO on most processors. However, no unassigned instruction can be used as a system call. Strictly speaking, this is a convention, but one that is strictly defined by the architecture. Some unassigned instructions are hardware instructions on older processors. For compatibility purposes, some operating systems implement these unassigned instructions in software as system calls that do what the old machine instruction did. Some unassigned instructions are defined as hardware instructions in future processors. Some operating systems implement these unassigned instructions in software as system calls that do what the new machine instruction will do. One unassigned instruction, 247, is defined as a hardware instruction that is implemented locally by the customer. It is a noop on some processors that does not implement, and traps as an MUUO on other processors. Some instructions are assigned, but are not permitted by the processor mode; for example, user programs can not halt the processor or do most hardware I/O. These generally trap as MUUOs. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ###### From: "Glen Herrmannsfeldt" Newsgroups: alt.sys.pdp10 References: <7bhqb.87041$9E1.439868@attbi_s52> Subject: Re: advice on setting up pdp-10 emulator Lines: 77 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: NNTP-Posting-Host: 12.228.234.203 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s54 1068177684 12.228.234.203 (Fri, 07 Nov 2003 04:01:24 GMT) NNTP-Posting-Date: Fri, 07 Nov 2003 04:01:24 GMT Organization: Comcast Online Date: Fri, 07 Nov 2003 04:01:24 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s54.POSTED!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14185 "Mark Crispin" wrote in message news:Pine.WNT.4.60.0311061601370.2240@Shimo-Tomobiki.Panda.COM... > On Thu, 6 Nov 2003, Glen Herrmannsfeldt wrote: > > Say someone was given a PDP-10 box, without any software, and reverse > > engineered it. Would that person find that UUO's were special, or not? > > It depends upon the processor. For a KL or KS processor, "without any > software" means "without microcode", and without microcode it isn't a > PDP-10. Well, some people call it firmware, not so hard and not so soft. I would say that the microcode stays, but the microcode source with comments doesn't. > > So what do other illegal operations do? > It depends upon the processor. > > Also, what do 000-037 do in EXEC mode? > It depends upon the processor. :-) > The only thing that can be said in general is: > Opcodes 001-037 are "local UUOs" (LUUOs), which user application programs > can define and use for their own purposes without misinterpretation as a > system call. Similarly, the kernel can use them for internal purposes > without fear that an application program can invoke them. > Opcodes 040-077 are "monitor UUOs" (MUUOs) which the kernel can define and > make available to application programs as system calls; similarly the > kernel can call them itself. > Opcode 104 is a hardware instruction on KA10 processors with BBN pager, > and an MUUO on all other processors. > Opcode 000 is an unassigned instruction. It, and other unassigned > instructions, traps as an MUUO on most processors. However, no unassigned > instruction can be used as a system call. Strictly speaking, this is a > convention, but one that is strictly defined by the architecture. Just like S/360, where X'00' is permanently undefined. > Some unassigned instructions are hardware instructions on older > processors. For compatibility purposes, some operating systems implement > these unassigned instructions in software as system calls that do what the > old machine instruction did. For S/360, S/370, and ESA/390 it was usually software emulation so that older processors could do what new ones did. The 360/85 started extended precision (112 but mantissa) floating point and a software emulator was supplied for older machines. DXR, extended precision divide was emulated on all machines for many years until it was finally implemented in hardware, I believe in ESA/390. > Some unassigned instructions are defined as hardware instructions in > future processors. Some operating systems implement these unassigned > instructions in software as system calls that do what the new machine > instruction will do. > One unassigned instruction, 247, is defined as a hardware instruction that > is implemented locally by the customer. It is a noop on some processors > that does not implement, and traps as an MUUO on other processors. You mean like a breadboard patch area where the customer can add their own hardware, and the processor will use it for 247? > Some instructions are assigned, but are not permitted by the processor > mode; for example, user programs can not halt the processor or do most > hardware I/O. These generally trap as MUUOs. Like any good protected mode processor. -- glen ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator References: <3FA9FF17.DB3EC340@comcast.net> Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 06 Nov 2003 21:11:12 -0800 Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 6 Nov 2003 21:12:21 -0800, ruckus.brouhaha.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.he.net!news.kjsl.com!news.spies.com!ruckus.brouhaha.com Xref: redlance.franklin.ch alt.sys.pdp10:14186 Charles Richmond writes: > This idea was *not* lost on more modern processors. The Motorola > 68000 family has the "line A" and "line F" instructions, which > also branch to an address stored at a specific location in lower > memory. This allowed "instructions" to be defined that actually > executed a subroutine to perform the task... However, on the PDP-10, customers (and the monitor deveoplers) were *supposed* to use UUOs; that's what they were there for. On the 68000, the line A and line F traps were there because Motorola reserved that part of the opcode space for new instructions (either for the main processor or a coprocessor). They were explicitly stated to not be intended for customer use. The 68000 provides the TRAP instruction for customer use, and it is basically equivalent in function to the PDP-10 MUUO. Apple *ignored* the Motorola documentation, and used line A instructions as software traps in the Macintosh, just like the developers of the IBM PC BIOS ignored Intel's documentation on which INT instructions were available for software vs. reserved for future hardware. As a result, Motorola chose not to use line A for new instructions or coprocessors. Intel, on the other hand, *did* use the low-numbered interrupts in their later processors (286 etc.), so that there were conflicts with the PC BIOS. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Fri, 07 Nov 03 09:26:48 GMT Organization: UltraNet Communications, Inc. Lines: 58 Message-ID: References: X-Trace: UmFuZG9tSVZGXH2YWMFNJ18c99/7L+9ZhBml9zYeIryxcdFSeHbN06Vd039+5KRv X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 7 Nov 2003 10:30:07 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!easynet-quince!easynet.net!peer01.cox.net!cox.net!rcn!feed3.news.rcn.net!207-172-216-231 Xref: redlance.franklin.ch alt.sys.pdp10:14187 In article , Mark Crispin wrote: >On Thu, 6 Nov 2003 jmfbahciv@aol.com wrote: >> >ITS .CALL was slightly more like the "CALL" UUO (opcode 40) than CALLI >> >(opcode 47). I've very rarely seen CALL used in code. >> That's because CALL was limited. > >Actually, I think that it's because CALL in the DEC monitor did a linear >search for the SIXBIT name, which clearly would not scale as the number of >calls got large. That's possible, too. I would think that keeping the CALL scheme would make patching one in hard to do. ISTR that a patching trick could also use a CALL, but I'm not sure about that. Somehow, the LIGHTS UUO rings a bell about being the UUO of choice. > .. .CALL on ITS did a binary search which was much faster. Oh, faster than doing a SIXBIT compare through a table...I was thinking how it could be faster than a indexed JRST. > >The reason why JSYS was the way it was is that it originally was a machine >instruction. JSYS 320 (the SWTCH JSYS) on Tenex would would dispatch >through the 320th location of the JSYS dispatch table (location 1320), >which contained FPC,,.SWTCH . This in turn stored the JSYS PC+1 in FPC, >entered exec mode, and jumped to .SWTCH. That code consisted of: > >..SWTCH: > DATAI APR,1 > XCT MJRSTF > >MJRSTF normally contained JRSTF @FPC which would enter user mode and jump >to the location after the JSYS. > >The important thing is that all the steps up to and including the jump to >..SWTCH were implemented in hardware on the KA10 with BBN pager. > >User JSYS (E >= 1000) was also implemented by the hardware, but this time >E was an address rather than an offset in a dispatch table, and it did not >enter exec mode. > >Put another way, JSYS was somewhat like XJRSTF, only it used a dispatch >table and entered exec mode if E<1000. > >TOPS-20 inherited that design, even though on the KL10 it was implemented >entirely in software and thus would seem totally bizarre as a system call >design. One of the great mysteries was why it was never implemented in >microcode, even when they had space to do it. I don't know much about that flavor of DEC politics. It seemed like it took forever to get anything done to the microcode, but I have no idea what hardware engineering's process to get a project started and done was. /BAH Subtract a hundred and four for e-mail. ###### From: Mark Crispin Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Fri, 7 Nov 2003 12:12:35 -0800 Organization: University of Washington Lines: 21 Message-ID: References: <7bhqb.87041$9E1.439868@attbi_s52> NNTP-Posting-Host: shiva0.cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.u.washington.edu 1068235957 13556 (None) 140.142.17.38 X-Complaints-To: help@cac.washington.edu In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!enews.sgi.com!hammer.uoregon.edu!logbridge.uoregon.edu!news.u.washington.edu!140.142.17.34.MISMATCH!news.u.washington.edu!shiva0.cac.washington.edu!mrc Xref: redlance.franklin.ch alt.sys.pdp10:14190 On Fri, 7 Nov 2003, Glen Herrmannsfeldt wrote: > > One unassigned instruction, 247, is defined as a hardware instruction that > > is implemented locally by the customer. It is a noop on some processors > > that does not implement, and traps as an MUUO on other processors. > You mean like a breadboard patch area where the customer can add their own > hardware, and the processor will use it for 247? In the KA and KI, you would implement it by modifying the hardware. In the KL and KS, it was microcode. The most common implementation was as CIRC, which first appeared on the MIT ITS KA10s. CIRC ("circulate") is a ROTC with AC+1 going the other way. This is actually useful in a number of ways. For example, CIRC AC,^D36 will reverse the bits in a doubleword, and CIRC AC,-n (where AC+1 is zero initially) will do an unsigned divide by 2^n (IDIVI does a signed divide). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ###### From: jmfbahciv@aol.com Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Sun, 09 Nov 03 11:26:34 GMT Organization: UltraNet Communications, Inc. Lines: 9 Message-ID: References: X-Trace: UmFuZG9tSVbAJOKEq+59Y6xQ2HRkdKW7W4H2lunbDVVhCsA1ZhlVrSwEOtoIpCye X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 9 Nov 2003 12:30:14 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!feed3.news.rcn.net!207-172-216-19 Xref: redlance.franklin.ch alt.sys.pdp10:14196 In article , Lord Isildur wrote: Did you get your questions answered? /BAH Subtract a hundred and four for e-mail. ###### From: Lord Isildur Newsgroups: alt.sys.pdp10 Subject: Re: advice on setting up pdp-10 emulator Date: Sun, 9 Nov 2003 09:27:57 -0500 (EST) Organization: Carnegie Mellon, Pittsburgh, PA Lines: 19 Message-ID: References: NNTP-Posting-Host: smtp3.andrew.cmu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: bb3.andrew.cmu.edu 1068388078 13943 128.2.10.83 (9 Nov 2003 14:27:58 GMT) X-Complaints-To: advisor@andrew.cmu.edu NNTP-Posting-Date: 9 Nov 2003 14:27:58 GMT In-Reply-To: Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.news.ucla.edu!usenet01.sei.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail Xref: redlance.franklin.ch alt.sys.pdp10:14197 yes, and a lot of other interesting stuff besides :-) thanks to all, isildur On Sun, 9 Nov 2003 jmfbahciv@aol.com wrote: > In article , > Lord Isildur wrote: > > > Did you get your questions answered? > > /BAH > > Subtract a hundred and four for e-mail. >