http://sdcc.sourceforge.net/index.php#News

They just announced work in progress to support the 6502.

it says "mos6502" so i assume they don't mean the W65C02, which is a shame.

Nice to have another C compiler on the block. I used SDCC on an 8-bit PIC project a number of years back and found it to be very good there. It managed to cover the data banking almost transparently, so maybe there is hope for it on the '816 too in the future?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Great news. I also used SDCC for an embedded 8051 project many years ago and found it very capable. It looks to also have support for the 65C02.

I played a little last night with SDCC-4.2.0 (the latest version) in a Linux Mint environment.

First thoughts:
- There is apparently no documentation regarding the 6502, other than a couple of mentions in the sdccman.pdf. Grepping doesn't find anything useful.

- Obviously, putchar() has to be defined if you want to use text input. The error message if you don't complains about a missing '_putchar' but it does not want that leading underscore.

- You're also going to have to include any necessary initialisation of the input mechanism (in my case, it will be a 68B50 uart).

- The mystic incantation (discovered after some trial and error) to build for 6502 is 'sdcc -mmos6502 hello.c' which rather implies that it's assembling base NMOS code (which I'm old-school enough to be happy about; it might not be optimal on a WDC part but it'll run on anything). It didn't like -65c02 or -wdc65c02.

- It seems to be assuming a flat memory model with 64k ram. The hex file starts with a single line: which points the reset, nmi, and irq vectors to $0200.

- The simple test file (as yet unrun, and note it doesn't have the uart initialisation!)

produces a hex file with code from $0200 to $0d30 or thereabouts. I assume that's because it's dragging in the stdio library - printf is always a code hog even without floating point.

Neil

Try puts instead of printf and see how much baggage you omit...

As expected: it's a lot smaller. As I said, printf is a memory hog on every small microcontroller; it drags in too much baggage with it even without floating point.



Neil

I've been playing a little with the sdcc compiler; it's not bad at first glance but it's missing some obvious optimisations:



Those ACIA pointers should be constant pointers to a volatile char - the register content. However, it produces the following assembly:

where it has obviously defined the pointer as a word in memory; it copies it to a temporary word, and reads the byte using (abs),y. It also loops back and loads the pointer address every time. This is obviously generic so a pointer can change between calls - but one might have hoped that the const keyword would have allowed it to avoid the indirect load and the repeated load. Indeed, the ideal optimisation is perhaps a simple lda abs to the register... oh well, the whole point of C is that you don't have to worry about these things

Another bit which is somewhat confusing this early in the morning is if one replaces the

with the hopefully more self-documenting but theoretically identical operation

which changes the generated assembly to

Which includes the requested test but leaves an unnecessary pha/pla hanging around.

All very interesting, but this is the first release. At present there is zero documentation either in the installed codebase or on the wiki page associated; I may have to join their forum so at least I can ask some questions.

I think I'll knock up a quick monitor and see how that works. I've got lots of eeprom space

Neil

Another observation: as far as I recall no flags are set by simply loading a variable on the 6502, but require a cmp, cpx, or cpy operation (or playing games with the flag register via the stack).

In which case, this generated code looks suspicious:

It seems to me that the beq after 00113$ is dependent on the flags on entry to get_line, and not on an actual test. There is a jump to 0113$ later based on a comparison (buffer full) but also one later still which is just a jump.

Am I missing something obvious?

(I have not yet been able to get the code onto a real 6502; my development machine doesn't have the same GLIBC as this one and I'm a bit leery of updating it; there's too much on it. Hopefully over the weekend.)

Neil

Hmm, no, you have that wrong unfortunately: loading a register does set N and Z. (Not so on all other micros, but true on 6502. If in doubt run a few instructions in an emulator: easy6502 is right there in your browser, for example.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thank you gents! I thought I knew this processor - it's only been forty years since I used one in anger

So I looked in the Zaks that's been open on my desktop for the last month and there it is, plain as day... doh!

I think I got confused with the 8080 which I've been recreating at logic level; that one does require an ALU operation to set the flags and the register move and load instructions don't set flags. https://www.pastraiser.com/cpu/i8080/i8080_opcodes.html

Thanks again; I'll keep on plugging on at understanding this compiler.

Getting a little further with the secret incantations:

tells the linker to put the assembled code at 0xe000 (in my eeprom space) and to use from 0x0200 for constants and variables. Default values without --code-loc is to build at 0x0200 and it puts the bss at 0x8000 (where I have an empty hole in the memory map) without the --xram-loc. A --data-loc looked like the obvious switch for the bss but instead it moves the zero page variables...

That done, the code

produces

which outputs the expected '#' from the 68B50.

Neil

> secret incantations
That's good to know, thanks!

When I get to a more complete state of knowledge, I'll knock up a quick how-to. The main things I need to know are

• How to compile anything! (done)
• How to compile code to a given memory map (done)
• How to handle interrupts and the BRK instruction
• How to include assembly code directly

Neil