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,FROM_ADDR_WS, 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,fb1663c3ca80b502 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public From: "Joachim Durchholz" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/13 Message-ID: <8kkv7a$2nf6h$1@ID-9852.news.cis.dfn.de>#1/1 X-Deja-AN: 645988821 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <3963DEBF.79C40BF1@eiffel.com> <2LS85.6100$7%3.493920@news.flash.net> <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de> <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de> <_dS95.9945$7%3.666180@news.flash.net> <396DEEE8.60B3F5C7@lmco.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Trace: fu-berlin.de 963510314 2866385 195.190.10.210 (16 [9852]) X-MSMail-Priority: Normal Reply-To: "Joachim Durchholz" Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-13T00:00:00+00:00 List-Id: Howard W. LUDWIG wrote: > > The most common option is a MIL-STD-1750 16-bit architecture processor--they > run quite a bit more slowly than your Pentiums and PowerPCs (by about a factor > of 10 if I recall correctly). Indeed that fast? My last experience was with a 32 MHz 68000 IIRC. (Hardened etc. - this is *really* an issue. You simply don't get latest-generation hardened processors from Intel. You'll always get processors that are a few generations behind, because the unhardened processors are already pushing the limits of production technology.) However, DbC doesn't say that you always use run-time checking. DbC is documentation as well as run-time checks. If you need run-time checking, use a faster processor for ground testing with assertions switched on, for example. If you really need an assertion check that raises an exception, use a language that can switch checking on and off selectively. > As a sidenote, these very tight timing constraints are why hard-real-time > software developers avoid like the plague languages such as Eiffel in > which garbage collection is mandatorily done in a manner that is "transparent" > to the developer. If you have only 0.5 ms to spare in each processing cycle > and garbage collection comes along and grabs 2 ms at an uncontrollable time > to clean up memory, you've blown your timeline and crashed the rocket. Oh, another GC myth. Modern garbage collectors don't come along and uncontrollably grab time. Usually, you run GC whenever there's spare time - modern garbage collectors run in parallel (in a coroutine-style fashion) with the application. Actually automatic garbage collection is more predictable than smart pointers. Removing the last smart pointer to an object will trigger a cascade of object deletions, possibly overrunning the deadline. In a GC environmnt, removing the last pointer will turn the object into garbage that will be collected at the next opportunity when the system has room to breathe. Regards, Joachim -- This is not an official statement from my employer or from NICE. Reply-to address changed to discourage unsolicited advertisements.