I couldn't help but notice that the current parrot interpreter
generates a divide-by-zero error when executing 'div I0,I1,0'. I'm
currently packaging up a set of patches that adds the following set of
features to parrot:1) An exception stack (The stack prefix is 'E') 2) Instructions push_e, pop_e, set_e_i, set_i_e 3) Alters div_i_i_ic to raise an exception when dividing by the constant 0 4) Added t/op/exception.t to test the div_i_i_ic instruction. Having the virtual machine die was, to me, unacceptable. Skipping the 'div' instruction was also unacceptable, at least without signaling an exception. One way to signal an exception would be to create a bitfield of exceptions, where bit position 1 would signal 'divide exception' on. This would limit the number of exceptions to the number of bits in the register, which would be fixed at the time of creation of the register. Limited and inflexible. Another solution was to write a special set of integers onto the int stack which would signal an exception. Also bad because it would take a long time to test for the special set of integers. Pushing a special string onto the string stack would have the same problem. Having a separate exception stack keeps the special information out of bounds, and assigning one integer to each exception (Say, 1 = DIVIDE_BY_ZERO, 2 = NAN_I0, 35 = SOCKET_CLOSED) means that we have an effectively unlimited number of exceptions available. Because it's an exception stack, the user can preserve previous exceptions at will. For instance, catching a divide-by-zero error might look as follows: pushe # Save previous exceptions div I0,I1,0 # The bogus operation eq E0,E_DIVIDE_BY_ZERO,FAILED pope # No error occurred, go on with life branch CONTINUE FAILED: print "DIVIDE-BY-ZERO\n" end CONTINUE: add I0,I1,3 # Go on with life. Of course, divide-by-zero is a simple error to catch. However, this technique can be extended to mathematical errors like square roots of a negative number, I/O errors like writing to an illegal filehandle, and it should be able to handle IEEE math, with any luck. -Jeff <[EMAIL PROTECTED]>
