Re: [cc65] Temporary zero-page allocation

From: doynax <>
Date: 2013-10-27 20:28:43
On Sun, Oct 27, 2013 at 7:59 PM, Ullrich von Bassewitz <>wrote:

> 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.

I think I may have confused the issue somewhat by speaking of registers.
I'm mostly concerned with zero-page allocation in assembly code, not C.
Though of course the latter would be most welcome as well if it save space,
I'll try out the register keyword on a few candidate functions to see
whether it saves space.

In a perfect world the C optimizer would perform global optimization and
assign (overlayed) zero-page variables to all local variables by default,
but as you say that would involve an awful lot of work with plenty of other
lower-hanging fruit along the way.

> 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.

On a related subject.. I haven't dug around much in the code yet but do you
think it would be difficult for me to add more code generations patterns
for zero-page accesses? I remember having trouble (admittedly a couple of
versions back) with zero-page arrays generating absolute addressing code,
something which happens to be central to my game code since the primary
actor attributes are get stored as structures-of-arrays on the zero-page.


To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun Oct 27 20:28:57 2013

This archive was generated by hypermail 2.1.8 : 2013-10-27 20:28:59 CET