ais6438@acf4.UUCP (05/06/84)
Well, you sound convincing, but is there anything serious besides the disk format that would prevent me from getting something like Turbo Pascal for the Commodore with Commodore CP/M? I'd be happy to let the Z80 do the job. Incidentally, I wonder why I don't hear more about Commie CP/M. It's an attractive idea, isn't it, having two microprocessors sharing memory, helping each other out, reading to each other at night? Perhaps I don't hear much about Commodore CP/M because many have had the same compatibility problems I have had: three CP/M units in a row would not boot on my system (64 of last summer, brand new disk drive). I've had no problems with any other disks or cartridges. The last CP/M was tested at the store, and worked on the portable and one regular 64, but not on another. So they gave me a refund and said give Commodore a few months to get straightened out. But to get closer to your subject: The thing that worries me about the 64 is the small address space. I don't really know, but (and set me straight on this, please) wdn't a C compiler leave very little room on the 64 for a C program?
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!janneygwyn@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.
joemu@tekecs.UUCP (Joe Mueller) (05/25/84)
About the only way to handle automatics are to set up your own stack (the 6502's is a cruel joke) and allocate them from the pseudo-stack. I have been in the process of building a C-64 c compiler for about 8 months now. It is in pretty good shape but will not be available until I get the rest of the support programs ready (linker, assembler, loader, librarian). I wasn't going to say anything about it until it was ready, but seeing all this discussion prompted this response. If everyone is in such dire need for a compiler (I agree what's available is either too expensive or worthless), would there be suffecient interrest in an incremental release? I may be able to provide something within a couple months and provide updates real cheap. Also what would be the minimum functionality for initial release? Currently I don't have structures, unions, parameter substitution in macros, multidimentional arrays, bit fields and floating point. I could also drop separate compilation & relocatability. Questions/comments are welcome.