Re: [PATCH] fix trap in parallel for m32r-sim

[Doug Evans <dje@transmeta.com>]

Kazuhiro Inaoka writes:
 > > i.e. _why_ is "trap || insn" being treated as "insn -> trap".
 >
 > If insn changes SM, IE or C flag, trap will be store wrong value. (rare
 > case?)

I'm not sure I understand.
On h/w the particular case of `trap || insn' doesn't really have
parallel semantics?  In general, if two insns execute in parallel
and write the same resource, the result is undefined.
Or does the m32r spec actually specify a well-defined answer here?

 > When you use "trap || insn", m32r_trap() is executed before executed insn.
 > A m32r_trap() uses a result of insn.

Clearly for the normal case it's a bug if two insns are executing
in parallel and one is able to see the result of the other.
One expects all inputs to be consumed before any results are written
(in general, one might certainly have special cases though).

I can see that m32r_trap violates the semantics for the particular
case of TRAP_SYSCALL but I'm guessing that's not at issue here.

 > ex) trap #2 || ldi r7,#1
 > What want to do is to execute m32r_trap() after second insn.

This example involves insns without overlapping resources,
the insns could be executed serially in either order and the
result will be the same (right?).
Do you have an example where the current simulator implementation
gives a different answer than h/w?

 > > Also, if things are indeed kosher, why the added FIXMEs?
 > It's meaning this patch is not enough to fix it.
 > I think it is a first step.

What's the next step then?  The FIXMEs aren't specific.