[net.micro.apple] compilers for the 6502

wak@hpfclk.UUCP (05/11/84)

   Manx C65 also uses a few locations in page 0 for register variables.
   This works quite well for high usage loop variables and pointers.
   If the range of a variable is known to be small, you can declare it char
   and get very fast and small code. Of course, you can also warp your 
   programming style and make heavier use of globals.

janney@unm-cvax.UUCP (05/17/84)

There have been a number of requests on the net for real (native code) C and
Pascal compilers for the 6502, and a fairly noticeable lack of response.
As it happens, I've been studying the 6502 recently and I've reached a
conclusion that is now ready for beta-testing ("let's throw it onto the
net and watch them kick it apart"), to wit:

	There will never be any good C or Pascal compilers for the 6502.

Before you start organizing the mob of peasants with torches, allow me to
explain.  C and Pascal, and other similar languages, make extensive use
of what C calls "automatic" variables.  These are variables that are local
to a particular function and have no existence outside it.  Space is
allocated for them when the function is entered and released again when
the function is terminated.  This is essential for recursion and allows
better use of memory in general.

This causes a problem for the 6502 in that these variables do not
occupy fixed addresses: an address may be different for every call
to the function.  The usual solution is to express these addresses
as offsets from an index register: when the function is called, all
you have to do is put the right base address in the register and
the code is ready to run.

Unfortunately, although the 6502 has two 8-bit index registers and a
zillion different ways for clever assembly language programmers to use
them, it doesn't have any 16-bit index registers.  So the usual solution
doesn't work, unless you can live with a 256-byte address space.
Worse, there don't seem to be any other good solutions.  I will briefly
consider a few possible solutions.

	Fake the automatic variables: use fixed addresses except in recursive
	functions.  This requires the compiler to recognise recursive
	functions: easy in Pascal, not always possible in C (consider
	indirect recursion with separate compilation).  This loses the
	memory saving of automatic variables and still has to deal
	with recursion somehow.

	Fake an index register: construct the address in memory, probably
	on page 0.  This is very expensive both in time and instruction
	space.  It requires a minimum of one extra instruction for every
	reference to an automatic variable (probably more).

	Calculate all the addresses once on entry to the function.  This
	is an improvement over the previous scheme, but makes calling
	a function very expensive.

	The register approach: put all automatic variables in "registers"
	(fixed locations on page 0) and save all registers before entry
	to a function.  This can be improved by keeping a pointer to the
	highest location with a meaningful value, so you don't waste time
	saving garbage.  It also makes calling a function expensive,
	depending on the number of local variables it uses.

Note: very little of this applies to arrays, since you have to do address
calculation for them anyway.  For the record, the 8080 or 8085 is even
worse off, since it doesn't have all the nifty addressing modes of the 6502.
The Z80 is a different story, since it has two 16-bit index registers.

Sorry this got so long.  "There ain't no such animal" propositions are
hard to defend.  I am very interested in hearing other people's opinions
on this, especially if someone can refute me.  Does anyone know how
Manx C does it?


Jim Janney
{{convex,ucbvax,gatech}!unmvax, {purdue,lbl-csam,cmcl2}!lanl-a}!unm-cvax!janney

gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/17/84)

Manx C65 allocates automatics off the stack, as usual for C runtime
design.  However, they do not use the hardware stack since it is too
limited but instead maintain their own (SP in a known place).  This
works just fine, although clearly a better architecture would permit
faster, smaller code.