C Development

C Compilers

• cc65
• Calypsi
• llvm-mos

List of "Gotchas" for llvm-mos

1) When trying to use the EMBED directive in order to put data at specific memory locations, keep in mind that you CAN'T comment those lines out with /* and */, the compiler will try to follow them whether they're in them or not. The only way to comment them is to use //.

2) When trying to use the EMBED directive, you may want to put your assets in a subfolder of your project. As in, assuming your source files are in ./src/ (where '.' is the root of your project) and your assets are in ./assets/, then you WILL need to refer to your asset files like so: EMBED(myassetname, "../assets/myassetfile.bin", 0x10000);. Note the weird ../ folder backtracking that has to be used. No other combination worked for me (-Mu0n)

3) In the f256dev/ folder, the f256build.bat file contains all you need to compile and link your project. In the "call mos-f256-clang.bat" line, one important switch is the optimization level you let the compiler use. Experiment with -O1 (no optimization), -O2 (some) and -O3 (most). Some operations and repetitions work with some and fail with others. One prominent example of where it failed was a repetitive fileRead operation that read and parsed little chunks of data from a file, byte by byte and while it compiled and linked, it failed during execution. By reducing -O3 to -O2, it all worked again.

4) One linking error kept giving me "ld.lld: error: ld-temp.o <inline asm>:2:1: operand must be a 16-bit address sta (mos8(.LpickAudioFile_zp_stk+4)" despite not having written any inline assembly in my project. You can skirt around the issue for the problematic function by adding a compiler attribute: __attribute__((optnone)) right before your function definition.

5) When your code nears a size of 0x9400 and above, you may get in trouble in terms of code not being fully loaded into RAM while executing. Either deliberately put some code into far memory and devise a scheme with the MMU to swap that code in and out of reach for the CPU, or you can carve yourself a bit more space by editing f256dev/llvm-mos/mos-platform/f256/lib/link.ld and change:

/* fake C Stack */

PROVIDE(__stack = 0xA000);

to

/* fake C Stack */

PROVIDE(__stack = 0xC000);

to get yourself an extra 8k of code space before it collides with the stack

6) The compiler will often complain about a missing closing curly bracket '}' at the end of your source files. Just add the one it requires at the very end even though it's an extra one, or, finish your source file by putting your last function with this notation:

void myLastFunction(uint8_t whatever) {

//bunchacode

}