Re: Efficiency of code generated by Ada compilers

[Brian Drummond <brian_drummond@btconnect.com>]

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

>Le Sat, 14 Aug 2010 12:47:27 +0200, Brian Drummond  
><brian_drummond@btconnect.com> a �crit:
>> In a single cycle, one small corner of the Rekursiv would perform both  
>> range
>> checks and type checks,
>
>Range check... and type check. Just real vs integer or was their some kind  
>of typing in integers as well ? Also may be character, BCD and the like ?

Integer was an object like anything else - you could ask 2 its class, size etc.

The equivalent of fetching a word from memory was "paging" an object, by its
object number, which would simultaneously fetch its type, size in words, address
in memory (if it had one), and the first word of its representation - usually
from a (155-bit wide) cache.

Integers and other simple types encoded the (32-bit) value in the (40-bit)
object number so didn't have a separate body in memory - the paging operation
unpacked all the above data as though it had come from cache, so even microcode
didn't see them as any different. Being an astronomer, David Harland named these
"compact objects"!

You could certainly subclass integers and impose other semantics - subranges,
units, currency exchange rates - on them if desired, but without explicit
microcode support, the subclasses would be memory-based objects and thus slower.

Explicit microcode support was not so far fetched, either - it had a writable
microcode store - though if there were ever a secure Rekursiv, I am convinced
the microcode would have to be in ROM. 

It had a novel approach in many ways - the microcode could be arbitrarily
complex, (recursive; hence the name) so garbage collection could be a single
instruction, or even none - running in the background. In theory you could turn
the nodes of a syntax tree into an instruction set, and execute parse trees
directly.

Page faults didn't interfere with complex instructions - instead of aborting
them, they were suspended on stacks, and resumed after handling the fault. 
(To be fair, the Rekursiv didn't do all that itself; to keep the project size
down, a separate "disk processor" handled the faults. Potentially an embedded
processor, but a Sun-3 workstation in the prototypes) 

>> The entire  Rekursiv was
>> about 70k gates + memory, next to a contemporary RISC of around 20-30k.
>
>70 000 gates, that's light.

Not so light in 1987...

- Brian