KEY CCNCEPTS
Since a windCM is referenced like memory, any individual transfer may be between an obj ect and PS memory, an object and a PS processor register, or an object and an I/O device. The latter may be appealing from the standpoint of "efficiency," rut it should be used with caution. Using a windCM to directly "connect" an I/O device and an object in 432 memory has the undesirable effect of propagating the
the subsystem boundary into the 432 system. It may seriously complicate error recovery as well. Finally, since there is a finite number of windCMs, JOOst applications will need to manage them as scarce resources which will not always be instantly available. This means that at least some I/O device transfers will have to be buffered in PS memory until a windoo becomes available. It may be simplest to buffer all I/O device transfers in memory, and use the windows to transfer. data between PS memory and 432 system memory.
There are four IP windows which may be mapped onto four different objects. The I/O controller may alter the windCMS during execution
to obtain access to different objects. References to windowed subranges may be interleaved and may be driven by different agents in the Peripheral Subsystem. For example, the Attached Processor and a J:I.1A controller may be driving transfers concurrently, subject to the same bus arbitration constraints that would apply if they were accessing memory.
FUNCrICNS
A fifth window, the control windCM, provides the IP controller with access to the Interface Processor's _function request facility. The IP oontroller requests the execution of an IP function by wr i ting operands and an opcode into predefined locations in the control
windCM's subrange. This procedure is very similar to writing comnands and data to a
