Re: Efficiency of code generated by Ada compilers

[Brian Drummond <brian_drummond@btconnect.com>]

On Sat, 14 Aug 2010 02:02:35 +0200, Yannick Duch�ne (Hibou57)
<yannick_duchene@yahoo.fr> wrote:

>Le Sat, 14 Aug 2010 01:29:56 +0200, <tmoran@acm.org> 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