Efficient C for 8 bits (a whitepaper)

[JamesD]

A whitepaper of writing efficient C code for 8 bit micro-controllers.

http://homepage.cem.itesm.mx/carbajal/Microcontrollers/ASSIGNMENTS/readings/ARTICLES/jones98_efficient_c_for_8bit_mcu.pdf

[flashjazzcat]

Excellent - thanks!

[JamesD]

I guess I should have pointed out that this applies to any regular 8 bit microprocessor as well as microcontrollers.

The advice in the whitepaper directly applies to the 6502, Z80 and 6809.
6809 and Z80 shouldn't have any special 8 vs 16 bit issues though 8 bits will always be faster.
The 6502 only has 8 bit registers so some of the advice is very important when using it.

People using a TI-99/4a or 65816 compiler might want to experiment with 8 vs 16 bit use.
Using 16 bit (unsigned int) might be more efficient on the TI but I've only studied it's assembly a little bit and the TI-99/4a architecture has some unique limitations.
Due to the mode switching that takes place to change between 8 and 16 bits on the 65816, it may be more efficient to use a 16 bit loop counter when dealing with 16 bit data and 8 bits when dealing with 8 bit data within a loop. The 16 bit loop counter will take an extra clock cycle for each access but mode switches also take clock cycles. I'm not sure which would be slower but using the 16 bit counter should eliminate mode switches for smaller code. I have ORCA C on my IIgs but I have not tried this yet.

For anyone that wants to develop for a 6800 or 6803 compatible cpu, I haven't seen a free native code generating C compiler for either. The lack of stack relative addressing, no page zero pointers to index off of and a single index register would make efficient compiler output a challenge. The rules in the white paper would certainly apply and I would thing many more related to how a specific compiler deals with these issues. There are some commercial C compilers for these cpus though and I'd be interested if anyone has any experience with them.

[jhd]

What about another high-level language, such as Pascal? I assume that it would suffer from the same issues, only more-so because it is even more abstracted from the underlying hardware.

 

I know that there were a few different implementations for Pascal for the Coco, but I never used them, and I do not know if they were used for any commercial software development.

[JamesD]

What about another high-level language, such as Pascal? I assume that it would suffer from the same issues, only more-so because it is even more abstracted from the underlying hardware.

 

I know that there were a few different implementations for Pascal for the Coco, but I never used them, and I do not know if they were used for any commercial software development.

Pascal is very different from C.

The short answer is... it depends.

The suggestions for C are mostly related to the use of bytes and some idiosyncrasies of the C language which have no equivalent in Pascal.

It's impossible to force the use of bytes in Pascal unless a compiler supports it. You can define byte and unsigned byte data types and arrays... you just can't guarantee the compiler will recognize them for what they are and generate byte oriented code.

And then there is the PCode vs Assembly issue with different 8 bit Pascal compilers.

 

You can take a stab at it using byte sized data types like this but I make no promises it will be more efficient than using integers:

type
  byte            = 0..255;
  signed_byte      = -128..127;
  ByteArray       = packed array[0..255] of byte;
  SignedByteArray = packed array[0..255] of signed_byte;

[carlsson]

Although I've never managed to wrap my head around it, I believe Forth is one of the better suited languages for 8-bit platforms, if you want something faster than compiled Basic and slightly less code than macro-enabled assembly code. There may be other, specialized languages for individual platforms but few that are supported on a wide range of CPU's and systems.

 

As for various C compilers, some come with tips and clues how to use them most efficiently. A lot might already be covered in the above whitepaper, but it often pays off studying the particular compiler, e.g. which shortcuts and improvements CC65 prefers when compiling for 6502. Some think it is a poor compiler. Personally I don't know, I haven't tried any other C compilers for 6502 systems although I know there used to be both commercial ones and perhaps even an obscure gcc port, IIRC?

[JamesD]

Although I've never managed to wrap my head around it, I believe Forth is one of the better suited languages for 8-bit platforms, if you want something faster than compiled Basic and slightly less code than macro-enabled assembly code. There may be other, specialized languages for individual platforms but few that are supported on a wide range of CPU's and systems.

 

As for various C compilers, some come with tips and clues how to use them most efficiently. A lot might already be covered in the above whitepaper, but it often pays off studying the particular compiler, e.g. which shortcuts and improvements CC65 prefers when compiling for 6502. Some think it is a poor compiler. Personally I don't know, I haven't tried any other C compilers for 6502 systems although I know there used to be both commercial ones and perhaps even an obscure gcc port, IIRC?

 

 

Forth is good for 8 bit systems because it's a compiler and an interpreter. The compiler generates something similar to PCode though specific to Forth. So it's not as fast as assembler but it generates small code. Unless you have a Forth implementation with a lot of extensions (words) for your system, you are writing about everything from scratch and I think it's more cryptic than assembly for most people. Someone wrote a game for the TI-99/4a in Forth but you won't see that very often.

 

You need to know the compiler specific features, optimizations or limitations of any compiler you choose to get the most out of it.

 

CC65 has a ways to go for full ASNI C support and the stack handling overhead doesn't lead to the most optimal code. I believe LCC is better speed wise, it has better ANSI support and output is a little closer to hand written assembly, but you have to watch memory and stack usage if I remember right. I've seen the gcc port for the 6502 available but it's a very obsolete version of gcc and I'm not sure it was even fully debugged. Being such an old version of gcc it wouldn't provide some of the later code optimizations that would favor the 6502 like the ability to use virtual registers on page 0.

gcc is huge and will soon be replaced by another compiler that is smaller, faster and generates better code.

 

If speed isn't the first concern for most of the program, you could use a Pascal or C compiler that generates PCode. PCode is small and fast (similar to Forth output). With some external libraries/procedures written in assembly for speed critical stuff you can get some pretty impressive results. Wizardry was originally written in Apple Pascal (a PCode compiler) with some procedures written in assembly for graphics, sound and other things that needed maximum speed. PCode is also platform independent, you just need an interpreter for each platform rather than a totally different compiler. Libraries and hardware would be different so you can't really use the same PCode for every machine but you only need one good PCode compiler to use with any system.

 

To me, the ideal solution would be a compiler that can generate assembly and PCode and you could link them together. Then you could use PCode for stuff that isn't speed critical and assembler output for stuff that needs to be fast. I haven't seen a compiler that does this for any 8 bit... yet.

 

*edit*

You can download LCC with the Oric SDK here:

http://osdk.defence-force.org

Edited October 31, 2013 by JamesD

[JamesD]

Apple people could try this version of Aztec C
http://macgui.com/usenet/?group=2&thread=6092&id=23439&start=0