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.