🚀 go-pugleaf

[]

My guess is that MWC made the program larger since all references to
variables and functions, i.e. all addresses, are 32-bit instead of the
16-bit offsets used by Megamax.  Many people have complained about the
32K limits in Megamax, enough that the upcoming Megamax 2.0 will have
32-bits throughout.  But that means larger, and slower, executables.

BTW, this is very different from the infamous "segmentation" IBM-PC users
have to deal with.  Even in Megamax, all pointers are 32 bits, so that
pointer arithmetic works fine for large chunks of RAM.  It's just that
a reference to a variable looks like:

	a = b;		-->	move b(A4),a(A4)
	p = &a;		-->	lea a(A4),p(A4)
or				lea a(A4),Rp
if p is a register variable.
Here 'a' and 'b' are 16-bit numbers.  A4 is set at runtime, when the program
is launched, so Megamax code is basically position-independent.  The new
version, with absolute addressing, will be relocatable (as all GEMDOS
programs are) but not position-independent.  The above lines will look
like:
				move a,b
				move #a,p

where a,b,p are absolute addresses.

(In reality, expect to see things like:

				move b(A4),D0;  move D0,a(A4)
				lea  a(A4),A0;  move.L A0,p
in the 16-bit case, etc.
A compiler just needs to do a lot of optimizations to approach AL...
I DID observe Megamax to translate "*p++ = *q++" (with register pointer
vars) into "move (Aq)++,(Ap)++".  I hope for more such smarts!)

- Moshe Braner