This is the way they are defined in the GS/OS Reference, as well as the way they seem to be used by all assemblers and all other linkers that I could check (ORCA/M, MPW AsmIIGS, Apple LinkIIGS, old ORCA/APW LINKED, 8-bit ORCA linker).
Previously, this linker treated ORG records as giving an absolute address to ORG to (but with a bug in the address computation). The OMF spec in appendix B of the ORCA/M manual defines them this way, but this is inconsistent with the spec in the GS/OS Reference and with the way ORG records are generated by ORCA/M itself (for an ORG *+expression directive). Therefore, I think this is just an error and the specification in the GS/OS Reference should be regarded as correct.
We still do not support going backward (using a negative ORG operand). Trying to do so will just give an error.
Previously, the values of such expressions were essentially ignored, resulting in incorrect output.
This affected code like the following example:
test1 start
lda >p
rtl
end
D1 data
p gequ val
end
val data
dc i'123'
end
Note that the EQU/GEQU expression is evaluated within the context of the location that references it, not the location where it is defined. This affects the value of the location counter, as well as the symbol search behavior. The references for the OMF format do not clearly define which way this should be done, but the current behavior can cause problems with certain object files produced by ORCA/M.
Previously, the position-independent attribute bit would be set in a load segment if it was set on the first constituent object segment. Now it is only set in the load segment if it is set in all the constituent object segments. This is consistent with the ORCA linker's general approach of conservatively combining the flags from the object segments.
This is a new feature where the linker will automatically divide the code into load segments, creating as many segments as necessary to fit it. This relieves the programmer from the need to manually figure out how a large program can be divided into segments.
Auto-segmentation is triggered by the use of the special load segment name AUTOSEG~~~. Using this approach (rather than a flag in the OMF header) allows auto-segmentation to be used with all existing languages that provide a mechanism for specifying load segment names.
This would happen if a later object segment had a more restrictive alignment than previous object segments that contribute to the same load segment, as in the following example:
s1 start
jsl s2
rtl
end
align 256
s2 start
rtl
end
These alignment requirements can be satisfied by just giving the load segment the most restrictive alignment of any object segment (since all alignments are powers of 2) and inserting space as necessary to align the code from each object segment.
Stephen Heumann
Kelvin Sherlock
mikew50