Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
User Mode Traps
On most existing architectures, a trap results in a mode switch, a jump to the kernel's interrupt handler. For a lot of these jumps, the kernel just raises a signal in the userspace process. For dynamic languages, it would be useful if the traps only caused an unconditional jump and no mode (or context) switch. An example would be an integer overflow or a floating-point exception. The first of these examples is typically handled by promoting the values to big integer objects and retrying the operation. Even things like memory-protection failures would be useful for implementing better garbage collection and distributed objects.
In JavaScript, every Number object has to have the range specified by IEEE double-precision floating-point. If you want a loop counter going from 1 to 100, however, you don't actually need this specification. You're using the floating-point unit on your CPU for integer operations, which is quite slow. Ideally, you would want to create Numbers as integers and only promote them to doubles when they actually need this precision. You can use this strategy now, but it requires an expensive check before or after every operation to see if it results in a rounding error or an overflow.
Related to this issue is the idea of having traps rather than condition flags for rare things. Some architectures have condition flags for integer overflows. These flags can be tested in userspace, but that results in a conditional branch after every integer operation in Smalltalk, which is expensive in terms of instruction cache usage. Since these conditions are exceptional, they should be handled in a way appropriate to their rarity.