A new C compiler for the 6502 and derivatives

[Arlet]

C doesn't care how you implement the parameter storage, as long as it works as if it were on a stack. Static parameter storage would require having the compiler do an analysis to see which functions are called recursively, and/or have their pointers taken.

I've used a Keil 8051 compiler that did something like that.

[whartung]

Well this brings up another issue.

Where is this compiler to be hosted? If you're going to host it on a modern machine with the associated resources, then, you can do all sorts of things (including global optimizations, assuming you're compiling ALL of the code, not simply linking). But if this will be hosted on a 65xx machine, then none of that is really tenable. There's simply not the horsepower or resources to do this kind of analysis efficiently.

[BitWise]

whartung wrote:

Well this brings up another issue.

Where is this compiler to be hosted? If you're going to host it on a modern machine with the associated resources, then, you can do all sorts of things (including global optimizations, assuming you're compiling ALL of the code, not simply linking). But if this will be hosted on a 65xx machine, then none of that is really tenable. There's simply not the horsepower or resources to do this kind of analysis efficiently.

The was a C compiler for the BBC that ran on a standard 32K model B (at 2MHz). The compiler and byte code interpreter was in a 16K ROM. The compiler is probably in byte code itself. I had a copy in the late 80's but never did much with it.

http://mdfs.net/System/C/BBC/

[Bregalad]

Since this topic comes regularly (including in my own head), I made a post on NESdev summing up all current existing possibilities to code for the NES (or any other 6502 machine, really) using a high level language. I could do the same here but I do not want to maintain two separate post when I need to update it, so I'll just link to the existing post.
http://forums.nesdev.com/viewtopic.php? ... 17#p139617

Basically, my tought reflects exactly the OP. An efficient C compiler for the 6502 target is indeed technically possible, but if the goal is to develop a new project, there is no reason to be bound to the C language and to limit oneself to it.

The problem is that the effort to build a new compiler entirely (or to adapt an existing compiler to those specific needs - which is just as much effort) is a huge project and even if technically possilble, I wonder how realistic it is to do such a large project during one's free time. Actually if the goal is to win time to develop a project by using a high level language, we'll probably loose several times the project's development time to develop the compiler.

Quote:

Obviously UCSD Pascal chimes in here.

Yes, but the problem is the license.

[GARTHWILSON]

Bregalad wrote:

I could do the same here but I do not want to maintain two separate post when I need to update it, so I'll just link to the existing post.
http://forums.nesdev.com/viewtopic.php? ... 17#p139617

I figured I'd register; but in the registration, there's the line,

• The character you play as in The Legend of Zelda?:
  This question is a means of preventing automated form submissions by spambots.

Other than supposing it's some kind of video game, I have no idea what this is. I am not a games person at all. Any help? What are the choices? If it is a video game, and I'm supposed to have played it and identified with some sort of character, is there no way I can sign up? I don't see any way to contact a moderator or administrator until after I'm registered.

[barrym95838]

GARTHWILSON wrote:

... Other than supposing it's some kind of video game, I have no idea what this is. I am not a games person at all. Any help? What are the choices? If it is a video game, and I'm supposed to have played it and identified with some sort of character, is there no way I can sign up? I don't see any way to contact a moderator or administrator until after I'm registered.

I wasn't sure that I knew the answer, but it took me approximately 10 seconds with my favorite search engine to confirm (that the answer is "Link").

Mike B.

[Tor]

A spambot can do that search easily too (and they do), so forums with that kind of protection are not really protected, as I've seen elsewhere.

[jamestn529]

Bregalad wrote:

Since this topic comes regularly (including in my own head), I made a post on NESdev summing up all current existing possibilities to code for the NES (or any other 6502 machine, really) using a high level language. I could do the same here but I do not want to maintain two separate post when I need to update it, so I'll just link to the existing post.
http://forums.nesdev.com/viewtopic.php? ... 17#p139617

Basically, my tought reflects exactly the OP. An efficient C compiler for the 6502 target is indeed technically possible, but if the goal is to develop a new project, there is no reason to be bound to the C language and to limit oneself to it.

You can also add Batari Basic—it's a BASIC compiler, for the Atari 2600. While it's very simple (it's more like a macro assembler with expressions), it's batteries included, and allows programming an Atari 2600 game without touching a line of assembler, and especially without having to write the scanline-by-scanline display code. It's gained some popularity inside the 2600 dev comminuty.

I'm not opposed to designing a new 6502-tailored high level language. My goal is specifically to develop a C compiler for the 6502, though. And we won't be bound completely to the C language—the standard makes plenty of provision for platform-specific and non-specific language extensions.

Quote:

The problem is that the effort to build a new compiler entirely (or to adapt an existing compiler to those specific needs - which is just as much effort) is a huge project and even if technically possilble, I wonder how realistic it is to do such a large project during one's free time. Actually if the goal is to win time to develop a project by using a high level language, we'll probably loose several times the project's development time to develop the compiler.

A C++ compiler is too big for a single person to write. Standards-compliant and less-than-standards-compliant C compilers, though, have been written by single persons a multitide of times. C isn't a particularly large language. The hardest part is the code generator, but that will be a problem you run into implementing any HLL that provides for as many types and operations as C does.

That reminds me of this XCKD comic, "Automation": http://xkcd.com/1319/. You're right that the effort to maintain a project can exceed the time gained by using it. Properly-done, the time gained by the whole 6502 community will far overshadow the time spend on writing the compiler.

[whartung]

jamestn529 wrote:

I'm not opposed to designing a new 6502-tailored high level language. My goal is specifically to develop a C compiler for the 6502, though. And we won't be bound completely to the C language—the standard makes plenty of provision for platform-specific and non-specific language extensions.

But then it's not C any more, is it? At least it's not C in terms of being able to port the code to anything. It's "C-like", it's "kinda C", but it's not C. It's C enough to confuse people that it's C, when it's not.

K&R C isn't a big language, that was it's charm. It's kind of fast and lose. ANSI-C less so.

That's why I mentioned ACTION, as it was designed with the 6502 in mind. Static procedures, no floating point.

Oh my, the source to ACTION has been GPLd… https://sourceforge.net/projects/atari-action/

[jamestn529]

whartung wrote:

jamestn529 wrote:

I'm not opposed to designing a new 6502-tailored high level language. My goal is specifically to develop a C compiler for the 6502, though. And we won't be bound completely to the C language—the standard makes plenty of provision for platform-specific and non-specific language extensions.

But then it's not C any more, is it? At least it's not C in terms of being able to port the code to anything. It's "C-like", it's "kinda C", but it's not C. It's C enough to confuse people that it's C, when it's not.

"C" can mean two things: it can mean strictly standard ANSI C, the lastest standard of which is C11.

It can also mean a superset of C, such as GNU C. GNU C has nonstandard features like case ranges, void pointer arithmetic, a plethora of builtins (here's a the whole list: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html), but anyone you ask would call that "C". It's completely compatible with standard C, with extensions that make development easier in general or on a specific platform.

[Rob Finch]

Good luck on the project ! It’s something I’d like to follow along on. I’ve done some work on a compiler and know it’s not a trivial task.

[GARTHWILSON]

whartung wrote:

But then it's not C any more, is it? At least it's not C in terms of being able to port the code to anything. It's "C-like", it's "kinda C", but it's not C. It's C enough to confuse people that it's C, when it's not.

Although I don't speak C, hopefully my comment from Forth will apply.

Before the ANS standard, people were complaining that there's no effective Forth standard. I thought the '83 standard plus a lot of things in common usage and documented in Starting Forth, Thinking Forth, Forth Dimensions, and other publications were enough of a standard; but when the ANS standard came along, it seemed to give Forth more credibility outside the inner circles. I've added some things from ANS to my own '02 and '816 Forths, but I don't like being confined to some parts of ANS.

There are some parts of ANS Forth that present extra overhead in order to make it more portable across a wide range of processors. My personal opinion is that they may have taken this too far. At some point, we need to acknowledge that no language that lets you get so close to the heart of the computer will be 100% portable. We must consider the programmer(s) and platform(s) involved, and decide on a good balance between portability and optimization. I personally prefer more optimization at the expense of portability. Greater optimization means a particular processor can be used for a wider range of jobs anyway, which could in itself somewhat reduce the need for portability. If code is taken from one platform to another, modifications may be needed, but they should be rather minor.

Jack Woehr of Vesta who was on the X3J14 committee says in his book "Forth: The New Model", "When Forth, which some hold to be inextricably wedded to hardware, takes responsibility for cross-platform portability, a certain light-footedness and grace will be surrendered." He admits that optimum portability and optimum efficiency don't come at the same point. Fortunately he also says it's not the committee's intention to force anyone to comply with the standard. What I have is basically Forth-83 with a lot of extensions from my own experience, the books "Starting Forth" and "Thinking Forth," Forth Dimensions magazine, ANS, and common usage.

The transfer is of course that if a C compiler needs minor incompatibilities with common C to make it really sing for 6502, it seems appropriate to take that avenue. I think it would give the 6502 a good promotion.

[jamestn529]

GARTHWILSON wrote:

The transfer is of course that if a C compiler needs minor incompatibilities with common C to make it really sing for 6502, it seems appropriate to take that avenue.

What are some incompatibilities that you would suggest for the 6502? Are you thinking of extensions to the standard, or deviations? One that comes to mind would be floats: they're incredibly slow, especially because we don't have an FPU, and no application that I can think of would benefit from their use on the 6502. The only reason to include it would be completeness.

[Martin_H]

jamestn529 wrote:

What are some incompatibilities that you would suggest for the 6502?

I'm not Garth, but if I may interject.

Microcontrollers that use the Harvard architecture don't fit the standard C model either, and generally require #define's to declare which memory store to use (i.e. static ram versus EEPROM). Under the cover the C compiler uses dedicated instructions based upon the #define contents. When porting to an alternate architecture the #defines can be stubs, or that platforms equivalent.

While the 6502 is Von Neumann, its page zero addressing and immediate modes are really the key to getting things done efficiently. So you would either need a really smart compiler that managed page zero allocations, or annotations that allowed a programmer to say this really needs to be page zero or an immediate mode.

[Arlet]

I don't think anybody has yet mentioned the existing SDCC (small device C compiler) project.

Quote:

SDCC is a retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11) compiler suite that targets the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A, TLCS-90) and STMicroelectronics STM8. Work is in progress on supporting the Microchip PIC16 and PIC18 targets. It can be retargeted for other microprocessors.

It doesn't support the 6502, but it does support various other small targets, and writing a 6502 backend is probably less work than writing a compiler from scratch.