From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-06-24 23:13:35
On Sun, Jun 24, 2001 at 10:44:29PM +0200, groepaz wrote: > yeah, sure.... and it _HAS_ a hard time to figure it out, even in all > c-compilers i have seen ;=) Point taken:-) > yeah you are right ofcoz, and to be honest... i havent even thought to > handle things like this (i wouldnt need them personally) .... BUT i > guess it would be the best idea to work on "precompiled" object > files.... That would solve some but not all problems. You don't have to parse expressions, but you have to handle them, since the object files will contain expression trees for all expressions, the assembler is not able to resolve. > ... what about that > .a64 (right extension?) relocatable stuff your linker can spit out? > maybe thats a good starting point aswell? (but i guess that would > already leave out all info about internal references/symbols etc?!) The linker output is always binary. I've added .o65 support at some time, but it's only about 95% ccomplete and never tested. In addition, o65 is also a very simple format, it contains nothing besides binary stuff and relocation info. It is a real beauty on a real 6502, because it is simple to implement. I've decided against using it as an intermediate format since a lot of more advanced features are missing, and the additional overhead is no problem for a crosscompiler/-assembler. > i really love the idea about not having to mess with expressions (would > make the optimizer hell easier to write and debug) but it would > definetly require more than a plain binary as input to do anything > useful in the optimizer ,=) There is no such thing as free lunch. Which means (in this case), that you either have to cope with expressions and (possibly external) symbols, or rebuild internal program structures from a binary file. In the cc65 tool chain, the linker is probably the one that has the most information available, so adding an optimizer step to the linker would be a viable option. Or maybe a two step approach: One pass in the assember and another one in the linker. To improve the capabilities of the linker, it would be needed to change the assembler to virtualize the code in the object files even more. Currently, the assembler knows about code sizes, adjusts branches and handles symbol references that are internal to one source file. Removing all this knowledge from the assembler and placing it into the linker instead would concentrate all information in one place. A disadvantage would be that the intermediate code (the object files) would get much more complex. As an advantage, much more information about the code is gathered in one place (the linker). Smart branches (use bxx if possible, otherwise use jxx) could be delayed until the linking stage, the linker would be able to inline short subroutines, remove unused code and more. I've avoided this because I feared the really complex object code format, but for a perfect solution, this is a must. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:40 CET