This could be interesting: a 6502 port of gcc is in active development.
https://github.com/puppeh/gcc-6502-bits
Edit: now at https://github.com/itszor/gcc-6502-bits

Previously: viewtopic.php?t=1476

Points previously covered:
- 6502 is not an ideal target for C compilers
- gcc isn't a pleasant codebase
- 65816 is another question

Cheers
Ed

I would have thought SDCC would be an easier port to the 6502. gcc has become quite large and unwieldy.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

Maybe so - but as with all these things, it takes someone to decide to do it, and to get it done. A quick search tells us that Jonathan Masur was intending to try to port SDCC this year as a Masters project. We can hope!

I notice that SDCC has a simulator too, which does not presently model the 6502. The gcc port I mentioned also comes with a simulator (semi65x), based on Beeb-em, which might be worth a look.

Oh, and another encouraging sign about the gcc port is that there are many thousands of test cases, and the project is reporting how many are presently passing.

Cheers
Ed

Ref: http://sourceforge.net/p/sdcc/mailman/s ... luewin.ch/
Ref: http://www.mkw.me.uk/beebem/

Finally I am working on a totally different Master's project. However, I might try again to port SDCC later if I ever get the time and motivation.

The problem is that the codebase of SDCC is HUUUUUGE and it's very hard to get an understanding of how the compiler works in the 1st place.
Porting the compiler in itself is probably "not that hard", but it's a clear requirement to understand how it works internally in a pretty good way, and THAT is hard !

As for GCC, I don't know exactly how it differs from SDCC (probably in thousands of ways), but it was not made to work with 8-bit CPUs in the first place, so chances are it'll perform terribly. SDCC does quite a lot of messy stuff to eliminate stack frames in order to produce decent output on 8-bit CPU, without having to explicitly declare all variables STATIC.

Ah well!

In many ways the 65816 is a more interesting target, because we already have cc65 for the 6502, and it's probably a more amenable target too.

Some other possibly interesting starting points:
- Tiny C Compiler by Fabrice Bellard at http://bellard.org/tcc/tcc-doc.html
- CC500 by Edmund Grimley-Evans at http://homepage.ntlworld.com/edmund.grimley-evans/cc500/ [dead link changed to archive, see also here]
- 8cc by Rui Ueyama at https://github.com/rui314/8cc

See also the nice story about bootstrapping by Grimley-Evans:
http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html [dead link changed to archive]

Cheers
Ed

Compared to gcc?

I needed gcc for the ARM last year, and it wasn't available in precompiled form for my Linux distribution, so I had to compile it from source. The source download (from the Debian repository) was over 900 megabytes.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

Those compilers seems to focus on completely different goals than produce small or fast code output.

This means that while those compilers have other qualities (be small, be fast, be educational), the produced code will be absolutely terrible, and definitely not fast or small, which is usually the goal that a programmer wants to achieve.


The generated code is pretty terrible. You must declare all variables STATIC by hand if you want them to not use the horribly managed "software stack frame" of CC65.

The most interesting start point is probably [url="http://www.kdef.com/geek/vic/quetz.html"]that compiler with a incredible name starting in Q[/url].
However it wasn't updated for 8 years and is largely incomplete (for instance, array and pointer support is incomplete).


No, compared to other computer science related projects I've had to deal so far.


I did that too, in fact it's not that hard, but I agree it's crazy how bit it is. Thanks god you don't have to understand code to compile it. However you definitely have to understand most of it in order to contribute to it.