Fig. 9. Control part to compute weighted averages using multiply macro.

end of the subroutine. A return is made to all calling modules simultaneously and only the Ksub that actually made the call is active and will respond to pass control on to the next module.

The option of whether to share facilities via subroutining or whether to use separate hardware for each occurrence (macros) is one of the recurrent design alternatives in RT-level design. (It occurs as well in programming, under the same rubric of subroutines versus macros; originally it was known as the alternative between open and closed subroutines, where an open subroutine was a form of what is now termed a macro.) As can be seen by comparing Figures 8 and 10, there is a very slight cost to be paid for using subroutines, both in time and in hardware. The cost in time is about 0.02 microseconds per call. The cost in hardware is the use of a Ksubroutine instead of a Kevoke at each occurrence plus the one Kserial-merge associated with the subsystem. In general this hardware cost is minor compared to the hardware savings from not having the additional hardware for each copy of the subsystem. However, it does put a lower bound on how trivial a subsystem can be effectively used as a subroutine.

The Ksubroutine was added to the basic set of RTM modules precisely to

120