Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site intelca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!hplabs!intelca!glen
From: glen@intelca.UUCP
Newsgroups: net.micro,net.micro.apple,net.micro.cbm
Subject: Is there a fast High-level language for the 6502?
Message-ID: <268@intelca.UUCP>
Date: Sun, 20-May-84 12:28:48 EDT
Article-I.D.: intelca.268
Posted: Sun May 20 12:28:48 1984
Date-Received: Tue, 22-May-84 07:35:41 EDT
Organization: Intel, Santa Clara, Ca.
Lines: 84
Xref: 1472 246 250

Is there any high-level language for a 6502 based machine that
executes the final code quickly and efficiently?

Recent discussions in net.micro.apple and net.micro.cbm seem to indicate:
  -  No very efficient compilers exist
  -  It is very difficult to write efficient compilers for the 6502

Most of the compilers for 6502 machines either:
  -  compile down to an intermediate code which is eventually interpreted
       (For example: Apple Pascal compiles to p-code)
  -  compile down to 8080/8085/Z80 code and require external hardware
       (For example: Turbo Pascal requires CP/M card)

Neither case is a true, fast 6502 compiler.

Jim Janney writes:

From: janney@unm-cvax.UUCP
Newsgroups: net.micro.apple,net.micro.cbm
Subject: compilers for the 6502
Message-ID: <850@unm-cvax.UUCP>

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. 

...

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


One language that seems to be fairly efficient according to net response is
Manx Aztec C.  They seem to have circumvented this problem as follows:

Doug Gwyn writes:

From: gwyn@brl-vgr.ARPA (Doug Gwyn )
Newsgroups: net.micro.apple,net.micro.cbm
Subject: Re: compilers for the 6502
Message-ID: <2124@brl-vgr.ARPA>

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.

****

OK, so Aztec C is fairly efficient, are there any other efficient languages
for the 6502 (besides assembly)?  Will there ever be?

{The views expressed are soley my own and not necessarily those of my employer}

^ ^    Glen Shires, Intel, Santa Clara, Ca.
O O     Usenet: {ucbvax!amd70,pur-ee,hplabs}!intelca!glen
 >      ARPA:   "amd70!intelca!cem"@UCB-VAX
\-/    --- stay mellow