🚀 go-pugleaf

While I was doing some debugging I was perusing the assembler listings,
and since I wanted to be sure what addressing mode was actaully being
used, looked at the binary opcodes.  Did I get a surprise!

As we all know, Manx have a near data model that uses the a4 register as
a base and adds a signed 16 bit offset to get the data address, so I
would have expected to see 
	2c6c xxxx	(move.l	xxxx(a4),a6)

but found instead
	2c6d xxxx	(move.l xxxx(a5),a6) !!

Just in case there was a bug in the assembler listing I checked the .o
files, and sure enough, there was 2c6d.
But after linking these self same .o files, the final object file
contains 2c6c as it should.
Curiously, subroutines with local variables contain move.l d(a5),an in
both the .o files and the final object.

How on earth does the linker know which d(a5) should be converted to
d(a4), and why do it this way in the first place?

Allan Duncan	ACSnet	a.duncan@trl.oz
(03) 541 6708	ARPA	a.duncan%trl.oz.au@uunet.uu.net
		UUCP	{uunet,hplabs,ukc}!munnari!trl.oz!a.duncan
Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.