Actually the RQM functionality existed at hardware level (a true release quantum timeslice) when Pick ran on the Microdata machines specifically built for Pick. Way back when, Master Dick (and the other fella) wrote 'the ideal operating system' as their thesis. The theory goes that operating systems were inefficient because machines were being built and only when the machine existed an operating system would be invented for it. The "hardware" side of the Pick Operating System (as opposed to the file structure) was to be specifically designed to implement the structure at raw machine code level.
Microdata (or whoever they were prior to that - maybe the ARPA people) then built this machine specifically for Pick. This was even pre-R81. My understanding was that it was at IRQ (interrupt request) level, so that just as a process needing something from an external source (external to the CPU), the processor would set a flag as "I'm waiting" then release the cpu to other processes (just as they do today). The difference today is that many disparate processes need to occupy memory, and so a paging file/swap space is needed. Back then Pick occupied the CPU the whole time. RQM would emulate this behaviour and also set a "I'm waiting" flag, thus releasing the cpu to process the next request. This worked in a circular fashion just like an ethernet works today - the focus moves from computer to computer until all have been serviced then returns to the first one. In a Pick CPU each "user" process had a "request" (of some maths to be done on something). They would all sit in a bottleneck queue and be processed one after the other (no multithreading). The RQM was a way to hurry up the process to allow important processes (logged in users) to get reasonable response times and yet still be able to run slower routines. Yes, 16 users on a 386. Full MRP system, plus GL and accounts, and MRP/CRP reporting running in the background constantly. All background apps were initiated as phantoms that read flags, when the system set the flag, all phantoms would implement RQMs. Online programs would set the flag as data capturing started, then reset it while the processor thought, etc. On 30 August 2012 05:18, Tony Gravagno <[email protected]> wrote: > The documentation is interesting for at least two reasons. > > 1) > I have an R83 manual in my hands, v5 1990 that has the exact same text > as the Microdata text below, except with the words REALITY and Pick > interchanged, and one other subtlety: > REALITY: "RQM statement causes a one-second sleep, terminating the > program's current timeslice." > R83: "RQM statement terminates the program's current time-slice." > > There's no telling which version came first without going back to > R81v1 docs. There's probably no way to tell who got the text from who, > or by what license or method. There's also no real way to know which > implementation actually did a sleep 1 or whether it really just > relinquished the Nms timeslice if there was no 'seconds' argument. > That RQM and SLEEP are documented as being equivalent only confuses > the matter more in this "much ado about nearly nothing" but fun > discussion. > > 2) > As I understand it, Unidata was conceived in a dream, and any relation > to other Pick platforms was purely coincidental - at least as > described in early lawsuits defending the originality of the platform. > (Or maybe I'm thinking of Universe?) So how could there be an > "original purpose" of a command that was not based on something else? > I'm sure that there is some logical reason for this and that we're not > looking at a smoking gun from 1991, but the historical significance is > intriguing. > > T > > > From: Bob Wyatt > > UniBasic User's Guide, Release 2.1, Copyright 1991 by Unidata, Inc. > > "The original purpose of RQM was to release remaining execution time > > reserved for a program, allowing other programs to use the time. > > > > REALITY by Microdata. DATA/BASIC Programming Manual, Series 3.0 - > > 4.0, Release 4.0, February, 1981 > > > > "The time-shared environment of the REALITY system allows concurrent > > execution of several programs, with each program executing for a > > specific time period (called a timeslice or quantum) and then > pausing > > while other programs continue execution. The RQM statement causes a > > one-second sleep, terminating the program's current timeslice. The > > RQM statement may be used in heavy compute loops to allow increased > > execution speed of other concurrently executing programs by giving > up > > time. It may also be used to cause pauses." > > > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
