By: TREZA (no.delete@this.ema.il), February 26, 2013 4:53 am
Room: Moderated Discussions
EduardoS (no.delete@this.spam.com) on February 26, 2013 2:55 am wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 25, 2013 8:18 pm wrote:
> > The concept of explicitly testing for arithmetic overflow for every possible operation seems excessive.
> > Generating an exception (handled in user mode) would seem to avoid excessive test instructions.
>
> Yes and no:
> Yes for, really, testing every instruction is a pain, but required in some cases;
> No for, instead of testing when required means every instruction will pay
> the opcode space tax, even the check is only needed in some cases*
MIPS have for ADD and SUB the two variants "trap on overflow" / "don't trap on overflow" instructions. (ADD/ADDU, SUB/SUBU)
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 25, 2013 8:18 pm wrote:
> > The concept of explicitly testing for arithmetic overflow for every possible operation seems excessive.
> > Generating an exception (handled in user mode) would seem to avoid excessive test instructions.
>
> Yes and no:
> Yes for, really, testing every instruction is a pain, but required in some cases;
> No for, instead of testing when required means every instruction will pay
> the opcode space tax, even the check is only needed in some cases*
MIPS have for ADD and SUB the two variants "trap on overflow" / "don't trap on overflow" instructions. (ADD/ADDU, SUB/SUBU)
