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/23 Message-ID: <3770F360.37A5B472@pwfl.com>#1/1 X-Deja-AN: 492959530 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> 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-23T00:00:00+00:00 List-Id: Keith Thompson wrote: > I've always found this wording a bit odd. The way Operand Error is > capitalized implies that it's a technical term, but course there's no > predefined Ada exception by that name. Presumably they're referring > to Constraint_Error (or possibly Numeric_Error if they were using an > Ada 83 compiler). Perhaps "Operand Error" is the name of a > hardware-level error condition? > As I've said elsewhere, my recollection was that the system ended up going to an interrupt handler and, as you observe, there is no such thing in Ada (that I'm aware of) called Operand_Error. On the 1750a, there is a fixed point overflow interrupt and several user definable interrupts which may have somehow ended up tagged with this terminology. We have to remember that the guys who write these disaster analysis reports are not usually experts in the specific domain wherein the error occurs. They interview lots of technical experts and attempt to understand exactly what happened, then write up a report. Chances are, they were caught up in the terminology of whoever was doing the explaining. > Also, what does "protected from causing an Operand Error" mean? I > *think* it refers to surrounding the operation with a local exception > handler, but it's not at all clear from the report (at least to me). > Dittos. My recollection from other parts of the report was that the code was running at a very high duty cycle which caused the developers to remove the runtime checks for efficiency. This rather implies that, having turned off checks, there was nothing to examine ranges, etc, and explicitly generate an exception. (To raise the exception, there must be some code generated of the form "if (X not in -32768..32767) then...", shouldn't there?) Either that, or there has to be some sort of trapping of the interrupt which is going to get generated, right? 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. Not having the original code in question in front of us is a decided handicap... > Obviously the report wasn't written for an Ada-aware audience (not > that it necessarily should have been). > It would have been nice for me at the time this was going down if it had been a little more "Ada Aware" - Interpretation and explanation of how this wasn't going to happen with *my* rocket would have been easier! It would have been useful to have the source code - maybe. 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/