I'm not talking about cavalier code structure. I'm talking about designed code structure that hits the limits of assumptions that the tools and environment enforce. Attempting to get good code reusability, enabling flexible feature configuration, and optimizing to those selected features using lots of assembly-time directives to configure itself, is where I've hit issues with this the most.
As one small example, inside AcheronVM, instructions are defined as 1-liner macro declarations at the point of instruction implementation. This is the easiest way to be able to add and remove instructions, and is optimal in the "don't repeat yourself" organizational/maintenance sense. The jump tables, opcode allocations, and even generating the include files defining VM instruction -> byte macros, are all done at assembly time, respecting differing types of instruction allocations and alignment concerns. However, even with ca65's great support I still have to hop out into writing external helper programs to do things that should (intuitively) be expressable with the currently available directives; it's ordering and resolving constraints on those directives that limits what you can do with them.
BigDumbDinosaur wrote:
As soon as you said "to be compiled as" the rest of your message got lost. Pardon my pedantry. but one does not compile assembly language programs.
Assembly is a strict subset of compilation (the transformation of code from one form to another), so the use of "compiled" is still technically correct.
![Wink ;-)](./images/smilies/icon_wink.gif)
(I've got a lot of Lisp on the brain, which regularly and substantially blurs the line.)