Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic <condicma@bogon.pwfl.com>]

Robert A Duff wrote:
> It's not clear what sort of "data conversion" they're talking about in
> the report.  Is it an Ada type_conversion, as in "Integer(Some_Float)"?
> Or is it a subroutine that's doing something similar -- that could
> explain the "Operand Error" -- maybe the subroutine raises that
> exception.

In the 1750a, there is a FIX opcode which converts the integer portion
of the derived operand to a 16 bit integer (EFIX for extended precision
to 32 bit integer). If the conversion results in a number that is too
large, the condition status register is set and a Fixed Point Overflow
interrupt is triggered. I looked for references to "Operand Error" but
my Fairchild book doesn't seem to have any. My best guess is this is
what triggered the problem.

> 
> > It is possible that they meant having a "begin exception end" block
> > around the computation, but you don't usually see people doing that.
> > There's usually an exception handler at the end which catches all the
> > errors. And since the handler in and of itself is not (usually) run-time
> > intrusive, there would be no reason to remove the handler in the
> > interest of efficiency.
> 
> Unless they were worried about space efficiency.
> 
In a space based Mil-Std-1750a microprocessor, you almost invariably run
out of time *way* before you run out of space. :-) 

> It does seem strange that they would eliminate the exception handler,
> but not eliminate the code that raises the exception, if they were that
> worried about efficiency.  Which makes me think that it must have been a
> hardware-detected exception.  But that would raise Constraint_Error, not
> some user-defined thing called "Operand_Error".  Strange.

That's why I was convinced they were dealing with something that
triggered an interrupt and that the interrupt handler was not generating
an Ada exception, but rather going through some failure accommodation
logic.

If this conversation keeps up, I'm going to have to go re-read the
report. ;-)


MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/