.PAGE SIZE 58, 85 .NONUMBER .LEFT MARGIN 10 .RIGHT MARGIN 75 .AUTOPARAGRAPH # .SKIP 5 .CENTER THE RSX MULTI-TASKER .SKIP .CENTER January 1989 .SKIP .CENTER "In hoc signo foobar" .SKIP .CENTER Fine Realtime Commentary Since 1975 .SKIP 6 .CENTER ^&TABLE OF CONTENTS\& .SKIP .LITERAL RSX SIG NEWS Editor's Corner RSX-1 Submitting Articles to the Multi-Tasker RSX-1 Bulletin Board Notes RSX-2 Chairman's Corner RSX-2 ARTICLES Reading a VMS BACKUP tape via RSX RSX-3 Update on Bit Counting RSX-4 Performance Notes on Bit Counting RSX-7 As Time Clunks On RSX-9 .END LITERAL .SKIP 10 Opinions expressed in the Multi-Tasker are those of individual members. They do not represent the official position of the RSX SIG or that of DECUS leadership in general. .PAGE .CENTER ^&RSX SIG NEWS\& .SKIP 2 .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Editor's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .SKIP 4 .CENTER Editor's Corner .SKIP .LITERAL Jim McGlinchey, Managing Editor Phil Hannay, Production Editor Bruce Mitchell, Minister of Propaganda .END LITERAL .SKIP This month's articles were submitted a while back and have not yet appeared in print. The delay does not appear to have affected their pertinence. .TEST PAGE 15 .SKIP 2 .CENTER ----- Submitting Articles to the Multi-Tasker ----- You are encouraged to submit articles to the Multi-Tasker. No article is too big or too small. They can be serious or funny, and of any techinical level. Please submit machine readable media if possible. Hardcopy submissions are okay if they are fairly short. Illustrations and drawings that can be photocopied may accompany the article. Most any media is acceptable, however RX50, RX01/2, TK50 and 1600 BPI magtape are preferred. All RSX volume formats are acceptable, and VMS formats are also acceptable on RX50, TK50 and 1600 BPI magtape. You can also submit articles through the RSX bulletin board system at (612) 777-7664. Kermit the file into your account and then send it via MAIL to username MULTITASKER. The Multi-Tasker begins life as a RUNOFF file, so feel free to submit your articles in RUNOFF format. The page size will be 80 columns by 58 lines, with the left margin at 10 and right margin at 75. Use literal format for code examples. If you change margins, use incremental changes rather than absolute. Mail your articles and other submissions to the expansive Multi-Tasker offices: .LITERAL Phil Hannay Cargill Research Bldg Box 9300 Minneapolis, MN. 55440 tel. 612-475-5433 (daytime) .END LITERAL .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Bulletin Board Notes .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Bulletin Board Notes .SKIP The RSX Bulletin Board is still going strong. Software availability: RSX MAIL, Kermit, old issues of The Multi-Tasker and various other items. Free advice from everybody who logs in too. The system can always use additional hardware. Anything, including archaic items. We are still looking for an RL02 drive. Contact Jim Bostwick, at 612-475-6264 (daytime) if you wish to donate some equipment. The BBS number: 612-SPR-PONG (612-777-7664). This line is autobaud 110 - 1200 baud. To request an account, log in with account name ACCOUNT, password REQUEST. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Chairman's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .test page 15 .skip 4 .center Chairman's Corner .SKIP .center Jim Bostwick .skiP Publication lead-times being what they are, I'm still getting over my Thanksgiving pig-out (or turkey-out) as I write. You, of course, will be just about over your New-Year's party as you read it. I spent part of the long weekend poking around in some old SIG tapes, mostly looking for 'lost' programs. There are plenty of them out there - programs which did neat things, but which haven't been updated since 11M-V3.2 or whatever, and which no longer work 'out of the box'. Many don't understand named directories, for example. A suprising number of these need only to be recompiled and taskbuilt. Others may need more work, such as a very good version of Startrek which needed a new overlay structure to accomodate the growth in FCS since 1982! [ Holidays are usually when I fool around with RSX games, too! ] The point is that there are a lot of good programs on the SIG tapes that just need sprucing up to be as useful today as they were 'back then'. If you have worked over one of your favorites - even just cleaned up the taskbuild file - please re-submit it to the next SIG tape. You can submit to the SIG tapes even though you can't attend Symposia. If you don't know anyone who is going, or if you don't have 1600BPI magtape, contact me at the RSXBBS (instructions above), and we'll get your submission there somehow. Please do this well in advance, as the weeks prior to a symposia are generally a true madhouse. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Articles .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .PAGE .CENTER ^&ARTICLES\& .SKIP 2 .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Reading a VMS BACKUP tape via RSX .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Reading a VMS BACKUP tape via RSX .SKIP 2 .CENTER Dr. Adrian Bottoms .CENTER RSX SIG Chair - UK, Ireland, and Middle East Chapter .CENTER XDT Computer Systems Ltd. ,9 The Square .CENTER Keyworth, Notts NG12 5JT, Great Britain .SKIP 2 In spite of being a long standing PDP-11/RSX shop we have recently purchased a VAXstation 2000 for playing with VMS. The VAX2000 has an RD53 and a RX33 floppy drive. I was recently faced with a problem of installing a software product under VMS for which I had the distribution only on half inch magtape written with VMS BACKUP. The software developers have structured their release kit to use the VMSINSTAL procedure. Since our half inch drive lives on the RSX machine I had no way of reading the tape directly. Although the RSX world has a utility called BRU which serves a similar function to VMS BACKUP there is no utility which will read VMS BACKUP tapes under RSX. Unwilling to be beaten by such a minor incovenience and knowing a little about BRU tape formats I did some investigation and found that BRU and BACKUP have one thing in common (apart from incompatible tape formats!): They both write tapes structured as ANSI Format D with each save set appearing as a FILE on the tape. This gave me some room to maneuver. The following sequence of actions allowed me, some 15 minutes later, to have the software product installed and running on the VAX. .SKIP 2 .lm +9 .INDENT -4 1.##On the RSX machine mount the VMS BACKUP tape under MTAACP as a Files-11 volume and do a directory listing using PIP. This showed the presence of 'files' PAKM010.A and SQZ021.A. I was interested only in PAKM010.A. Each of these 'files' corresponds to a BACKUP saveset. .SKIP .INDENT -4 2.##Initialize an RX33 floppy under RSX and mount it. Copy with PIP PAKM010.A to the floppy. Since VMS BACKUP places its savesets in [000000] when writing them to a disc, rename PAKM010.A to place it into the RSX directory [000,000]. Dismount the floppy. Carry floppy across to the VAX. (Remember, this is a Files-11 ODS-1 floppy). .SKIP .INDENT -4 3.##Load the floppy into the VAX and tell VMSINSTAL to get on with the installation. Everything goes OK for a while, then VMSINSTAL starts griping and moaning, and finally fails. .SKIP .INDENT -4 4.##Mount the ODS-1 floppy under VMS and then copy PAKM010.A to the RD53. INIT/DENS=DOUBLE $FLOPPY1 to make the floppy FILES-11 ODS-2. Copy PAKM010.A 'file' to $FLOPPY1:[000000]. .SKIP .INDENT -4 5.##Turn VMSINSTAL loose on the floppy to install PAKMANAGER. This time the product is installed without problems and passes the IVP. .SKIP .INDENT -4 6.##Pat self on back. .LM -9 There are a few other points that need mentioning. First, PIP must be installed with a very large increment to cope with the block size of the VMS BACKUP tape. Second, this procedure works only if the saveset fits on a single floppy - although a bit of programming to split a file into pieces and then re-assemble it could get around this. I was only able to achieve this bit of trickery becuse whoever designed the tape format for BRU and BACKUP decided to use ANSI format. I don't really understand why this decision was taken, but I am very grateful that it was. This structure opens up some interesting possibilities for creative BRU/BACKUP save set manipulation and recovery from problems with tape errors, since the backup sets on a tape may be manipulated with standard system utilities. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Update on Bit Counting .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Update on Bit Counting .SKIP 2 .CENTER Richard Neitzel .CENTER 312 Laveta Pass .CENTER Golden, CO###80401 .SKIP 2 Recently I sent in a brief Macro routine to count the number of bits set in a word. Yes, it didn't work and I admit I headspaced the example - I suppose you never forget that BIT does not change the destination. However, a new algorithm that is faster in most cases is presented here, and this one does work! And for you quibblers, it handles the zero case, but my quibble is that you should test for zero before the call to avoid the overhead of a subroutine call. (Editor's note: I think it wise to let the subroutine check and return 0. Saves unnecessary repetition of test code in the mainline.) This algorithm relies on a form of parallel addition, adding first one, then two, then three and finally four bit pairs to determine the number of set bits. The code is a bit longer then the earlier algorithm, but since it executes once instead of looping, it is faster for cases where several bits are set. Based on testing, this is faster at about 4 bits set. The earlier form is much faster for 1-2 bits and about the same for 3-4 bits. In the 11-16 bit range the new algorithm is almost two times faster. The following examples are in Macro-11 and C. The Macro routine gives examples of both the Fortran (delineated by {}) and DECUS C (delineated by []) calling conventions. C code is also shown but Fortran users wishing to code directly in Fortran are left to adapt the algorithm on their own. .SKIP 2 .LITERAL .SBTTL BITCNT Count Bits in a Word .GLOBL BITCNT Fortran call: Call BITCNT (WORD, COUNT) C call: count = bitcnt(word); BITCNT: {MOV @2(R5), R0 ; Get word to test. } [MOV SP, R0 ; Grab stack frame MOV R1, -(SP) ; Push R1 on stack MOV 2(R0), R0 ; Get word to test. ] BEQ DONE ; If zero, don't bother MOV R0, R1 ; Copy it into R1 BIC #125252, R1 ; Clear every odd bit ASR R0 ; Shift right BIC #125252, R0 ; Clear odd bits again ADD R1, R0 ; Now add 1 bit pairs MOV R0, R1 ; Copy result into R1 BIC #146314, R1 ; Clear alt. 2 bit pairs ASH #-2, R0 ; Shift right 2 bits BIC #146314, R0 ; Clear again ADD R1, R0 ; Add 2 bit pairs MOV R0, R1 ; Copy result into R1 BIC #377, R1 ; Clear low byte BIC #177400, R0 ; Clear high byte SWAB R1 ; Swap bytes ADD R1, R0 ; Add 3 bit pairs MOV R0, R1 ; Copy result into R1 BIC #177760, R0 ; Save only lower 4 bits ASH #-4, R1 ; Shift right 4 bits ADD R1, R0 ; Add 4 bit pairs DONE: {MOV R0, @4(R5) ; Done, return result. } [MOV (SP)+, R1 ; Done, restore R1. ] RETURN ; Return to the caller .END LITERAL .SKIP Here is the same bit couting routine coded in DECUS C: .SKIP 2 .LITERAL int bitcnt(word) int word; { register int j,k; if (word == 0) return(0); j = word; k = j & 0x5555; j >>= 1; j &= 0x5555; j += k; k = j & 0x3333; j >>= 2; j &= 0x3333; j += k; k = j & 0377; j &= 0177400; j = swabi(j); j += k; k = j & 0xf; j >>= 4; j += k; return(j); } .END LITERAL .SKIP If you code in DECUS C, you can avoid the overhead of the function call and eliminate three lines of code by modifying the assembler output. Replace the push of the integer on the stack with "SWAB variable", and take out the subroutine call and the two lines after it that return the swapped value. It's not a lot, but sometimes every little bit helps. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Performance Notes on Bit Counting .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER Performance Notes on Bit Counting .SKIP 2 .CENTER Bruce R. Mitchell .CENTER Machine Intelligence and Industrial Magic .CENTER PO Box 77 .CENTER Minnesota City, MN###55959 .SKIP 2 As a Multi-Tasker editor I look at a lot of code. The bit-counting routine above is an interesting problem - one I thought I could do better with. For amusement, I coded the "classical" shift and count routine and a nibble-counting table-lookup routine to see what the relative performance was of each as opposed to Neitzel's bit pair method. Here is the classical shift and count routine used for the in the performance test: .SKIP 2 .LITERAL BITCNT: CLR R2 ; Zero the result MOV @2(R5), R0 ; Load argument into R0 BEQ 20$ ; If zero, exit now MOV #16., R1 ; We shift 16 times 10$: BIT #1, R0 ; Bottom bit set? BEQ 11$ ; If not, don't increment INC R2 ; Increment result 11$: ASR R0 ; Bump down next bit SOB R1, 10$ ; And loop for next bit MOV R2, @4(R5) ; Return the result 20$: RETURN ; Return to the caller .END LITERAL .SKIP And here is a routine which looks up the number of bits set in the current lowest nibble in a table. I got the idea for this from the CRC-16 code used in RSX DECnet. Note that it can be made to go even faster by processing bytes rather than nibbles and making BITTBL 256 entries in size (viz, 2**8 rather than 2**4). Then no looping is necessary, just a SWAB and BIC. I was too lazy to figure out the values for the byte table. .SKIP 2 .LITERAL BITTBL: .WORD 0,1,2,1,2,2,3,1,2,2,3,2,3,3,4 BITCNT: CLR @4(R5) ; Zero the result MOV @2(R5), R0 ; Load argument into R0 BEQ 20$ ; If zero, exit now MOV #4, R1 ; We shift 4 times 10$: MOV R0, R2 ; Copy value into R2 BIC #177760, R2 ; Leave only bottom nibble ASL R2 ; For word offset ADD BITTBL(R2), @4(R5) ; Add bit count to result ASH #-4, R0 ; Shift down next nibble SOB R1, 10$ ; And loop for next nibble 20$: RETURN ; Return to the caller .END LITERAL .SKIP The test program was run on an unloaded PDP-11/34A without cache, running RSX-11M-Plus V1.0 Update A. The results are thus indicative of the true performance of these routines. For classical shift and count, 65K test iterations: 12.3 seconds. For nibble counting, 65K test iterations: 7.4 seconds. For Neitzel's bit pair algorithm, 65K test iterations: 4.6 seconds. As you can see, Neitzel's bit pair algorithm was the best performer. Some ya win, some ya lose. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT As Time CLUNKS On .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 4 .CENTER As Time CLUNKS On .SKIP 2 .CENTER Peter Stadick .CENTER Cargill, Inc. .CENTER Commodity Marketing Division .CENTER P.O. Drawer AR, Reserve, LA 70084 .SKIP 2 Realtime control software is often required to record the time events occured and be able to manipulate those time values. The problem has been the lack of a convenient way to record those times in a format the could be compatible with other software packages, calculate new time values from existing time values and yet do this in some uniform "generic standard". Believe it or not a method does exist, "clunk" time. A "clunk" is a unit of time equal to 100 nanoseconds or thats 10 million clunks per second. A clunk time (date/time) is defined as the number of clunks, expressed as a 64-bit unsigned integer, since November 17,1858. This was the date the first photographic plate was exposed at the Smithsonian Astrophysical Laboratory ushering in the age of modern astronomy. Clunks provide very fine time resolution, yet can be used to span centuries. As a 64-bit integer it will take some 58,000 years before it will overflow. That should suffice for your programs until that next company merger when all programming is overhauled. DEC has used the clunk date/time concept in RSX Datatrieve (USAGE IS DATE) and in VMS for the system date/time and VMS software products including VMS Datatrieve. In 1982 Bob Rock of Northern Telecom wrote an article for the Multitasker on clunks. At that time he had written several routines that converted the DEC date and time stamp into clunks and visa versa. The routines did not actually let you manipulate the clunk time values. About a year ago I designed some logistics modeling software in which I needed to record events for later analysis as well as predict when future event should occur. Parts of the model required time calculations over periods of months while in other parts minutes was the order of magnitude. Here is where clunks really payoff. They are just as accurate over many years as over several seconds. To find the difference between two times all that is required is to subrtact the two clunk time values and divide by the time unit, in clunks, needed. To calculate a new clunk time value in the future or past the reverse of the process is done. Another major reason that clunk time representation was chosen is because Datatrieve uses clunks as the internal date representation for fields declared 'USAGE DATE'. The software involved using Datatrieve for some of the report generation and OMSI Pascal to perform the modeling calculations. Here, clunks proved a way to represent dates in a format compatable with both software packages. Datatrieve works only with the date portion of the clunk date/time and truncate the hours, minutes and seconds off a date printed in a report. Clunk dates written by Datatrieve will have "00:00:00" as the time value. If you need to do date comparisons in Datatrieve, keep this in mind. Datatrieve will arrive at an exact match of an externally written clunk time only if you used "00:00:00" as the time (IF DATE EQ "14-FEB-87"). If you use another time value, exact matches must be done with a range comparison (IF DATE GE "14-FEB-87" AND DATE LT "15-FEB-87"). Clunks do have a problem when it comes to RMS key compatability. There is no 64-bit unsigned integer key type in RMS-11. When a 'USAGE DATE' field in Datatrieve is declared as a key field, Datatrieve sets the key type to an eight character ASCII string. This allows Datatrieve to search for exact matches but will not allow 'greater than' searches. This is because the clunk values are stored least significant word to most significant word. If the clunks were stored in the reverse order 'greater than' searches would be possible. In real practice, working with 64-bit integers on a PDP-11 does present some problems. For example, there is no instruction to do a 64-bit unsigned integer divide returning the quotient and remainder. To overcome this problem, we have enhanced the clunk time routines to allow 64-bit integer manipulations. On the the Fall 87 RSX-SIG tape we submitted an overhauled version of Bob Rock's original submission with some new features. (This supercedes our Fall 86 submission.) The capability to convert between clunks and the DEC date and time stamp is still there but three new functions have been added. The first is a routine to calculate the difference in time between two clunk time values, returning the number of days and amount of time. The second is the ability to compute a new clunk value by adding or subtracting a specfic amount of time from an existing clunk value. The third function returns which day of the week a given clunk value falls on. The rudimentary routines to do 64-bit unsigned integer adds, subtracts, multiplies and divides have been included to do the added clunk date/time manipulations. These routines have been isolated as standalone routines so they can be used outside of the "clunk date" context for other purposes where 64-bit integer arithmetic would be handy. A 64-bit integer allows storage and manipulation of numbers from 1 to 17 quintillion (thats 17 with 18 zeros) with no rounding errors. Use of these routines will let you work with the U. S. budget and deficit figures (at least for the next few years) with resolution down to the last penny, or let you program traders get set for the next market crash. All nine of the routines use the DEC call site convention to pass parameters. This enables the routines to be used by FORTRAN, Basic-Plus-II, OMSI Pascal or MACRO-11. Great pains were taken when revising and writing the software to write only pure, position independent code. This enables the routines to be built into a shared resident, cluster or supervisor mode library. A resident and supervisor mode library example is included in the submission. I found clunks to be a very useful way of storing and manipulating time values. They didn't have the shortcomings and pitfalls of other methods I have seen and tried. The concept of a date/time stamp that can span centuries and yet retain 100 nanosecond resolution provides the ultimate in flexibility. Now that some of the overhead in manipulating clunk time values has been simplified, maybe clunk's time has come.