Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!purdue!decwrl!hplabs!hpda!hpcupt1!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.unix.wizards
Subject: Re: Re: Universal OS (was Re: Survey of architectures)
Message-ID: <670016@hpclscu.HP.COM>
Date: 26 Apr 88 17:33:31 GMT
References: <50825@sun.uucp>
Organization: HP NSG/ISD Computer Language Lab
Lines: 42

> In other words, if you want to write portable code, write it so that signal
> handlers take one argument.  This will work on any non-broken UNIX system.

I presume that by broken UNIX systems, you mean "most" UNIX system. What am I
going to do with that ubiquitous "SIGFPE"? That could mean the most amazing 
number of vastly different things on most systems. This becomes an especial
problem if you have funky architectures that catch you on many funnies in many
languages. As an example, take range-checking in Pascal (shudder! :-)). We'd
like to avoid the overhead of generating 4 or 5 instructions to check a value
and call a routine if anything goes wrong. Instead, we'd like to just use
a "compare and trap" instruction. *Of course*, the trap raised by this
instruction *just happens* to be the same one that's raised by an Integer
Overflow or a divide by zero (even the subcode). We thus have to do some
pretty fancy decoding of the instruction which trapped to figure out what
happened. That could have been done by the UX signal mechanism instead, saving
us a lot of grief...

Since machines have come a *long* way since the xxx-7, maybe it's time to
define a consistent and meaningful convention (standard?) for such signals.
For instance, SIGFPE (which now has an underground subcode which may mean
just about anything, depending on what system you are on..) could either have
an ARCHITECTED subcode, or be changed to a whole new array of codes, for
different things like Integer Overflow, Divide by zero, Floating-point
underflow and so on... 

After all, no matter how you bury your head in the sand, C is not the only
language out there. There's FORTRAN, Ada (soon coming to a computer near
YOU..), Pascal (that name again..), COBOL (no comments..) and so on. The
runtime semantics of such languages almost always force emission of UGLY
runtime code to do thins which can easily be caught by the hardware, but for
which U**X refuses to return a meaningful code.

Naturally, this will have to be defined to allow machines which do not have
a meaningful trap in a particular category to return a more generic code.

> Thus, the issue of the interface to the signal handler is not an issue raised
> by multiple versions of UNIX.  It *is* an issue if you have non-UNIX systems,
> but if you have to deal with non-UNIX systems, it's probably one of the least
> of the issues you will have to deal with.

This is not particularly a UNIX problem, it's an architecture problem.

Shankar.