newman (01/29/83)
The topic of why the 6502 can't support a compiler seems to
have come up again. The standard reasons given (no 16-bit
registers, 8-bit sp) don't seem convincing to me. The 6502
intentionally traded off on-chip registers for addressing
modes. The Z80 has more registers, but the 6502 has many
more addressing modes; the 6809 has both (oversimplified).
The reason the 6502 has no 16-bit registers is that you
are supposed to use the indexed indirect and indirect
indexed modes to use page zero as a large register bank,
essentially giving you 128 16-bit pointer registers. If
you look at the instruction timings, you can access an
absolute memory location through a two-byte zero-page
pointer (register) with a one-byte offset in as few as
5 cycles. Another benefit of few registers is fast state
saving (interrupt handling has little overhead). The
shortcoming of the dumb 8-bit stack pointer would
seem to be naturally implemented in software, with a
bit of a loss in speed. Also a useful capability I believe
not provided in the Z80 is the 6502's memory-to-memory
instructions; you can incr/decr, shift or rotate absolute
locations without using the limited registers.
As proof that the 6502 CAN support a compiler, the company
below claims to have a native 6502 C compiler available
(I posted this to the net some time ago - I don't know
any inside details on the compiler, so don't ask me. Also
I am realistic enough to realize that any time-critical
operation on 8-bit processors at low clock rates is best
done in assembler, so I haven't looked into the product).
Optimized Systems Software, Inc.,
10379 Lansdale Ave.,
Cupertino, CA 95014
(408) 446-3099
C/65 - "The first native mode C compiler ever produced
for Atari and Apple computers."
(This company was the one that developed Atari Basic,
Atari Assembler/Editor, the first Atari DOS, and the
first Apple DOS).
Ken Newman
Univ. of Torontoparker (02/02/83)
Wow!! Let me start by saying that there are several misleading statements in your message. First, you can only do a memory fetch in 5 cycles only if you have the base address loaded into two page zero locations and the 8-bit index loaded in the Y register. If you don't have this situation, you need to take many cycles (instructions) to load these registers. It is very hard to write a compiler that makes good use of page zero due to the fact that you have to share it with the OS and after that there isn't much of it left for program variables. Once you start swapping page zero you lose most of its advantages. Also, if you have an array with more than 256 bytes, you can't just use the index register anyway. Enough!! Now back to the subject of the C compiler sold by OSS. First of all, it is NOT a true compiler in that it does not generate 6502 code in the normal sense. It really generates subroutine calls which emulate something like a P-code. If you look at the BYTE magazine bench mark of Sept. 1981 and the update of Jan. 1983, you will see that there were several 6502 compilers tested, the best coming in at 14 seconds (Actually a little bit less than that if you read the Jan. issue, but its validity is in question since there weren't any controls), all of the compilers under 20 seconds were for Z80. The OSS compiler takes about 300 seconds to execute this bench mark and the Atari PASCAL (compiler) takes about 190 seconds. Well, now the plug. There is a compiler for the Atari that generates *real* 6502 machine code. It comes on an 8K cartridge and includes an Editor (true full screen) and Monitor as well as the compiler!!!!! It also generates very good 6502 code. It executes the prime number bench mark mentioned above in 13.4, yes I said 13.4, seconds. It also compiles that bench mark in just 2, yes I said 2, seconds off the disk!!! Compare that to the compilation times of the other compilers in the bench mark (all of them take minutes, not seconds and are running off of faster disk drives than the Atari). The compile time is only about 1/4 second if you compile it from the editor buffer!!! Now that I have you drooling at the mouth (or in total disbelief), let me tell you that you're going to have to wait to get one. It isn't scheduled to come on the market until the end of March (and you won't see any ads for it until about May). If things work out, OSS will be carrying this compiler as well. It is called AMPL, and if you haven't guessed by now, I'm the author. If you really can't wait till then, contact me and maybe we can work something out. Clinton W. Parker, owner Action Computer Services 1105 Plymouth Ave. So. Rochester, NY 14608 (716) 235-6572 rochester!parker
bernie (02/11/83)
I have not actually seen the C/65 compiler in operation, but have heard from several sources that it's a (small) subset of the language. Your observations about design tradeoffs in the 6502 architecture are valid. However, 1. Doing any kind of 16-bit operations on the 6502 is still extremely inefficient; for example, adding two 16-bit signed integers requires several instructions, whereas a processor like the Z-80 can do 16-bit signed adds with a single 1-byte instruction. 2. The stack on the 6502 is 8 bits wide and a fixed 256 bytes deep. Since you want to keep intermediate results of calculations on the stack, as well as local vars and arguments to functions, you quickly run out of stack space. The solution you suggest (a software stack) is fine, but slow and inefficient compared to a machine with a real stack. 3. The 6502 has been around a *long* time, and is widely used (apple, pet, atari...). Yet in all this time and with all the demand for good software for the chip, no one has implemented any native-code compilers for the 6502. To me, this says something about the capabilities of the chip. Even the 6800 has native-code compilers for it! (Granted, they're not very good, and produce terrible code, but at least they exist!) The 6502 is a fast, cheap, widely used processor. It is well-suited to simple applications. It is *not* suitable for supporting high-level languages. --Bernie Roehl ...decvax!utzoo!watmath!watarts!bernie