From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/24 Message-ID: <37725122.9D7E21E0@pwfl.com>#1/1 X-Deja-AN: 493407311 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com> <7k8nn5$qcb$1@its.hooked.net> <3767E8A2.EF1A0570@itools.symantec.com> <7k8tv3$3gm@drn.newsguy.com> <7kaa6o$nr3$2@wanadoo.fr> <376906CF.109EEF55@pwfl.com> <7kbaoc$1588@news2.newsguy.com> <3769519B.9B0F880@pwfl.com> <3770F360.37A5B472@pwfl.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-06-24T00:00:00+00:00 List-Id: 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/