[Bug 1561] sparc64 [2/5]: cpukit

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1561





--- Comment #10 from Gedare <giddyup44 at yahoo.com>  2010-06-15 09:39:18 ---
> The floating point context looks essentially the same as on the sparc port.
>   Is it possible to have a "context_switch_sp.S" file which is shared?
sparc64 has more floating point registers (it allows for double- and
quad-precision registers).

> The sparc port flushes register windows on context switch.  Isn't this
>   an issue on this port?
This remains an issue, but it is now a machine instruction called flushw.

> is it possible to share the single sparc tree and ifdef?
As Ralf points out, it is possible.  My feeling is that it will be very messy.

For the cpukit, almost all of the privileged registers are different, register
windows are handled in a wholly different way, the trap table handlers are
different sizes, and how the processor represents the trapped state is
different.  So you would essentially have separate files for all context- and
interrupt-related code, and the sparc.h / sparc64.h files with processor
specific macros and defines should still be separate.  I don't see a plus side.

On a related note, libcpu currently holds the interrupt handling code, which
typically would be in cpukit/score/cpu -- this happened when I tried to support
a simulator that did not have privileged access, so most of cpukit code is
non-privileged.  However, I never got the simulator to work, but that is why
context handling and interrupt handling are separated. It also makes sense
because the interrupt handling is slightly different in sun4v than it is in
sun4u, so it is ifdef'd in libcpu.

In terms of sharing libcpu, it may be a bit easier since there isn't a lot of
code there for the sparc64 at the moment, but if sparc/sparc64 is separate in
cpukit, it probably should be in libcpu as well.  As it stands, libcpu already
has some ifdefs that distinguish between sun4u and sun4v code.  The most
difficult part of merging the sparc and sparc64 is just to make sure the
interface to cpukit processor-specific functions (like privileged register
reads for manipulating the interrupt level or processor state) are consistent. 
I'm not sure how hard this would be, or how messy.

And for the libbsp, I think you would just end up with libbsp/sparc/sparc32 and
libbsp/sparc/sparc64 trees, which seems to me to be unnecessary.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.