RE: [PATCHES] Exception idea

2001-10-26 Thread Stephen Howard

If I might make a very small suggestion, for clarity's sake you might want to consider 
renaming your opcodes push_e and pop_e, or
push_x and pop_x.  I don't know if this violates any naming conventions you already 
have in place, however.

-Stephen

-Original Message-
From: Jeff [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 25, 2001 09:27 PM
To: Dan Sugalski
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCHES] Exception idea


Yeah, I probably should have named the register stack 'X' or something like
that. At least we're thinking along somewhat compatible lines. I'll be eager to
see your solution...

Dan Sugalski wrote:

> At 10:34 AM 10/25/2001 -0400, Jeffrey Goff wrote:
> >pope # Restore the exception stack
>
> I've been thinking about going with an exception stack rather than a set of
> exception registers, but there's something awfully compelling about an
> opcode named "pope"... :)
>
> Dan
>
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>   teddy bears get drunk





Re: [PATCHES] Exception idea

2001-10-25 Thread Jeff

Yeah, I probably should have named the register stack 'X' or something like
that. At least we're thinking along somewhat compatible lines. I'll be eager to
see your solution...

Dan Sugalski wrote:

> At 10:34 AM 10/25/2001 -0400, Jeffrey Goff wrote:
> >pope # Restore the exception stack
>
> I've been thinking about going with an exception stack rather than a set of
> exception registers, but there's something awfully compelling about an
> opcode named "pope"... :)
>
> Dan
>
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>   teddy bears get drunk




Re: [PATCHES] Exception idea

2001-10-25 Thread Dan Sugalski

At 10:34 AM 10/25/2001 -0400, Jeffrey Goff wrote:
>pope # Restore the exception stack

I've been thinking about going with an exception stack rather than a set of 
exception registers, but there's something awfully compelling about an 
opcode named "pope"... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




[PATCHES] Exception idea

2001-10-25 Thread Jeffrey Goff

[Apologies if this is a repeat, but the last message was early Wed. and
hasn't gone through yet]

The promised patches (against Wednesday morning's CVS-latest) are
attached to this message.
[You might need to reverse the first patch, against MANIFEST]

These patches add the following:

a) Exception register stack (E0-E31 for the moment, will trim down to
just E0)
b) div_i_i_ic altered to raise an exception when ic==0 (Which is to say,
sets E0 to 1)
c) New instructions set_e_i, set_i_e, push_e, pop_e
d) New test file t/op/exception.t, updated MANIFEST file

The tests exercise the new instructions and validate that div_i_i_ic
properly "raises" an exception.

The patches are a -very- crude form of exception handling. The constants
for errors like DIVIDE_BY_ZERO should probably be imported as manifest
constants, but that change would have been beyond the scope of the patch
:) Sample code that catches the divide-by-zero exception is in the
t/op/exception.t test #4, but here's a better explanation (Code uses
instructions that aren't implemented yet):

pushe# Save the current exceptions
set I2,5
div I1,I2,0  # This would ordinarily trigger a
coredump. Not now.
eq E0,DIVIDE_BY_ZERO,CATCH_EXCEPTION # Not in the current patch, but
easy to add
pope # Restore the exception stack

Rather than implementing a static set of flags in some sort of exception
register, each exception becomes an integer constant that can be tested
against. This leaves plenty of expansion room ((2**31)-1 possible
exceptions, assuming they're all negative) with the slight inconvenience
of not being able to test for a bitwise-or of exception flags. I don't
see this as being a major inconvenience, as most of the time you'll be
testing for a specific exception, at least at the assembler level.

The patch is incomplete, but then, so is the list of instructions that
can raise exceptions. This way we have a mechanism in place to handle
I/O exceptions when they're implemented (And I'm planning to work on
instructions such as open_i_s, read_i, close_i over the weekend). For
instance, an open I0," <[EMAIL PROTECTED]>

 exception.diff
 exception.t