11

I happened to find out about the Rekursiv today. Rekursiv is a processor that attempted to implement OOP concepts directly at the hardware level.

Since it never got fully developed, I wonder what would the performance improvements/impact of Rekursiv have been over traditional processors if it were developed?

Improve this question
  • 2
    There's at least one member (and probably only one member) of this forum that seems to have used a Rekursiv. – another-dave Jul 6 '20 at 20:11
  • 1
    This page suggests to me that the primary feature is that store is addressed by object identifier rather than by address. I wonder it has any conceptual similarity to System/38 (apart from the coincidence that I know next to nothing about either). – another-dave Jul 6 '20 at 20:17
  • ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=295543 might help some. It would not be the first processor proposed in the 80's that did not live up to the hype (including various 'transputer' chips, custom Lisp chips, full-wafer processors that melted, etc.). – Jon Custer Jul 6 '20 at 21:16
  • Have you tried to follow the references given in the Wiki page? Some look rather promising. – Raffzahn Jul 6 '20 at 22:07
  • re: and probably only one member - it seems the rekursiv-using membership has doubled overnight. – another-dave Sep 2 '20 at 22:11
18

I'm one of the developers of the Rekursiv. Its biggest problem was its recursive nature. Basically if a page fault happened while executing a (microcode, recursive) instruction it wasn't possible to abort execution of the instruction, issue a memory fault and switch to a different thread while the fault was serviced. Instead, the entire processor halted while the host machine (Sun 3) serviced the page fault, and then the Rekursiv carried on from where it had left off.

Also, the fact that there were so many different memories made efficient use of RAM tricky, and there was no VMM on anything but the object-store (IIRC), so there was a distinct upper limit on the number of processes which could run.

If we'd been able to integrate the entire CPU on one chip I think it would have been faster than the Sun, but we couldn't and so inter-chip communication delays probably halved what could have been achieved for execution rate. That and the fact that the board had no access to I/O of its own made getting to and from disk pretty slow.

Finally, if any of us had had any actual previous experience designing high-speed digital circuits or even (gasp!) processors, we might have made it go a bit faster. But we didn't :-)

Improve this answer
  • Thanks for the comment. Exciting to hear from someone who was actually on this project. – Will Hartung Sep 2 '20 at 14:08
  • :-0 +1 Awesome! – chthon Sep 5 '20 at 16:48
12

It was never fully developed in the sense that a complete system was built, but it was made into a card that plugged into the back plane of a Sun 3 system. We had one, and our card is shown here:

enter image description here

Ours is now in the (local) Computer Museum .

Unfortunately most of the software details are lost in the fog of past memories.

However, good information is shown in the page linked in the comments, which indicates that the hardware ran slower than the implementation of the software on the Sun 3, which eventually led to the demise of the project.

Improve this answer
  • That appears was pretty much also the reason that Java support in processors did not catch on. The software JIT's were much faster than the hardware if they had lots of memory available. – Thorbjørn Ravn Andersen Jul 7 '20 at 13:02
  • 1
    Amazing. I bought Harland's book when it came out and thought Rekursive was interesting but never knew until just now that any were actually built! I think all of these special purpose processors failed in the market because of the different level of effort that went into them vs the standard architectures. By a factor of 100 if not 1000. Of course general purpose architectures would progress faster, and thus become more suitable for more programming models (among other things) than a boutique architecture for one purpose with a few adherents. Thus, what @ThorbjørnRavnAndersen says. – davidbak Jul 7 '20 at 14:42
  • @ThorbjørnRavnAndersen: A hardware platform optimized for Java-style frameworks could handle some things better than existing platforms. For example, if there were an instruction to load a reference to an object and set a bit in its header if it wasn't already set, with the proviso that the bits could only be reliably tested or cleared by specialized instructions for that purpose, and caching logic was set up to accommodate it, a GC could know whether a reference to an object had been loaded since the last time the GC had scanned for reachable objects, but without adding synchronization... – supercat Jul 7 '20 at 17:27
  • ...overhead. If a reference is loaded for reading or writing in a thread which hasn't performed such an access recently, the core could write a cache entry that would force the read/written bits in the header to be set, without having to know or care whether other cores had done so. It would be necessary for cache lines to include bits to distinguish object flag bytes from other data, but a system could support nearly-pauseless garbage collection with less synchronization overhead than would be needed on existing hardware. – supercat Jul 7 '20 at 17:34
  • @supercat yes. Has this ever been implemented? – Thorbjørn Ravn Andersen Jul 7 '20 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.