Lars Brinkhoff <lars@...> writes:
> It's time to start thinking about how to partition the ARM register
> set. With ~16 general-purpose registers, there's a distinctive lack
> of registers compared with other RISC ports. I guess the AMD64 is in
> a similar situation, so what are you AMD64 porters' thoughts on this?
If you're short of ideas on this, I guess the person to ask is Douglas
Crosher. Some brief ideas...
> The conventional/hardware uses of the ARM registers are:
> R0-R3 Caller-saved, used in functions to pass/return values.
> R4-R10 Callee-saved.
> R11 (Number stack) frame pointer.
> R12 Temporary scratch register, usually not saved.
> R13 (Number) stack pointer.
> R14 Link register, used by subroutine call instructions but
> otherwise free.
> R15 Program counter, reserved for hardware use.
> Looking at the PPC port, I see a large amount of registers reserved
> for special purposes: fdefn, nargs, cfunc, bsp, cfp, csp, alloc, null,
> code, cname, lexenv, ocfp, lra, lip. Those alone could occupy all of
> the available ARM registers, so obviously most has to go to leave
> space for a healthy number of function arguments and non-descriptor
> and descriptor temporaries.
> There are some hints: SPARC doesn't have fdefn, and MIPS, Alpha, and
> HPPA doesn't have cname, so I guess those two aren't indispensable.
You could borrow some leaves from the x86 port, I guess: if you made
the lisp stack share with the C stack, you wouldn't need cfp, csp or
ocfp, I think. NULL could be at a memory location rather than in a
register. I don't know enough about the calling convention to give
full answers, but I'm fairly sure that at least one of fdefn and cname
can be removed.
lexenv is I think only used during calls of closures, so within VOPs
can be a temporary; likewise fdefn. Alloc can probably be a memory
location, too. How'm I doing? Does that help?
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)