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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-27 07:08:30 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!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: simple CPUs, was Re: How Ada could have prevented the Red Code distributed denial of service attack. Date: Mon, 27 Aug 2001 09:53:01 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9mdjbu$qri$1@nh.pace.co.uk> References: <9lr3tt$4gr$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 998920382 27506 136.170.200.133 (27 Aug 2001 13:53:02 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 27 Aug 2001 13:53:02 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: archiver1.google.com comp.lang.ada:12464 Date: 2001-08-27T13:53:02+00:00 List-Id: Well, it typically isn't done to simplify timing estimates. Its done to be sure that in the absolute worst case execution of the code, the timing remains *predictable*. Rocket guys loathe things that aren't predictable because they have enough unpredictabilities to deal with without throwing timing uncertainties into the mix. If you run through a routine in its worst case path and it takes N milliseconds, you know that you aren't going to generate conditions under which that is going to vary. Hence, when you pile all of the code together and it runs worst case scenarios and you still have time left on the CPU budget, you *know* that you aren't going to generate some sort of wierd combination or permutation of execution paths that change this behavior. Throw in cache and pipelining and then you've got to test the wierd permutations to be sure you don't blow the CPU budget. That can range from somewhere between extremely difficult to impossible - depending on your scheduler. Granted, if you have a CPU wherein you're only using 30% of the timing budget under all of your tested conditions, you can probably do enough analysis to figure out that the probability of any sort of cache or pipeline combinations blowing the CPU budget is extremely low. But the metal benders that tend to control deep space projects might not understand or accept this - they like to deal with certainty. That and you seldom find yourself with the luxury of running a state of the art microprocessor in the gigahertz range - or if you did, it gets limited by the access speed of memory or some other device. And even if you had 90% spare CPU budget, you *know* that there's going to be someone who will find something to do with it eventually - or tell you that the system is overbuilt and make you use a cheaper part! :-) But your point is taken - with many modern processors you could probably eliminate the cache and pipelining and maybe do some other things to create a more predictable (yet slower) device and still be coming out ahead. (I bel ieve this was the idea behind the RH-32) The problem is that there aren't a lot of silicon foundaries willing to make you a RAD-hard, custom version of their chip (with all the required testing and certification) when the number of chips you want to buy is measured in the hundreds. 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/ wrote in message news:sGhi7.17722$sa.8914739@news1.rdc1.sfba.home.com... > >If Intel did offer some version of their 80x86 family in a deep-space, > >... > >One of the beauties of the 1750a was the indivisible nature > >of the instructions, their simplicity and predictability. For hard-realtime > I wonder how much performance loss there would be if you eliminated > all the fancy pipelining etc etc from a Pentium IV, in order to simplify > timing estimates? As much as 1/2? Continue to run at 1GHz, of course.