I'm considering a simple extension to the assembler to help us manage
the register allocation.  It involves two new sets of registers q0..q31
and p0..p31 which can be aliased within a declared scope:

        frame ; starts the scope for "alias" and "protect" directives
        alias q0..q1 = r3..r4   ; Locals.
        alias p0..p2 = r5..r7   ; Parameters.
        protect r8..r31         ; Not used by this subroutine.
                                ; The remaining r0..r2 are scratch.
a_function:
        ...
another_entry_point:
        ...
        endframe ; clears all register aliases and protections

The intended use of register aliases is to hold local variables which
should not be scratched by subroutines (p for parameters, q for other
locals).  The idea is that while coding a subroutine, we may need to
introduce a new call which will scratch some of the current local
variables.  If the locals are aliases, they can be re-alias to higher
numbered r-registers.  Thus, we can postpone freezing the register
numbers of parameters and locals until the subroutine is finished.

I think the important rules to make this feasible is that

  * An aliased r-register may not be referred to directly, but only
    though its q- or p-alias.  This is to prevent code which
    accidentally overwrites its own locals, and it also gives us a
    chance to discover overwrites within calls, as explained below.

  * Each r-register may only be aliased once within a frame, and p- and
    q-register may not appear on the right hand side of an alias
    directive.

When calling a subroutine, we still use r-registers (which is in our
"scratch" space) to refer to parameters.  Since these parameter by
convention are the highest numbered registers used by the subroutine, we
have a fair chance of detecting if the call will scratch any of our
local or protected registers.

The way this is formulated, we could check that local variables are
preserved by all calls by checking them against the "protect" directives
of the frame of the target labels, but I'll leave this out for now.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to