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 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-28 06:58:23 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: Tue, 28 Aug 2001 09:38:06 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9mg6rv$rao$1@nh.pace.co.uk> References: <9mdjbu$qri$1@nh.pace.co.uk> <4Awi7.19571$sa.10111360@news1.rdc1.sfba.home.com> <9me5uq$3v3$1@nh.pace.co.uk> <3B8AD8DE.5C309B0A@lmco.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 999005887 27992 136.170.200.133 (28 Aug 2001 13:38:07 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 28 Aug 2001 13:38:07 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:12514 Date: 2001-08-28T13:38:07+00:00 List-Id: Don't besmirch my beloved 1750! :-) Sure, it was an instruction set with an eye towards having various hardware manufacturers build different chips capable of executing it. To some extent it succeeded. It wasn't a bad thing. Given the military & aerospace industry's needs the 1750 did a good job of satisfying them. It wasn't all that different from many contemporary 16 bit micros of its time. As for code reuse, I don't think anybody had any illusions about "porting" 1750a code all over the place. (other than possibly creating multiple sources for plug-compatible processors, like, say the 80x86 that Intel licenses elsewhere?) The basic idea was that if you built tools (compilers, debuggers, simulators, etc.) that these tools could move from one project to another and the investment wasn't wasted. This also happened. The Mil-Std-1750a was an excellent processor for its time and it certainly has a place in the world today. (Not every app needs a 32bit or bigger chip!) The problem with it was that by the time anything started to be settled out about the standard, the computer world had basically moved on to bigger and better things. Such is life in the world of standards. By the time you get agreement from a pool of people, some rugged individualist has pushed the technology beyond your standard. 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/ "William Dale" wrote in message news:3B8AD8DE.5C309B0A@lmco.com... > > This is what Mil-Std-1750A/B tried to do. Today people think the 1750 > is a CPU > but if you read the standard it is a defined instruction set to promote > re-use of > code. Of course that never happened ;-) They made a hardware CPU based > on the > assembly code instructions. And nobody reuses 1750 code! > > Bloody awful CPU at that! Still used on avionics systems like F-22! > > William Dale > mailto:william.dale.jr+ada_news@lmco.com