Deutsch.pa@XEROX.ARPA (08/21/84)
I looked at the CALLM/RTM stuff. I think it's usable for an object-oriented operating system, but it's questionable for a general object-oriented architecture, for the same reason as the Intel 432: it's pretty expensive in both time and space. Module descriptors take a minimum of 18 bytes (16 for the descriptor, 2 for the entry word). Module call stack frames take a minimum of 24 bytes, compared to 4 for a normal stack frame (just a return address). The typical (called "worst" in the MC68020 documentation) time for a CALLM instruction with no change of protection level is 36 clocks; with change of protection level is 56 or 64 clocks. The time for RTM is 22 or 35 clocks respectively. The corresponding times for JSR and RTS are 11 and 12 clocks respectively. If you add LINK and UNLK for delimiting the stack frame (a capability which incidentally is not built into CALLM/RTM, but which you usually want), add 7 and 7 more clocks respectively, and 4 more bytes to the stack frame. For comparison purposes, a register-to-register ADD takes 3 clocks; a memory-to-register MOVE with base+displacement addressing takes 9 clocks. As Dave Brownell observed, the protection levels, etc. are all implemented by off-chip hardware, such as Motorola's new MMU (specs not generally available yet). It's clearly their intention that you use the two chips together. While CALLM/RTM take care of the bookkeeping associated with protection levels for access to procedures, they give you no help with access to data. Thus, if a procedure A passes a pointer argument to a procedure B at a more privileged access level, B must check in software to be sure that the pointer doesn't point to data accessible to B but not to A. In other words, module descriptors are like capabilities for procedures, but there is no corresponding mechanism for data.