27 ms·
Be interesting how this contrasts with the cc65/ca65 tool suite, which is pretty complete I think in terms of assembling, linking, and libraries. (Discounting t
by whartung 3y ago
Be interesting how this contrasts with the cc65/ca65 tool suite, which is pretty complete I think in terms of assembling, linking, and libraries. (Discounting the actual C compiler part.)
- classichasclass 3y agoPretty good, I think! (Maintainer.) What I liked best about it is the portability, the scoping, and the preprocessor, which I prefer in particular to how many other assemblers do macros, and that's why I ended up taking it over (though Andre still did a lot of the code in this release too). The linking is not something I personally use much but other people do, and the O65 binary object format it uses covers a lot of use cases.
- ngcc_hk 3y agoThanks. Given I am using ca65 (not even cc65), do you mind anything I should take into consideration for trying yours. Other than for the old time sake.
- wiz21c 3y agoca65 is very complete but the linking phase is tedious. I prefere something more direct like acme which just spits the bytes.
- whartung 3y agoArguably when compiling/assembling is "free", outside of using precompiled code without source code, there's little reason for the linking phase. Ostensibly it was faster to link precompiled code than to constantly recompile it. But even back with Turbo Pascal, I think that was called into question. Especially as the CPUs went faster and faster, and memory expanded, but I/O dragged behind. Now, I don't think anyone would blink at constantly rebuilding 100K lines of assembly. It takes seconds on modern hardware. We even see that in the C world with large utilities shipped as a ".h" file.