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=AC_FROM_MANY_DOTS,BAYES_00, XPRIO_SHORT_SUBJ autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78b2880bc7e78e39 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-21 09:49:22 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!falcon.america.net!sunqbc.risq.qc.ca!newsfeeds.belnet.be!news.belnet.be!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: RISC Date: Wed, 21 Mar 2001 12:36:04 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <99aoqk$jsm$1@nh.pace.co.uk> References: <98qumf$5sf$1@nh.pace.co.uk><98r4g1$7r1$1@nh.pace.co.uk><3ab1d090$1@pull.gecm.com><98t8la$rc$1@nh.pace.co.uk><3ab72c8f$1@pull.gecm.com><997pq4$i35$1@nh.pace.co.uk><3ab79ade$1@pull.gecm.com><998ctp$ond$1@nh.pace.co.uk> <998o2h$sa2$1@nh.pace.co.uk> <99ae0k$g0j$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 985196180 20374 136.170.200.133 (21 Mar 2001 17:36:20 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 21 Mar 2001 17:36:20 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:5971 Date: 2001-03-21T17:36:20+00:00 List-Id: Back when I was doing engine controls, we'd get started talking about how the DEC compilers could generate different code depending on available memory & what else was running, etc. Our Configuration Management person would plug her ears and go "I can't hear you YAYAYAYAYAYAYAYA!!!!!!" :-) It was a real worry for Formal CM that we couldn't absolutely GUARANTEE that given the same source code, the same compiler, the same machine and two different days of the week, that we couldn't get the same set of bits out the back end. However, I'd consider your statement about "not *ever*" to be a bit strong. Remember that we were originally talking about doing an overlay by forcing two things to reside at the same spot in memory. If I could get my compiler to do this at all reliably for one structure, it would be a reasonably safe assumption that on two different days of the week, that same structure is going to reside at that same location in memory. (Otherwise, how do I deal with memory mapped devices?) It also seems reasonable that if I got one "for use at" to put something in memory at a specific location and another "for use at" to put a different thing at the same location, and I don't switch compilers, that on a different day of the week, I'll still have those two things residing at the same spot in memory. (This sort of thing is done all the time at low levels of code - getting access to the same physical memory locations from two different perspectives/locations in the code.) Granted, if I pull some sort of trick with access types and start counting on an optimization to fool the compiler into dealing with an overlay, I may have different problems. But I'm talking about a plain vanilla overlay. At some point you have to have *some* level of trust (based on conversations with your vendor, knowledge of the compiler, evidence in the documentation, etc.) that even "erroneous" things will work properly within some known parameters. Otherwise we're down to discussing what might happen to the code if the sun expands to 10 times its current size and the Earth is totally engulfed in fire. (I guess the program crashes and your rocket/payload augers in - tough noogies! :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" wrote in message news:lW4u6.325$fy.827@www.newsranger.com... > In article <99ae0k$g0j$1@nh.pace.co.uk>, Marin David Condic says... > > > >Very true. This is why lots of mission critical systems *freeze* a version > >of the compiler at some juncture in the project. Better the bugs you know > >than to have something totally unexpected show up in a new release. > > But that isn't even sufficient to keep you safe from erronious code. Assuming > that the generated code might be affected by how the compiler decides to > optimize (a quite reasonable assumption), then your code could cease to work if > any of the following happen: > > o You recompile with a different set of options. > o You change a line of code somewhere in the entire system and recompile. > > and in some cases (notably the old DEC Ada compiler)... > o You compile on a different machine. > o You compile on the same machine, but with a different amount of free RAM > (different set of background processes running at the time). > > You really should not *ever* use erronious code unless you have some kind of > good assurance from your vendor that it will behave predictably (often the > vendor docs will mention some such instances). I suppose having access to the > sources of your compiler and checking it over yourself might count, but that > would probably be more work than finding a better way. > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com