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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,54889de51045a215 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-23 15:17:50 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn14feed!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s54.POSTED!not-for-mail Message-ID: <3F985338.5080702@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Early Ada Mistakes References: <1066224357.499523@master.nyc.kbcfp.com> <1066231159.711433@master.nyc.kbcfp.com> <1066311805.222491@master.nyc.kbcfp.com> <3F8F3077.60402@comcast.net> <3F900F35.50203@comcast.net> <3F952A59.5090001@noplace.com> <3F96788C.5020309@noplace.com> <3F96E2C6.6010708@comcast.net> <3F975D3C.7050804@noplace.com> <1066919806.19766@master.nyc.kbcfp.com> <38adnd5Sk8hwuwWiRVn-tg@gbronline.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s54 1066947469 24.34.139.183 (Thu, 23 Oct 2003 22:17:49 GMT) NNTP-Posting-Date: Thu, 23 Oct 2003 22:17:49 GMT Organization: Comcast Online Date: Thu, 23 Oct 2003 22:17:49 GMT Xref: archiver1.google.com comp.lang.ada:1553 Date: 2003-10-23T22:17:49+00:00 List-Id: Wes Groleau wrote: >> Also, let's not forget the Intel 432 processor, which was supposed >> to be "Ada on a chip" and which ran like a pig. (Are pigs slow? >> The 432 was slow. .) The problem with the original 432 had nothing to do with Ada, but everything to do with the capability model. When the OS designers found out that the only way to extend the top-level capability node was to do a hardware reset and in effect reboot with a different top-level node, they wanted another hardware turn before the chip started shipping. The executive decision was that the chip was late enough already. As far as I am concerned, this is what killed the chip family. It is hard to understand if you don't know all the gory details. But the net effect was that the top-level node ended up as basically a placeholder, with the "real" top-level node one level down in any general-purpose OS. This meant that EVERY memory reference went through an extra level of indirection. Ouch! Later versions of the chip could cache some capability nodes which significantly improved performance. And there was a company in the UK, High Integrity Systems that figured out that you could use the chip in embedded applications where you migrated all the important capabilities into the root node at compile time. But it was too late to save the architecture. -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig