[LispM-Hackers] Error handling

James A. Crippen james@UnLambda.COM
Tue, 10 Apr 2001 09:56:31 -0800 (AKDT)


On Mon, 9 Apr 2001, John Morrison wrote:

> When I was building "raw," completely and totally self-contained binary
> executables for running on bare iron, I got all sorts of unresolved
> external references to libc (until I told the compiler to disable
> exception handling.  They seemed to involve exception stack maintenance
> and stack cleanup -- I seem to recall the compiler emitting calls to
> libc to set up try/catch blocks.  However, it's been a couple of years,
> and I didn't really try to chase it down very far.  I just blew it off
> entirely and lived quite happily without it.  I do not remember even
> figuring out whether it was popping frames off a single stack or whether
> it was walking a separate exception stack.

I have complete confidence that we can work around this situation when we
encounter it.  Since the bare iron port is not a high priority at this
time I'd like to have something that works, and works well, and most of
all makes SENSE, right now.  Like I said, we can wrap this exception
behavior later on and provide an alternative mechanism for ports that need
it.

> In general, I just try and adhere to the KISS principle.  If I knew
> exactly what the benefits were (I have tried to explain the complexity
> costs in the bare iron case -- although I confess I do not have a good
> handle on the cost of setting up try and catch blocks in terms of clock
> cycles) then I would feel more comfortable with making a decision.

The benefit is in programmer time.  It's much easier to write code using
exceptions than it is to write code using some ad hoc mechanism that may
or may not be what you want and may require rewriting to fit your
situation.

I know that some compilers have problems with exceptions.  But there's one
compiler that's totally free and not very difficult to install (takes
about a half-hour to install, minus compile time), and that's GCC.  And
GCC is known to support all of C++ (except for the template library,
which is of course Evil, as are templates in general).

If HP-UGH's C++ compiler doesn't like exceptions then screw it.  Use a
compiler that works instead of a broken piece of shite.

And for the bare iron port I see us ending up having to get libc support
anyway for a lot of the interface cruft that we're making for the
operating system.  You haven't even run into emulating any of the devices
yet, and things like ethernet will be *very* entertaining, and highly
dependent on high-level OS services.  There'll be a lot of glue to get the
bare iron port working, and I expect some heavy reliance on available
code, like glibc.

I don't want to argue about this right now.  Trust me.  I'll throw
together what I've got for the error system.  I'll outline it in the next
message.  Tell me what you think.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.