Fwd: Raw instruction code on sparc64?

[Andrew Whitworth]

oops, clicked reply" instead of "reply all".

--Andrew Whitworth


---------- Forwarded message ----------
From: Andrew Whitworth <wknight8111 at gmail.com>
Date: Tue, Feb 3, 2009 at 11:48 AM
Subject: Re: Raw instruction code on sparc64?
To: Mark Glines <mark at glines.org>


On Tue, Feb 3, 2009 at 11:25 AM, Mark Glines <mark at glines.org> wrote:
> Hi,
>
> There's some code at the top of trace_system_areas() in src/gc/system.c
> to flush the register windows on sparc.  The code in question:
>
>        /* Flush the register windows. For sparc systems, we use hand-coded
>           assembly language to create a small function that flushes the
>           register windows. Store the code in a union with a double to
>           ensure proper memory alignment. */
>        static union {
>            unsigned int insns[4];
>            double align_hack[2];
>        } u = { {
> #  ifdef __sparcv9
>                            0x81580000, /* flushw */
> #  else
>                            0x91d02003, /* ta ST_FLUSH_WINDOWS */
> #  endif
>                            0x81c3e008, /* retl */
>                            0x01000000  /* nop */
>        } };
>
>        /* Turn the array of machine code values above into a function
> pointer.
>           Call the new function pointer to flush the register windows. */
>        static void (*fn_ptr)(void) = (void (*)(void))&u.align_hack[0];
>        fn_ptr();
>
>
>
>
> According to "svn blame", some of this code dates all the way back to
> 2002, so I'm not really sure who to ask.  We have reports of failed
> builds on sparc64/openbsd (see Trac #271) which raised the question:
> will this code work on sparc64?

For the record, this code used to be located in src/cpu_dep.c, but I
moved it to src/gc/system.c earlier this week as part of the GC
cleanups. The purpose of this function is to extract pointer values
from the general-purpose registers of the host processor, and have
them be stored somewhere on the stack. With this done, we then scan
through the entire stack looking for pointers to mark as "alive" in
the GC.

A few points:
1) I don't know why Sparc9 and IA64 are treated specially here, don't
they have PARROT_SET_JMP on those platforms? Or if it does, doesn't
setjmp do what it should be doing there?
2) I don't like the idea of hand-coded assembly here in the C. It
certainly is a clever solution, but terribly unreadable and
non-portable. Better would be to include a separate assembly file and
have it be assembled at build time on systems that need it. We already
do this for IA64 in the file config/gen/platform/ia64/asm.s, I think
we should be able to do this for Sparc9 as well. Do we have anybody
knowledgable in Sparc9 assembly?
3) I can't speak for whether or not this code does what it claims to
do or whether it's portable to 64-bit systems. I suspect that it is
not.

Fixing this whole situation is definitely part of the ongoing GC
cleanups that need to happen, probably before 1.0.

--Andrew Whitworth