* [sim/mips] Proposed change to mips_core_signal
@ 2001-02-12 14:35 Ben Elliston
2001-02-12 19:21 ` Chris G. Demetriou
0 siblings, 1 reply; 4+ messages in thread
From: Ben Elliston @ 2001-02-12 14:35 UTC (permalink / raw)
To: cgd, cagney; +Cc: gdb, bje
I am working on a simulator port to a MIPS-like core that has a vector
processing unit. To produce more helpful diagnostic messages, it
would useful if mips_core_signal() could differentiate between scalar
memory transfers and vector memory transfers.
Are there any objections to adding two new elements to the
_transfer_type enum in sim-basics.h to identify such transfers?
Ben
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [sim/mips] Proposed change to mips_core_signal
2001-02-12 14:35 [sim/mips] Proposed change to mips_core_signal Ben Elliston
@ 2001-02-12 19:21 ` Chris G. Demetriou
2001-02-12 19:39 ` Ben Elliston
2001-02-12 21:27 ` Ben Elliston
0 siblings, 2 replies; 4+ messages in thread
From: Chris G. Demetriou @ 2001-02-12 19:21 UTC (permalink / raw)
To: Ben Elliston; +Cc: cagney, gdb
"Ben Elliston" <bje@redhat.com> writes:
> I am working on a simulator port to a MIPS-like core that has a vector
> processing unit. To produce more helpful diagnostic messages, it
> would useful if mips_core_signal() could differentiate between scalar
> memory transfers and vector memory transfers.
>
> Are there any objections to adding two new elements to the
> _transfer_type enum in sim-basics.h to identify such transfers?
I have no problem with it, but it's not clear that I know enough to
object.
(It doesn't really seem like this is a MIPS-specific issue either,
except that your port is MIPS-ish, right?)
chris
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [sim/mips] Proposed change to mips_core_signal
2001-02-12 19:21 ` Chris G. Demetriou
@ 2001-02-12 19:39 ` Ben Elliston
2001-02-12 21:27 ` Ben Elliston
1 sibling, 0 replies; 4+ messages in thread
From: Ben Elliston @ 2001-02-12 19:39 UTC (permalink / raw)
To: Chris G. Demetriou; +Cc: cagney, gdb
Chris G. Demetriou writes:
> I have no problem with it, but it's not clear that I know enough to
> object. (It doesn't really seem like this is a MIPS-specific issue
> either, except that your port is MIPS-ish, right?)
It's more than a MIPS-specific issue. It potentially impacts all
simulators, since it alters the _transfer_type enum. Something like:
--- sim-basics.h 2000/03/02 09:10:00 1.23
+++ sim-basics.h 2001/02/13 03:37:56
@@ -111,6 +111,8 @@
typedef enum _transfer_type {
read_transfer,
write_transfer,
+ read_vector_transfer,
+ write_vector_transfer,
} transfer_type;
Ben
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [sim/mips] Proposed change to mips_core_signal
2001-02-12 19:21 ` Chris G. Demetriou
2001-02-12 19:39 ` Ben Elliston
@ 2001-02-12 21:27 ` Ben Elliston
1 sibling, 0 replies; 4+ messages in thread
From: Ben Elliston @ 2001-02-12 21:27 UTC (permalink / raw)
To: Chris G. Demetriou; +Cc: cagney, gdb
Chris G. Demetriou writes:
> > I am working on a simulator port to a MIPS-like core that has a vector
> > processing unit. To produce more helpful diagnostic messages, it
> > would useful if mips_core_signal() could differentiate between scalar
> > memory transfers and vector memory transfers.
> > Are there any objections to adding two new elements to the
> > _transfer_type enum in sim-basics.h to identify such transfers?
> I have no problem with it, but it's not clear that I know enough to
> object.
I've found a cleaner way of implementing this that does not affect
sim/common code. Forget this thread ever existed!
Cheers, Ben
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-02-12 21:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-12 14:35 [sim/mips] Proposed change to mips_core_signal Ben Elliston
2001-02-12 19:21 ` Chris G. Demetriou
2001-02-12 19:39 ` Ben Elliston
2001-02-12 21:27 ` Ben Elliston
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox