Re: OOC Core Library

[Mike Griebling <grieblm@trt.allied.com>]

> Michael G. wrote:
>    > I do like the error handling.  Nice touch.
> 
>    Thanks.  In all cases, the functions will continue operating by returning
>    a default value like infinity, zero, or other logical result and set the
>    appropriate error condition.  It will be up the caller to check (or ignore)
>    the error state.
> 
> Mh, I think the correct way to handle errors is to raise an exception.
> Having to check an error code defeats the purpose of increasing the
> execution speed, doesn't it?  And it makes modules that doesn't
> explicitly check the error code (ie, almost all modules), somewhat
> unrealiable. 

Do we have an exception-raising paradigm that we are using with this
compiler?  Hopefully, something that would be independent of the final
target OS.  

There are also some instances when an exception is not warranted. (e.g.,
when an underflow occurs, it usually makes sense to continue execution).

Error codes only need to be checked during development testing.  After
a final version of software exists, the checks could be removed.  This
was the approach we used in the embedded software for the Boeing 777
cabin pressure and pack temperature controller.  Exceptions seem to
be frowned on in the real-time embedded world because you have to
recover from all errors into a mode which will let you continue 
operation.  Alan Freed from NASA would probably agree since his math
package prints error messages and then continues execution as well.
 
>    Both zero and infinity are approximations.  These approximations were
>    stolen from some Math modules posted by Alan D. Freed from NASA.  Basically
>    infinity=MAX(REAL)/100 and zero=1/infinity.  This implementation thus
>    avoids hardware overflow/underflow traps.  To implement a check against
>    zero, this module does the following:
> 
>        IF ABS(x)<zero THEN (* the number is effectively zero *) END
> 
> Both the `epsilon' and `infinity' are exact values in the IEEE
> standard.  IMHO you should either define them precisely by setting
> them to the appropiate bit patterns, or you give those variables a 
> different name.  

The epsilon is supposed to have the same meaning as the IEEE standard. I
will replace its definition with the standard.  The infinity is probably
best renamed.  I believe that zero is an exact value(s) in IEEE as well
so I suppose it should be renamed as well.
 
>    > [something about inlining deleted]
> 
>    BTW, does this mean we wouldn't be supporting CODE procedures as
>    used by ETH and shown (1st recommendation) in the Oakwood report.  It
>    may be useful to use code procedures when interfacing to other languages
>    and the OS. 
> 
> The implementation of CODE procedures is up to the back-end.  A assume
> that by CODE you mean a string of bytes defining the procedure body in
> terms of the target's machine code.  But the reference to CODE in the
> context of procedure inlining is somewhat misplaced.  It is not
> possible to inline such CODE procedures, procedure inlining is
> exclusively  done on the GSA level, _not_ on the assembler level.
> Calls to a CODE procedure are always coded as explicit calls and
> cannot be removed.

OK, that clears that up.  My main concern was not about inlining CODE
procedures but just about whether they would be supported.  Your answer
seems to say yes as long as the back end supports them.  I think code
procedures are trivial to implement in a general way so they could even
be placed in a shared back-end module.
 
>    All routines will be as accurate as possible in the given floating point
>    mantissa.  The routines should be comparable to the SUN math routines'
>    accuracy and similar to a FPU.  The only difference will be in how the
>    overflow/underflow are handled by the software routines so that execution 
>    continues instead of trapping.
> 
> As I said before, I'd prefer exceptions above error codes.

Just tell me how to raise an exception and it can be done.
 
> Michael van Acken

Michael Griebling