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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

BINDING AND LOADINGThe model behind the example operating system, XOS, includes these components:• Each module contains functionally related data structures and procedures.• One segment contains level-zero (kernel) procedures, another segment contains level-zero data,another segment level-one (I/O) procedures, and another level-one data. <strong>Operating</strong> system tasks(such as device drivers) have their own distinct segments.• The GDT contains descriptors of kernel and I/O segments, making them sharable by all tasks.Gates for operating-system primitives, however, reside in the LDTs of the tasks that use them.• The segment names created by PL/M-<strong>286</strong> set the standard for segment naming in general. (Referto the chapter entitled "Linking to Modules Written in Other Languages" in the PL/M-<strong>286</strong> User's<strong>Guide</strong> for definition of PL/M-<strong>286</strong> segment names).• Tasks will be loaded dynamically.• Load-time binding to XOS primitives is an option. (This is one reason for placing gates for operatingsystemprimitives in LDTs.)Source CodeSince some of the logical segments declared in assembly language may be combined after assembly bythe Builder, the assembler needs to know whether the object of an external reference will be in one ofthose segments whose descriptors it assumes to be loaded in segment registers. If the reference is toanother segment, the assembler must emit instructions that change the contents of a segment register.The programmer supplies this information via additional assembly language syntax. A variety of formsare available for this purpose, such asSEGMENTASSUMEN EAR and FAR variants of PRO C and LAB E Lsegment overrides (for example E S :' TAB L E _I T EM)(Refer to the ASM<strong>286</strong> Assembly Language Reference Manual for details on the use of these items.)The module DISP containing the dispatcher is the only kernel module of XOS written in assemblylanguage (refer to Chapter 4). The logical code segment has the name NUCLEUS_CODE and combinetype ER so that it will combine with PL/M-<strong>286</strong> segments of the same name. This module has no logicaldata segment. The procedure DISPATCHER is a NEAR procedure because only other kernel proceduresin the same physical segment call it.CompilersWith PL/M-<strong>286</strong>, decisions regarding segmentation are not imbedded in source code but rather areimplemented by the compiler according to compiler control statements that you supply. (Refer to theSMALL, COMPACT, LARGE, and extended segmentation controls in the PL/M-<strong>286</strong> User's <strong>Guide</strong>.)With these control statements, you have nearly as much control over system structure as with assemblylanguage, but changes in system structure do not require changes to source code. It is just as important,however, that use of these controls conform to a consistent model of system structure.Figure 11-1 shows the segmentation controls used for compiling the kernel modules of XOS. Thesecontrols define a subsystem named NUCLEUS that contains all the PL-O modules of XOS. ThePL/M-<strong>286</strong> compiler prefixes the names of the code and data segments with the subsystem name. Thelist of exports includes all the primitives. For each of the procedures named in the exports list, the11-4 121960-001

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

Saved successfully!

Ooh no, something went wrong!