From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-08-14 14:37:50
Hi!
On Mon, Aug 12, 2002 at 04:39:13PM -0700, David Holz wrote:
> Hi, I had an idea. I don't know if you guys have thought of it before, but
> using BRK followed by data bytes is a great way to save space in user code.
I've used a similar idea for some time, but have removed it, because it had
several disadvantages. Some may remember seeing code like this in older
versions of the compiler:
jsr ldeax
.dword $12345678
The ldeax routine fetched the return address from stack, loaded the dword
located behind the call, incremented the return address and returned. It needs
one byte more than the solution using BRK, but is somewhat faster, since the
overhead for the call is smaller, and it doesn't need a dispatcher in the
subroutine. But as said above, I've removed this particular sort of code
generation for several reasons:
* The code is difficult to understand. I got several bug reports from
people looking at the generated code, who thought something was wrong.
* The generated code is slow, and the difference is not only some percent.
Data access via the return address is several times slower (in case of a
simple subroutine like ldeax). Using BRK saves one additional byte, but
needs even more cycles, which means it's even slower than the subroutine
solution.
* The optimizer works on 6502 code level. Things like subroutines that
manipulate the return address do not work very well with the optimizer,
in fact, I had severe problems when using code generation like shown
above.
* The optimizer does register tracking (at least for immediate values).
This means that the register loads before subroutine calls are often
not necessary or replaced by transfers from one register into another.
Doing this saves a few bytes/and or cylces and would not be possible
with the embedded data method.
> I see that there's support for setting up the BRK vector from C now; do you
> think that it's used much, because it'd need a bit of work to make it
> interoperate with this (something like making 'brk $ff' the user BRK
> handler).
The current BRK handler is used for the debugger and this brings in a new
problem: Using BRK for subroutine calls would mean that the debugger could no
longer be used for such programs.
So while the idea itself is good, I think it has several disadvantages when
used with cc65.
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 : 2002-08-14 14:39:39 CEST