Googling has turned up a few links but most are for defunct OS's (eg FLEX). Assemblers are still around as a last resort.
I'm hoping for something that'll run under DosBox at least - although I'm guessing that the 6800 was already way obsolete but the time PC/MSDOS emerged.
Another avenue might be whether the GNU 68HC1X compilers can be pressed into service - anyone tried this?
The HC11 has more registers and opcodes, code for it won't run on the 6800. 6802 was 6800 compatible, I think 6801 also was but I am not sure, never used it. I never used the 02 either but did clone/extend a kit (D5) for the 6802 on a 6800.
I am not sure there has ever been a C compiler for the 6800, I'd be surprised if there has been one really. Would have been quite useless for those tiny systems anyway. My programming started using pencil and paper to write the assembly code, then manually assemble it using the processor manual then enter it into my kit, debug and run :D . I think I can still read some 6800 object code :D :D .
ISTR there were minor differences between 6800/6802 and 6801/6803. It was easy enough to write code that would run on either but you had to watch out for the odd exceptions both ways. It was when you got up to the 6809 and its derivatives that 68xx compatibility completely went out of the window.
Returning to the OP's issue I have hazy memories of coming across a Small-C derivative for the 6800. I probably have a copy of it around somewhere but it'll suffer from all the limitations Small-C always had - K&R syntax, no floating point, no structures, only single dimensional arrays. Dave Dunfield's Micro-C targeted many processors of that vintage too and ISTR the source is a free download now. I know it targeted the 6809, can't remember about plain 6800, but it was designed to be easy enough to write new back ends for and the manual actually described what was needed in some detail. That wasn't much more capable than Small-C but did at least support multi-dimensional arrays.
I'll have a look around my hard drive and see if I can find anything.
The 6800 (6801, 6802, 6803) is very tight on data handling paths: there are two 8-bit accumulators (A and B) which must be used for nearly all data moving. There are also two
16-bit registers, X and SP, but due to their special uses, they are less usable. IMHO, compiling C for this architecture is at least challenging.
The first 680x processor suited for running C is 6809. The
The current atmega devices are equivalent to a 6800, except they have a /less/ pleasant architectures for C programs. Most people program them in C, using a cross compiler.
But in the early 80s cross-compilers were a luxury: most people used *self-hosted* compilers. The major "challenge" I found was that, on a CP/M-Z80 system with two floppies, there was barely enough space for the compiler's symbol table.
I never programmed 6802 or 6809 in anything other than assembler but we did several 68HC11 projects in C.
BTW the 'hc11 is not a derivative of the '09, the '09 had additional registers and lea (load effective address) instructions which never appeared elsewhere.
Bytecraft have compilers for 6805 and 6808, if that is any help (I am not familiar with the 6800, so I don't know the details). Bytecraft tools are not cheap, especially if this is just a hobby, but they do a great job at a very difficult task. And I'm sure that if you email Walter Banks at Bytecraft, he will give you helpful advice.
The AVRs (including the Mega) are a world apart from these old 8-bit accumulator-based designs. While they have a few C-unfriendly issues (too few pointer registers, poor stack addressing modes), they are far easier for C. There is a reason why there are several good AVR C compilers available in a range of price categories.
Killer for me was the separate code/data memory address spaces. #pragma PROGMEM and so forth. Putting some constant structures in flash ended up infecting most of the program with weird typedefs and special versions of library functions everywhere.
I think in principle the compilers could have made all of this invisible, but none of them did AFAIK.
As far as I know the only commercial C compiler for the 6800 was part of the HP development system no longer produced or supported. This did indeed translate C into code that would run on the 6800 and that is about all that could be said for it.
The 6800 was phased out before the availability of basic compiler technology needed to produce an asm competitive compiler for 6800. The 6800 evolved into 6811 and 6805. The
6805 is a 6800 with a single accumulator and different codings for the ISA.
The 6805 was our first C compiler project. The code generated for the 6805 will not run on a 6800.
Yes, that's another serious C-unfriendly issue with the AVR - no doubts there. But it's still /much/ better for C work than the 6800 or similar architectures, which was my point here.
You can't make the memory spaces invisible to the programmer without a lot of inefficiencies, as it requires fat pointers. Compiler optimisations can perhaps reduce the overhead a bit, but it would still be there. But if you are happy to pay the price of 24-bit pointers, gcc obliges:
Imagecraft had a different idea (at least when I used their AVR compiler, which was a long time ago) - they made "const" mean "flash". That let you write most C code in a natural way, and const data got put in flash. But it meant that converting a non-const pointer to a const pointer would cause disaster, which was a bad idea.
Indeed.
The msp430 is probably the smallest cpu the is /really/ C friendly.
Hah! Not to some extent may be, but I won't agree with the "at all" :).
I have only a vague idea of the register model of the atmega, but:
-is it unable to add 8bits (not to speak of 16) to a 16-bit register?
-is it unable to access data relative to its sp so one has to constantly do tsx/txs (6800 lingo) and be able to access things only at an 8 bit fixed, unsigned offset from X after that?
It the answers to these are "yes" we are closer to your "not at all" but still a long way from it - namely,6800 systems regarded a 2K EPROM as a huge space for an embedded project. It will take 20k to fit the equivalent C code using a C compiler - if you are lucky and if the compilers have become better than I expect them to be.
On the 6809 under MDOS09 there was a pascal compiler. I played with it for a few months - I was learning the trade then. Man it was moaning and puffing with the floppies clicking the head load/unload for half an hour for not that long pieces of code :D :D . Was pretty good though (integer only), my main gain was to understand the difference between high an low level programming. Had enough time to think about it while waiting for the compiler :D :D. Basically high level is a good thing if the underlying architecture/register model is dirty/inconvenient and hiding it makes the programmer more efficient. I am glad I had the stomach to stay with architectures I did not find ugly and inconvenient (like the hugely popular x86 was, nowadays ARM which is not as ugly, just limiting). Cost me a fortune from a consumer point of view but the feeling when you look 20+ years back and like what you see to a point you still want to keep on building on it is good, I suppose it is irreplaceable.
Yep, I was about to post something in that sense but turned out I am not the only one here who remembers that :-).
I grew up on 6809 assembly, RASM09 / RLOAD were used a lot :). In fact I can still run them on an emulated th9 machine in a dps window, haven't done so for ages though (
formatting link
). Last year or so I undug my first ever CPU board (early 80-s, done as a hobby project), here are its remnants (was 100% populated back in the day):
formatting link
. Was running MDOS09, it was the one I used to play with the pascal compiler I mentioned elsewhere (along with other boards on that bus).
Imagecraft now uses "__flash" to indicate that an object is in the AVR's program memory space, so the overloading of "const" (which was handy but had pitfalls, as you point out) is no longer supported. There are also additional library functions (e.g., char *cstrcat()) where the constant object is in flash.
Yes sorry, drifted off the point there. Actually would be fine for most deeply embedded programs, I ran into trouble when trying to do GUIs with big constant structures like fonts and menus.
Those must have come after I abandoned AVR for new development. Inefficient as you say.
I thought that was standard behaviour for embedded, e.g. I thought the gcc toolchains put constants into a read-only segment that the link script puts in flash.
I admit I under-use "const".
Yes never tried it but would look into it if needed something really small/low power. Everyone had nice things to say about it. I seem to recall it did not have a proper gcc port when I would have been in a position to use it last, so I went with ARM.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.