This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MIPS div_trap vs. general conditional traps
- To: Greg McGary <greg at mcgary dot org>
- Subject: Re: MIPS div_trap vs. general conditional traps
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 07 Sep 2000 16:15:01 -0600
- cc: gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <200009062017.NAA06786@kayak.mcgary.org>you write:
> I implemented conditional traps for MIPS using the MIPS
> conditional-trap machine instructions for ISA>=2 and using the MIPS
> `break' instruction for ISA==1. I posted the patch last night.
Sounds like a good thing.
> Since then, I have noticed that the MIPS div_trap also generates
> TRAP_IFs, but always translates them to conditional branches to MIPS
> BREAK instructions. Is there any reason why we shouldn't use
> conditional-trap machine instructions for div_trap as well, falling
> back to conditional branches to BREAK only for ISA==1 ?
Because the expansion of division now done by the compiler needed to be
equivalent to what used to be done by the assembler in terms of
break vs trap.
> One reason not to do it is that operating systems might expect div
> traps to come as BREAKs (EXC == 9), rather than as traps (EXC == 13).
Precisely.
> However, since I doubt that OSes do anything other than terminate the
> program that gets a div_trap, and BREAK and trap exceptions probably
> both terminate just as effectively,
You lose the context as to why you had to stop the process. ie, we use
different break #s for the different reasons why we might stop the
target.
> For backward compatibility, we could always provide a `-m' option to
> force branches to BREAKs.
We shouldn't break backwards compatibility to start with.
> Another reason not to do it, and to favor branches to BREAK even for
> general conditional traps is if the conditional-trap machine
> instructions are serializing. My MIPS manuals are silent on that
> issue.
No clue on this one.
jeff