In added in the context switching code for the signal processing engine
on the e500 core I noticed that a fair amount of the code matched what
is being down for altivec.
SPE is a 64-bit wide vector engine on the e500 core (it extends the GPR
register file).
I was wondering if it would make sense to change the altivec code to be
more generic and have the SPE code and AltiVec code share the same
functions. It is not possible to have both AltiVec and SPE in the same
processor (they share opcode space).
Changes would include:
CONFIG_ALTIVEC/CONFIG_SPE -> CONFIG_VECTOR
(we would still have some CONFIG_ALTIVEC/CONFIG_SPE for altivec/spe
specific handling)
last_task_used_altivec -> last_task_used_vector
giveup_altivec -> giveup_vector
dump_altivec -> dump_vector
enable_kernel_altivec -> enable_kernel_vector
I am not sure about what to do about ptrace. We extended the interface
to have two new request types (PTRACE_GETVRREGS, PTRACE_SETVRREGS)
which return the full altivec state (all registers, vscr, vrsave). We
could overload these request types to return all the 'vector' state
depending on which processor we are. This would mean debuggers would
have to know which processor we are to know how big of a buffer to have
for ptrace calls, the memory layout, etc.
We also extend generic vector idea to allow dumping of altivec/SPE
register state into core files (which we do not do currently).
If we think this is the way to go, I will make a set of patches for the
2.4devel and 2.5 trees.
thanks
- kumar
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, Oct 03, 2002 at 04:20:14PM -0500, Kumar Gala wrote:
I am not sure about what to do about ptrace. We extended the interface
to have two new request types (PTRACE_GETVRREGS, PTRACE_SETVRREGS)
which return the full altivec state (all registers, vscr, vrsave). We
could overload these request types to return all the 'vector' state
depending on which processor we are. This would mean debuggers would
have to know which processor we are to know how big of a buffer to have
for ptrace calls, the memory layout, etc.
I'd rather see you do it the other way around: Add PTRACE_GETSPEREGS
in the e500, so that the debugger can use ptrace to figure out which
registers are available.
We also extend generic vector idea to allow dumping of altivec/SPE
register state into core files (which we do not do currently).
That's a great idea. Again, I think Altivec and SPE registers should
be tagged differently even though they can't coexist.
Otherwise, it sounds like a good idea to me.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thursday, October 3, 2002, at 04:31 PM, Daniel Jacobowitz wrote:
On Thu, Oct 03, 2002 at 04:20:14PM -0500, Kumar Gala wrote:
quoted
I am not sure about what to do about ptrace. We extended the
interface
to have two new request types (PTRACE_GETVRREGS, PTRACE_SETVRREGS)
which return the full altivec state (all registers, vscr, vrsave). We
could overload these request types to return all the 'vector' state
depending on which processor we are. This would mean debuggers would
have to know which processor we are to know how big of a buffer to
have
for ptrace calls, the memory layout, etc.
I'd rather see you do it the other way around: Add PTRACE_GETSPEREGS
in the e500, so that the debugger can use ptrace to figure out which
registers are available.
This seems reasonable, make life easier on the debugger.
quoted
We also extend generic vector idea to allow dumping of altivec/SPE
register state into core files (which we do not do currently).
That's a great idea. Again, I think Altivec and SPE registers should
be tagged differently even though they can't coexist.
I was thinking, by doing this we can add a dump_vector into the generic
code that handles the creation of core files.
- kumar
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/