gcc for 6502 (kinda)

[42bs]

Hi

just an idea I am going "pregnant" for some time. And now a small prove of concept works.

 

Here the basic idea: GCC is very good in optimizing, but only supports 16 and 32 bit CPUs. So first I thought to port it to Sweet16. But then (while discussing with someone who develops an audio book for developing countries) I got a better idea: Cortex-M0.

 

The Cortex-M0 has an very limited ISA but is very well supported by gcc (and other commercial compilers).

 

So, I tried to compile C to assembly, then throw away unneeded stuff and do some modification to get a version which can be fed to lyxass.

 

In a first step, I just replace the CM0 opcodes 1:1 by 65SC02 ones, like this:

 

movs rn,rm

=>

macro movs
lda regs_lo+\1
sta regs_lo+\0
lda regs_hi+\1
sta regs_hi+\0
endm

Of course, it will result in a code-explosion, so the next step would be to write an interpreter and generate opcodes for this with the macros.

Kind of Sweet16-reloaded.

 

Cheers

Edited March 4, 2019 by 42bs

[+karri]

Having gcc might open up lots of other things as well. Integration with IDE's, code debugging over ComLynx, high level languages.

 

Sounds interesting.

[carlsson]

Look up Jason Turner, he kind of did this a couple of years ago though I think mostly as a proof of concept. At least it made some of my non-retro interested computer friends excited.

[42bs]

Look up Jason Turner, he kind of did this a couple of years ago though I think mostly as a proof of concept. At least it made some of my non-retro interested computer friends excited.

 

:-( So I was'nt the first. Tragic of my live. Anyway, I think using Cortex-M0 should be easier than x86. There is only a dozen or so instructions. And many aren't used in normal C code.

 

The only problem I see is to find out if operations are 8 bit only to avoid 16 bit calculations.

 

I once talked to IAR about releasing their 65SC02 compiler for free for hobbyists, but they refused

Edited March 4, 2019 by 42bs

[carlsson]

I'm sure you have more drive in turning it into practically useful, instead of just a proof of concept. Many of us are excited about the compiler power and in particular optimization found in a modern gcc, but don't know how to harness it for retro purposes. If you can find a way to actually make use of it instead of just using an expensive C++ compiler as a macro preprocessor, you're in for the win.

[+karri]

The video does not use gcc to produce 6502 code. It demonstates how to create x86 asm that the guy runs through his x65 to 6502 asm conversion program that can turn a few asm mnemonics from x86 assembly to 6502 assembly.

[42bs]

The video does not use gcc to produce 6502 code. It demonstates how to create x86 asm that the guy runs through his x65 to 6502 asm conversion program that can turn a few asm mnemonics from x86 assembly to 6502 assembly.

 

I think so, first he compiles to x86 then translates the x86 to 6502.

It might be the better way, because the x86 ISA has explicit byte (8bit) operations. Whereas Armv6-M (Cortex-M0) always uses 32 bits.

So after most operations gcc has to expand the byte to 32bit.

[ChildOfCv]

Here the basic idea: GCC is very good in optimizing, but only supports 16 and 32 bit CPUs.

Huh? Atmega micros are 8-bit all the way. Heck, even with x86 architecture it can do 8-bit operations when desired. I see no reason that the GCC compilers can't have a 6502 backend too.

 

The only real challenge is supporting the zero-page and indirect addressing schemes. Maybe the avr-gcc code could even give you ideas on how to accomplish this.

[42bs]

Huh? Atmega micros are 8-bit all the way. Heck, even with x86 architecture it can do 8-bit operations when desired. I see no reason that the GCC compilers can't have a 6502 backend too.

 

The only real challenge is supporting the zero-page and indirect addressing schemes. Maybe the avr-gcc code could even give you ideas on how to accomplish this.

 

Oh, tried this about 15 years ago when I was using the 68HC12 gcc. But hacking gcc is a real pain. On the HC12, the linking was the real challenge. But for the Lynx, one can maybe use the cc65 linker.

 

But the "fun factor" is what's driving me. And gcc-hacking is no fun. By no way. :-)

 

Anyway, my problem is: I have a dozen of ideas what I want to do with the Lynx and the Jaguar (and other fancy stuff like octa-cores).

So, it's likely I won't follow this road to its end.

But hey, I will put my stuff on github, so maybe ...

[carlsson]

I don't know if you'd be interested in this thread over at the Atari 8-bit computer section: http://atariage.com/forums/topic/276141-gcc-6502-vs-cc65/

[42bs]

Now, that's cool. Thanks for the link/hint.

 

I will give it a try.

[42bs]

Now, that's cool. Thanks for the link/hint.

 

I will give it a try.

 

I could compile it on ubuntu 16.4.6 and it works. Cool!

So, I can stop this project, up to the next one ...

 

 

For info: Could compile it on Ubuntu 16.4.6, but

apt-get build-dep gcc-4.8

fails. So I did

 

sudo apt-get install libgmp-dev libmpfr-dev libmpc-dev

 

and build worked like a charm (ok, replace -j 4 by -j 8 ).

Edited March 5, 2019 by 42bs

[+bhall408]

On a tangent, how about porting Deep Blue C (which was itself a port of Tiny C) form Atari 8-bit to Lynx?

 

The source code had been available as part of "Deep Blue Secrets" which APX (Atari Program Exchange) sold.

 

So it would be possible to compile that for use on Mac (as linux/command line tool) or Win (cygwin?)

 

Back in the day, I'd used that to make my own tweeks to DBC to be able to squeeze a few hundred extra bytes out.