C compiler requests

[johnwbyrd]

It's common to place code and assets in banks manually, and to pick the memory layout by the game's needs. No automatic system can match the needs of the platform.

Thanks, that's good to know. You'll be able to assign code to sections, and the linker may be able to guess what you want, but you're right that no automatic system can always get the layouts exactly at you want them. The linker scripts will be more like templates than requirements.

Presumably this is about debuggers and debug symbols. I don't use debug symbols for NES development, it's so rare to need the name of a memory address that it's not much bother to look up manually.

Yes, you are correct. Although I suspect that it might be useful to see where C symbols ended up, no?

What's your development pipeline?

Write in my preferred editor, alt-tab to terminal, type 'm' (alias for make -j13). Presumably this is about IDEs and compatibility with those; things like 8-bit workshop or VS code are not that popular.

Got it. Out of the box, the SDK will build all the examples with cmake, but obviously the compiler and linker are build system independent, and you can drop them into makefiles or whatever.

If I'm writing some specific algo, I often write it first on my Linux system, using quality tools like valgrind to make sure it's correct before compiling for the NES.

Which Linux compiler do you use in that case?

Smart packing of memory (BSS/RODATA symbols). This doesn't really exist anywhere, GNU ld at most sorts symbols by alignment, leaving plenty of gaps. Yes, optimal packing algos can be O(n^2) or so, but we're talking 8-bit development here, with banks of 8kb-32kb - N is small.

We got a small part of this right already -- ld-type linking likes to set everything at 4 or 8 byte boundaries, but our backend can (and must) align on single byte boundaries. Several targets, such as Commodore, require it as part of their executable formats. I think the packing problem is combinatorily NP-hard, but the good news is that since we store everything in ELF, you could write a custom tool to do such juggling, without having to write a bunch of MOS-specific code.

However, you may find it hard to gain market share. The main lack in cc65, the leading suite, is its low optimization ability. Even gcc-level optimization may not be worth it to spend time migrating, doubly so if it's not compatible with existing banking and layouts. Any artificial barriers on top, like not being open source or not having an essential capability like manual placement, will just pile on blockers.

Agreed on all that. The project is open source; you'll be able to hack on it. We're trying to make choices between rebuilding everything in ld compatible script, versus providing shims to make ld act like cl65. We think that many of cc65's limitations are rooted in its ABI, which we at the moment, we don't intend to be binary compatible with. In exchange for losing that ABI compatibility, we're able to generate faster code.

IOW, cc65 is "good enough". The C parts rarely need max speed, and the amount of asm in a typical modern NES game is not that big.

You may well be right about that. Still, we are hoping that we can press a lot more use and reuse out of zero page, than other C compilers to date, and we're hoping that the performance improvements will warrant the effort.

[johnwbyrd]

Not really. I've seen people talk about reserving the bottommost bytes for function-local storage or parameter passing. The only hard constraints come from the 6502 core (zero page, stack) and 2A03 augmentations (sprite DMA, DPCM DMA)

Other than the fact that that said DMA must occur from zero page, I don't see any other conventions or limitations on it, am I correct?

[lidnariq]

If by "from zero page" you meant to write "sprite DMA must be from a fully aligned 256-byte page", then yes.

[tepples]

OAM DMA must be 256-byte aligned. It usually comes from work RAM in the console ($0000-$07FF) but may also come from RAM or ROM in the cartridge ($6000-$FFFF).

DPCM DMA must be 64-byte aligned and start in $C000-$FFFF, and the program continues running while it is in progress. For this reason, a few programs dedicate an 8K window at $C000-$DFFF to DPCM playback dedicate even if it means only one switchable window for the rest of the program (as in MMC3, VRC4, VRC6).

[calima]

Yes, you are correct. Although I suspect that it might be useful to see where C symbols ended up, no?

Well, that's the map file, which is unrelated to debug symbols.

Got it. Out of the box, the SDK will build all the examples with cmake, but obviously the compiler and linker are build system independent, and you can drop them into makefiles or whatever.

Curious choice, cmake at least used to be absolutely horrible for cross-compiling.

Which Linux compiler do you use in that case?

gcc. I do occasionally use clang for its static analyzer, but that's getting rarer, as my clang version is older (from before they switched to cmake, making it harder to build it), and as gcc keeps gaining abilities.

[johnwbyrd]

3. Valid ASM6 code is not valid ca65 code. Either the compiler comes bundled with its own counterpart to Binutils (assembler and linker) or it uses an existing one.

Well since this is a new backend to an existing compiler suite, we'll use the binutils that typically accompany that compiler; our assembler currently has 100% NMOS 6502 instruction coverage, and the linker is able to generate binaries for a few platforms already (with NES to come, pending feedback here).

[johnwbyrd]

Curious choice, cmake at least used to be absolutely horrible for cross-compiling.

It's gotten only trivially better -- I had to spend a lot of time looking at cmake internals to get it working. The outputs need to work on N different 6502 platforms, where N is a number somewhere between 4 and 30.

gcc. I do occasionally use clang for its static analyzer, but that's getting rarer, as my clang version is older (from before they switched to cmake, making it harder to build it), and as gcc keeps gaining abilities.

Yes, our compiler's cmake dependency, makes bootstrapping the compiler inconvenient at best. Fortunately, we roll Linux, MacOS, and Windows binaries as part of continuous integration.

[Goose2k]

What are your preferred mappers or memory layouts?
* NROM, MMC1

What are your preferred emulators?
* Mesen mostly, and a little FCEUX.

What's your development pipeline?
* Write code in VSCode, compile with CC65/CA65 via batch scripts (in VSCode), debug in Mesen with C source code.

Anything that you can't do with your current assembler/linker/compiler combination, that you would like to be able to do?
* Nope.

What features would cause you to switch from your current compiler? Performance speedups? Backwards compatibility? Debuggability? Better docs?
* Significant perf improvements with similar bug free code generation and feature set of CC65. I think the existing compilers are quite decent, so I would imagine performance improvements would be the biggest thing for most people, but i might be wrong.

Would you be able to write a good-quality demo to show off the features of a new C compiler and linker?
* From Below is open source, and a full featured commercial release. It could potentially be a good test bed, and also a way of showing off improvements from CC65.

[DarkKobold]

Not to beat a dead horse, but have you considered SNES instead? There's a real dearth of C compilers for that platform, and if you need an end user to test, you can find me and many others, likely.