By: Etienne (etienne_lorrain.delete@this.yahoo.fr), February 26, 2013 6:01 am
Room: Moderated Discussions
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.
I did quite like the "BOUND %e?x," assembly instruction of ia32 to generate a trap, not sure why it had gone - maybe not enough users, or the only (?)
instruction generating two memory read access.
At least that BOUND instruction was not encoding target addresses of jumps, it was short in code size.
Also, note that an unsigned overflow is easy to regenerate with only the resulting value and one of the operand: if the result is smaller than an operand you had an overflow.
> 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.
I did quite like the "BOUND %e?x," assembly instruction of ia32 to generate a trap, not sure why it had gone - maybe not enough users, or the only (?)
instruction generating two memory read access.
At least that BOUND instruction was not encoding target addresses of jumps, it was short in code size.
Also, note that an unsigned overflow is easy to regenerate with only the resulting value and one of the operand: if the result is smaller than an operand you had an overflow.
