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.
The error "Alignment factor must not exceed segment align factor" is now given when an ALIGN record with greater alignment than its segment is encountered. (This is the error that was given erroneously in other circumstances before the last commit.)
Previously, the linker gave an error if the relative displacement was more than + or - 32 KB. But 2-byte RELEXPR records are typically used for the operand of the BRL instruction, and since its address calculation wraps around within the program bank, it can effectively address + or - 64KB (i.e. any location within the program bank). Similar reasoning applies to PER, the other instruction using long relative addressing.
This would give an error in code like the following:
bigbrl start
brl later
ds 33000 ; realistic examples would have actual code here
later rtl
end
(This currently also gives an assembler error due to similar logic in ORCA/M, but the output file can be linked anyway.)
This issue can affect very large functions compiled with ORCA/C or ORCA/Pascal, which may sometimes have branches that go more than 32 KB forward or back.
Stephen Heumann
Kelvin Sherlock
mikew50