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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2a34b7ad6c6a0774 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 14 Aug 2010 05:40:00 -0500 From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: Efficiency of code generated by Ada compilers Date: Sat, 14 Aug 2010 11:47:27 +0100 Reply-To: brian@shapes.demon.co.uk Message-ID: References: X-Newsreader: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-GX3b5zIFGGawRVuydlZxNI4chk5fJj/QHQx4K7fxXnKWuO6LVZFL043N+eLbaAVgPnPck6U5sJlrDm+!vOecgRUJXLVJPJLWsdvXpKzoyIuwyO75qCMZN5AbxowMxFs5VvaUxBjkHu9kraJWwHsizIgdmG1C!8fs= X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: g2news1.google.com comp.lang.ada:13272 Date: 2010-08-14T11:47:27+01:00 List-Id: On Sat, 14 Aug 2010 02:02:35 +0200, Yannick Duch�ne (Hibou57) wrote: >Le Sat, 14 Aug 2010 01:29:56 +0200, a �crit: >> The Burroughs machines were like that. The descriptor pointing to >> an array included the size as well as the base address, so index in-range >> was automatically checked by the hardware. >So these old machines were in some way safer than ones of nowadays > >A similar thing exist with Intel CPUs : memory segment are defined using a >base and a limit. This may be feasible to assign a memory segment to each >array and then get the same check done (an hardware exception would be >raised if ever an attempt to access a byte beyond the limit was maid), >while this would come with a cost, at least the one to have to switch >memory segment register all the time (this is more costly than reading and >writing any other register). I believe that was the serious intent behind the segments on the 80286, but I don't know of any software that took full advantage of it (the 8086 segments were just a hack to address a whole megabyte!). Possibly OS/2 did, at the process level, but nothing at the object level within application software. (The segments also offered privilege levels, so your app couldn't corrupt a kernel segment). But you're right, there were an extra few cycles penalty incurred in using 80286 "protected" mode, and at the time, that mattered to users. I expect that penalty would be completely hidden by a cache line load nowadays, if the facility had been used heavily enough to justify improving it, instead of regarding it as an expensive aberration and letting it quietly atrophy. >I found a nice page about Burroughs machines and others: >http://www.cs.virginia.edu/brochure/museum.html Allegedly the Intel 432 chips pictured there were intended specifically to target Ada, and the 286 inherited its segments from them(possibly with B5000 influence) as the 432 feature most worth saving, with the smallest implementation penalty. I once had my hands on a set of 432 datasheets - its slowness appears to have largely been the result of pushing a huge microcode word across a 16-bit bus, to save pins on the very expensive custom packages (before PGA packages). I was involved with the Linn Rekursiv processor (which I'm sure at least two other group regulars remember) which used 299-pin packages (2 of them plus a 223-pin) for enough connectivity to overcome most of the 432's problems. There were some similarities between the two processors otherwise. In a single cycle, one small corner of the Rekursiv would perform both range checks and type checks, in parallel with whatever the ALU was doing on the real data. At the time it was billed as the most complex processor in existence, but if you look at the complexity of the hardware needed to support safety and security without additional execution time, it is pretty much invisible next to a superscalar scheduler, branch prediction, or L1 cache. The entire Rekursiv was about 70k gates + memory, next to a contemporary RISC of around 20-30k. There was much talk then of "bridging the semantic gap" between high level languages and the low level operations in hardware. It seems we have subsequently bridged the semantic gap, by leaning to program in C... - Brian