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