8086 Object Module Formats | Version 4.0 |
(1)A 5
TARGET: EI(subroutine) ,0000H
The reason is that when
. TARGET: SI(A) ,dl
Now the programmer may be correct in dknowinq· that when the proqram is eventually LOCATE'd, the TARGET will be within 128 bytes of
LOCATION; however, this does not mean that dl is less than l28! Thus, as
various pieces of LSEG A are combined, it needs a full word to
maintain the offset. Since the LOCATION is a sinqle byte, the
translator must provide an offset field in the fixup record itself for
(2)The translator wishes to reference ·backwards~ from the
REFERENT. For example, if the TARGET is the word in front of the external array ARY, and the reference is with respect to a base register that will contain the address of the LSEG named FOO, the translator would use
FRAME: SI(FOO)
TARGET: EI(ARY) ,0000H
and place the dneqative offset- FFFEH in LOCATION. R&L will perform access verification to the REFERENT ARY: however, access to the TARGET is not guaranteed, and is the programmer's responsibility.
Note: if Case 3 in the above diaqram were available, the translator could use
FRAME: SI(FOO)
TARGET: EI(ARY) ,-2
and R&L would perform access verification, not to the REFERENT ARY (as above), but to the actual TARGET (in front of ARY)!
(2)(continued) The calculation by
quantities: the
(say, BAZ) containing ARY, and the relative offset of ARY within
BAZ.
(location of SAZ plus relative offset) - (location of FOO) r
is not qreater than ~5535r provided that all quantities enterinq into this difference are
FRAME: SI(FOO)
TARGET: EI(ARY)
then
linkaqe to linkaae) relative offset of ARY within BAZ. in the
LOCATION itself, where it qets ~added~ to the content FFFEH. And because the R&L system cannot know if the FFFEH was a neoative 2 or a positive ~5534, the access verification of R~L may thNart the translator'S intentions.
20