Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.cbm » compilers for the 6502
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
compilers for the 6502 [message #64890] Sat, 18 May 2013 21:01 Go to next message
Anonymous
Karma:
Originally posted by: janney@unm-cvax.UUCP
Message-ID: <850@unm-cvax.UUCP>
Date: Thu, 17-May-84 01:59:07 EDT
Article-I.D.: unm-cvax.850
Posted: Thu May 17 01:59:07 1984
Date-Received: Fri, 18-May-84 00:49:15 EDT
Organization: Univ. of New Mexico, Albuquerque
Lines: 66

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
Re: compilers for the 6502 [message #64891 is a reply to message #64890] Sat, 18 May 2013 21:01 Go to previous messageGo to next message
gwyn is currently offline  gwyn
Messages: 27
Registered: May 2013
Karma: 0
Junior Member
Message-ID: <2124@brl-vgr.ARPA>
Date: Thu, 17-May-84 07:44:44 EDT
Article-I.D.: brl-vgr.2124
Posted: Thu May 17 07:44:44 1984
Date-Received: Fri, 18-May-84 02:14:24 EDT
References: <850@unm-cvax.UUCP>
Organization: Ballistics Research Lab
Lines: 5

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.
Re: compilers for the 6502 [message #64892 is a reply to message #64890] Sat, 18 May 2013 21:01 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: ais6438@acf4.UUCP
Message-ID: <12900002@acf4.UUCP>
Date: Sun, 6-May-84 06:20:00 EDT
Article-I.D.: acf4.12900002
Posted: Sun May  6 06:20:00 1984
Date-Received: Fri, 18-May-84 02:36:59 EDT
References: <850@unm-cvax.UUCP>
Organization: New York University
Lines: 21
Nf-ID: #R:unm-cvax:-85000:acf4:12900002:000:1128
Nf-From: acf4!ais6438    May 17 06:20:00 1984

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?
Re: compilers for the 6502 [message #64917 is a reply to message #64890] Sat, 18 May 2013 21:01 Go to previous message
Anonymous
Karma:
Originally posted by: joemu@tekecs.UUCP (Joe Mueller)
Message-ID: <3806@tekecs.UUCP>
Date: Fri, 25-May-84 15:00:58 EDT
Article-I.D.: tekecs.3806
Posted: Fri May 25 15:00:58 1984
Date-Received: Fri, 1-Jun-84 04:58:31 EDT
References: <12900002@acf4.UUCP>
Organization: Tektronix, Wilsonville OR
Lines: 18

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.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: 1541 questions
Next Topic: vi problems
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 17:12:04 EDT 2024

Total time taken to generate the page: 0.15290 seconds