From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 1999-07-16 22:10:43
I'm currently adding register variables to the compiler, but unfortunately I
run into a problem that seems unsolvable. I would be glad for any help.
Register variables are actually zero page locations. The current
implementation reserves a few bytes in the zero page for this purpose. The
available space is used in a "first come first served" manner, that is, for
each variable with storage class "register" zero page space is allocated until
the space available for register variables is exhausted.
To make the functions with register variables reentrant, the old values of the
register variable locations are saved onto the stack, so each function has the
whole register variable space available. The problem occurs when pointers to
register variables are involved:
void anyfunc (void)
{
register char c; /* First byte in register variable bank */
register char unused; /* Second byte */
f (&c);
}
void f (char* s)
{
register char i; /* First byte, same address as c */
for (i = 0; i < 5; ++i) {
....
}
}
Variable c is assigned to the first byte in the register space. When calling
f(), a pointer to this location is passed. Unfortunately the variable i will
occupy the same space as c: The old value is saved and the storage is reused.
A store operation to *s (which points to c) will now overwrite i instead of c,
since i and c share the same storage.
I know the problem can be solved by generating parse trees for the complete
function, so the problem can be detected before generating code for the
register keyword. But the current compiler implementation does not generate
explicit parse trees, and adding it is a real lot of work, so this is out of
reach for now. On the other side, register variables would be very nice, but
if I don't find a solution for the described problem, I have to remove or at
least disable the already existing code.
Can anyone think of a better implementation of register variables that doesn't
have the described problem, or find some way to work around it? I would be
really glad for any suggestions.
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:44 CET