Re: [cc65] Temporary zero-page allocation

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2013-10-27 19:59:06
Hi!

On Sun, Oct 27, 2013 at 09:51:08AM +0100, doynax wrote:
> As the title states I'm wondering whether anyone on the list may have some
> ideas on schemes for dealing with zero-page "register" allocation.

The scheme implemented in the last cc65 version released by me was to
explicitly honour the "register" keyword up to some configurable size (6
bytes). The current contents of the locations used were saved on the stack on
function entry and restored on function exit. This means that register
variables come with some overhead. But especially when used for pointers to
something, code generated for register variables is much smaller and faster,
so there are still many places where they are useful.

Apart from that, there is no handling of zeropage "registers". Since cc65
emits code while parsing (without AST or intermediate code), there is no easy
solution for automatic allocation strategies that don't save and restore the
zeropage contents.

Regarding manually declared zero page locations (using #pragma zpsym): The
fact that these symbols are in the zeropage is completely ignored by the
optimizer. This means that (apart from saving one byte when accessing them)
the generated code does not change.

Since I see no easy solution, the tradeoff between the work needed to
implement register allocation, and the possible space saving is rather bad.
Somebody willing so spend time with the compiler might be better advised to
allow the compiler to generate better code in the first place, or optimize
some of the runtime functions.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
Encrypted email preferred                          PGP Key-Id: 29D93B10
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun Oct 27 19:59:15 2013

This archive was generated by hypermail 2.1.8 : 2013-10-27 19:59:17 CET