Re: is there a version of unix written in Ada

[Brian Drummond <brian@shapes.demon.co.uk>]

On Fri, 09 Oct 2020 05:35:22 -0700, Olivier Henley wrote:

> On Thursday, October 1, 2020 at 5:36:40 PM UTC-4, Brian Drummond wrote:
>> Maybe I should knock together a new Linn Rekursiv on an FPGA.
> 
> Just finished 'LINN REKURSIV: A PERSISTENT OBJECT COMPUTER' by Dick
> Pountain and indeed this is utterly interesting.
> By looking at what is available in the wild about it, it is quite clear
> you are one of a few with the appropriate 'overall skillset' to bring
> that back to life.
> If you do so, please publish the work somewhere lasting...

I remember that (Byte, I think) as being one of the better articles.

In many ways we only scratched the surface of what it could do. 

The fact that we could save and restore state in microcode meant that if 
an instruction that allocated, failed, we could suspend it, do some 
garbage collection, or even page something out, and resume the same 
instruction.

(That of course ties the CPU up for some time! Would have become a 
serious objection if the project had got much further, but now with 
hyperthreading, you'd switch to executing another process while waiting 
for the page operation).

------------

One thing I never really got a chance to try, was departing from the idea 
of linear instruction streams. This thing could have implemented tree-
like instructions : imagine an IfThenElse instruction that called a 
boolean expression (suspending itself), then resumed and jumped to either 
arm according to the result.

So you could potentially just execute a parse tree directly. That would 
IMO have been interesting for interpreted languages along the lines of 
Python; simplifying and (in those days it mattered) accelerating 
compilation..

------------

But even Lingo was compiled to 11 mostly straightforward sequential 
instructions (with one exception) (later, others were added as 
optimisations), the exception being "Send".

Send encoded a "message send" : applying a selector to any object, 
discovering which method was bound between that selector and the type of 
that object, and executing that method.

Method discovery traversed the type hierarchy from the object's type, 
looking up the selector in the method dictionary for that type (aka vtable 
for C++) - if not there, recursively using the parent type, until the 
parent of all objects, i.e. Object. (Where failure raised "Unknown 
Selector exception).

Sounds slow, but in parallel with all that, hashing the selector and type 
and lookup the method in a hashed array, took 4 cycles, so that was the 
practical penalty for dynamic binding.

------------

I added optimisation in the form of targeted Send instructions, like 
"Send +" for common selectors like "+". (Selectors could be operators, or 
subprogram names). 

On the face of it, this simplified "Push +; Send" into one instruction.
In practice, it performed integer addition in parallel with setting up 
the Send instruction, so that if both argument types matched Integer, all 
it had to do was push the result and exit. Otherwise, branch into Send.

Fun times...

Maybe I'll put it on the list of retirement projects...

-- Brian