From rt11@iptvax.ENET.dec.com Thu Oct 30 13:39:47 1997 Received: by alph02.triumf.ca; id AA02054; Thu, 30 Oct 1997 13:39:47 -0800 Resent-Message-Id: <9710302139.AA02054@alph02.triumf.ca> Resent-Date: Thu, 30 Oct 1997 13:02:52 PST Resent-From: Resent-To: Received: from mail11.digital.com by REG.TRIUMF.CA (MX V4.0-1 VAX) with SMTP; Thu, 30 Oct 1997 13:02:48 PST Received: from us7rmc.bb.dec.com (us7rmc.bb.dec.com [16.53.0.29]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA10249; Thu, 30 Oct 1997 15:35:32 -0500 (EST) Received: from iptvax.enet by us7rmc.bb.dec.com (5.65/rmc-17Jan97) id AA10068; Thu, 30 Oct 97 15:35:28 -0500 Message-Id: <9710302035.AA10068@us7rmc.bb.dec.com> Received: from iptvax.enet; by us7rmc.enet; Thu, 30 Oct 97 15:35:31 EST Date: Thu, 30 Oct 97 15:35:31 EST From: 30-Oct-1997 1335 X-Mx-Warning: Warning -- Invalid "To" header. To: mail11:;@us7rmc.bb.dec.com@us7rmc.bb.dec.com@unknown.domain; (@rt11) Apparently-To: billy@mix.com, baldwin@shop-pdp.kent.edu, twelmers@netcom.com, timclarke@alumni.stanford.org, jimc@netcom.com, shal@alumni.caltech.edu, frisbie@flying-disk.com, sbrook@concentric.net, rcpassoc@netcom.com, shoppa@triumf.ca, bschor@vms.cis.pitt.edu, chip@mentec.com Subject: (via RT11): ASCII six-monitors.doc Status: RO From: IPTVAX::US3RMC::"shoppa@alph02.triumf.ca" "Tim Shoppa" 30-OCT-1997 12:35:57.28 To: iptvax::rt11 (30-Oct-1997 1135) CC: Subj: ASCII six-monitors.doc OK, I managed to extract most of the "flat text" from Bob Schor's talk "Six-monitors.doc". Notice the complete lack of formatting and tables in the document below :-( Tim. Multiple Monitors in RT-11 Version 5.7 Bob Schor Department of Otolaryngology University of Pittsburgh 200 Lothrop Street Pittsburgh, PA 15213 (412) 647-2116 bschor@vms.cis.pitt.edu There are six RT-11 Version 5.7 monitors. They can be logically grouped in a 2 * 3 matrix, with an almost-logical naming scheme. The first division is based on the number of jobs the monitors can handle, and distinguishes between the "B series" and the "M series". [This is the only example of an illogical name for historic reasons, we call the multi-job simple monitor "FB" instead of the logical alternative, "SM"]. Besides looking at the monitor name, you can distinguish between the B and M monitors by examining the RMON offset $JOBS -- if it is 1, this is a B series; if it is greater than 1, an M series. Similarly, within IND there is a parameter which is either 1 or a larger number, depending on the monitor series. The second dimension in the matrix has three entries. We've briefly mentioned the "S-series" (the Simple Monitors SB and SM, er, FB). One can test for the presence of the S series by examining the KT11$ bit of RMON offset $CNFG1 (Configuration Word 1) if it is clear, then memory management is not running, implying this an S-series monitor. In IND, the symbol is false. If the KT11$ bit is set (or is true), then we are running either an X or Z monitor. Next come the "X-series", the Extended Memory monitors XB and XM. These monitors feature a virtual environment with the monitor and its services executing in Kernel space, and the user's routines kept separate in User space. As in the earlier versions of RT-11, I and D space remain locked together, so there is no real distinction between program and data spaces. To distinguish between these two, one must examine $CNFG3, bit CF3.SI if clear, we cannot support separated I/D space, so we must be running the X series (I'm assuming KT11$ was also checked and found to be set). There's also been a new logical symbol added to IND to distinguish between X and Z monitors if is false, and is true, this is the X series. The last, and newest, series of monitors are the Z monitors, ZB and ZM. These provide a "completely virtual environment", featuring access to Kernel, Supervisor, and User modes, with full control over memory mapping. This monitor will support separated I and D space programs as well as Supervisor Libraries, allowing you to potentially quadruple the memory space available to your program. [Actually, since you can even use the relatively-scarce Kernel memory via a user-written handler, you can even squeeze out a little more than four times 64kB of directly-available memory space]. With all of these monitors, how do you choose rationally between them? In some cases, your needs force a choice. For example, if you are running multiple jobs, you need the M series, instead of the B series. If you want to take advantage of the completely virtual environment (to use Supervisor Libraries, for example, or to take advantage of separated I/D space), you need to run a Z monitor. What if your needs are "none of the above"? What if you have a program which ran just fine under RT-11 Version 5.5? In principle, it will run basically unmodified under any of the monitors. How do you choose? Here are some rules of thumb. (1) Always run ZM. It is the biggest, slowest monitor of the bunch, but these days, PDP-11s come with 4Mb of memory, so size isn't an issue, and the speed difference (for most tasks) will probably not be noticable. Anything which runs under any of the other monitors will run fine under ZM. When running in this environment, SET RUN VBGEXE to allow VBG to be the default loader, which will vastly improve the performance of "VBG-aware" programs, such as Macr@0`@T run them under VBG. You can use SIPP to patch $JSX, the Job Definition Word at location 4, to try out various VBG options. The bit settings of interest are: Value Bit name Meaning REQID$ Job requires separated I/D space USEID$ Job uses separated I/D space, if possible REQSM$ Job requires Supervisor mode USESM$ Job uses Supervisor mode, if possible ALL64$ Ask VBG for 64kB of memory IOPAG$ Ask VBG to map to I/O page (PAR 7) NOVBG$ Job cannot run under VBG VBGEX$ Job can (and should be) run under VBG The second rule of thumb is that if you need to tweak out some additional speed, for example when doing a real-time task, drop back to the B series. Here you will benefit because the monitors know there is only a single task, there is no need to context switch between jobs, so don't bother unnecessarily messing with registers, checking monitor tables, etc. If you want to push it to the limit, and you don't have a space problem, you can run SB. Another talk discussed the Whys and Wherefores of SB, so I won't repeat them here. Note that the reasonable upgrade path for SB (if space is a problem) is ZB, which trades off a little speed for a lot of memory. The Z monitors in RT-11 Version 5.7 support running programs which involve separated I/D space. What you, as a programmer, need to consider to take advantage of this completely virtual environment which allows you to have 64kB of program code directly addressing 64kB of user data? The main trick in getting programs to run in a separated I/D space environment is to get the machine properly set up, with the programs in I-space and the data in D-space. RT-11 Version 5.7 uses VBGEXE as the run-time loader to take .SAV images in the new executable file format and load them properly. The Linker has also been made more savvy. The mechanism used to specify what portions of your program are instructions (I-space) and what are data (D-space) is the .PSect mechanism. If you've been diligent, have read the manuals, and have followed the Recommended Coding Practices, you have already been using .PSects properly to separate the code and data areas of your programs. On the other hand, if you have been relying on the past twenty years' experience to tell you |.PSects don't matter, you have to relearning to do! What are the basic rules? There is really only one keep your code physically separated from your data, and place them in their proper .PSects. Note that immediate mode "data", as in "Mov #BufAdr, R0" will still work, as the datum, here #BufAdr, really comes from I-space. What doesn't work? In-line arguments will fail. This is a technique which Fortran has used, and may still be using. A Fortran-style call is as follows: #ArgList, R5 Call SubRtn ..... ArgList:.Byte ;N is number of arguments .Byte ;Fortran only uses low byte .Word AdArg1 ;Address of argument 1 .Word AdArg2 ;and so on Good coding practice, required for I/D separation, is to place the argument list in a Data .PSect. However, it is very easy to get lazy and take advantage of the unused byte at the top the list if you make it 1, and interpret the first data word as an instruction, the sequence .Byte N, 1 will be executed as the branch instruction .+2+<2*N> which has the nifty effect of jumping you right over the argument list. The bad news is that it breaks I/D separation (so don't do it!). Normal Default Paragraph Font Paragraph Code Bob Schor"E:\PDP11\RTVer565\Six Monitors.doc @HP LaserJet 5P/5MP PostScript LPT1: PSCRIPT HP LaserJet 5P/5MP PostScript HP LaserJet 5P/5MP PostScript Custom page 1 Custom page 2 Custom page 3 HP LaserJet 5P/5MP PostScript Custom page 1 Custom page 2 Custom page 3 Times New Roman Symbol Arial Courier New $Multiple Monitors in RT-11 Version 5 Bob Schor Bob Schor Microsoft Word Document MSWordDoc Word.Document.6 Multiple Monitors in RT-11 Version 5 Bob Schor Normal.dot Bob Schor Microsoft Word for W Multiple Monitors in RT-11 Version 5 indows 95 Multiple Monitors in RT-11 Version 5 % ====== Internet headers and postmarks ====== % Received: from mail13.digital.com by us3rmc.cxo.dec.com (5.65/rmc-17Jan97) id AA00868; Thu, 30 Oct 97 12:29:18 -0700 % Received: from alph02.triumf.ca (alph02.Triumf.CA [142.90.114.18]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA30616 for ; Thu, 30 Oct 1997 14:16:20 -0500 (EST) % Received: by alph02.triumf.ca; id AA04844; Thu, 30 Oct 1997 11:13:50 -0800 % From: Tim Shoppa % Message-Id: <9710301913.AA04844@alph02.triumf.ca> % Subject: ASCII six-monitors.doc % To: iptvax::rt11 (30-Oct-1997 1135) % Date: Thu, 30 Oct 1997 11:13:49 -0800 (PST) % In-Reply-To: <9710301836.AA05159@us7rmc.bb.dec.com> from "30-Oct-1997 1135" at Oct 30, 97 01:36:22 pm % X-Mailer: ELM [version 2.4 PL22] % Content-Type: text