Page 1 of 1

A "functional" processor architecture

Posted: Thu Feb 16, 2012 5:48 pm
by schoppenhauer
Recently, I had a (trivial) idea:

If I got that right, in protected mode, an x86_64 processor needs four (!!!) dereferencings for every memory reference the code makes. With one more, more RAM would be needed for the tables, but it would also be possible to have pagesize=wordsize. This would be especially interesting in the scope of lazy evaluation, when you could use pagefaults as a mechanism for triggering calculations. And one could implement fine-grained deduplication and copy-on-write for the heap space of usermode processes.

This would be pretty optimal for functional programs, and would only add one more level of dereferencing.

Just for my personal interest, would such an extension to x86 (or some other architecture) be reasonable? What would be the disadvantages? I am interested in any kind of qualified (or semi-qualified) comment.

Re: A "functional" processor architecture

Posted: Fri Feb 17, 2012 6:58 pm
by nuntius
AIUI, too many pages would cause a slowdown at the hardware level (loading page tables in and out, or requiring deeper=slower lookups).
This article describes the TLB, a common page table cache, and some page table implementations.
http://en.wikipedia.org/wiki/Page_table

That said, coarser tables can still be used to good effect. For example, the linux kernel dynamically allocates the resources for the fast userspace mutex (futex); it associates the futex address with the memory page, and uses that to find or create a linked list of processes waiting on that futex. There are also copy-on-write techniques, and parallel garbage collectors (GC) often lock pages.

That said, most of what I know on this is second hand at this time (i.e. not from direct experience, and from playing with other technologies).

Back to your original idea, I think it should be doable without changing existing memory mappings (though some GC coordination may be required).
Unfortunately, you should probably start experimenting in C/C++ (since kernel APIs are generally C, and C has no GC).
But these C tests would be small, and only a small library may be needed before returning to lisp.