13.07.2015 Views

iAPX 286 Operating System Writers Guide 1983

iAPX 286 Operating System Writers Guide 1983

iAPX 286 Operating System Writers Guide 1983

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

BINDING AND LOADINGModules are relevant to binding in that they (indirectly) define the units that can be distributed amongphysical segments. A module is a single compilation unit. Intel's translators divide each compilationunit into logical segments. Each logical segment is a named object that can be assigned to a physicalsegment. You can use the development tool Binder to combine more that one logical segment into aphysical segment.SegmentationProtection requirements partially dictate how to distribute modules among physical segments:• Data and procedures of different privilege levels must reside in different physical segments.• Data and procedures of one task must reside in different segments from those of other tasks unlesssharing is explicitly intended.• Instructions must reside in different physical segments from writable data items.• Data structures for which you wish to provide individual protection (for example, the semaphoresand mailboxes discussed in Chapter 5) must each be in a separate segment.<strong>Operating</strong> system procedures that have the same privilege level and are shared via the GDT can becombined in just one segment (assuming that the total size does not exceed 64K bytes). In fact, doingso has two advantages: all intermodule calls can be implemented as short CALL instructions, avoidingthe additional processing associated with changing the contents of the CS register, and more GDT slotsare available for other purposes. Of the procedures in XOS, the level-zero procedures presented inChapters 3 thru 5 can be combined in one segment, while the level-one I/O interface procedures cango in another segment. Each device-driver task has its own code, data, and stack segments.InterfacesPossible mechanisms for implementing the interfaces among modules are• Intrasegment (short) references. References to data or procedures in the same segment are mostefficiently implemented when you can use the current contents of a segment register.• Intersegment (long) references. References to data or procedures in a segment not currently indicatedby one of the segment registers must cause a segment selector to be loaded into a segment register.Intersegment references permit sharing of functions among many modules and permit access tofunctions at another privilege level.• Sharing by value. Procedures and data can be shared by including a copy of the data or proceduresin the same unit (segment or task, as appropriate) as each procedure that uses them. While thisapproach can yield more efficient execution in some cases, it has limited applicability. It is usuallybest to share dynamically changing data by name, so that all the procedures that use it can obtainthe most up-to-date version. Sharing large or widely used data or procedures by name uses mainmemory more efficiently.• Sharing by name. The "name" referred to here is the descriptor of the shared data or procedure.Chapter 5 discusses methods of sharing by name (namely GDT, common LDT, and aliases).In XOS, all tasks share the segments of the kernel and I/O-interface segments via the GDT. Applicationsprocedures use long calls to access the primitives in these segments. Calls within the kernel levelor within the I/O level to private procedures at the same level are short calls.11-2 121960-001

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!