A "functional" processor architecture

Whatever is on your mind, whether Lisp related or not.
Post Reply
schoppenhauer
Posts: 99
Joined: Sat Jul 26, 2008 2:30 pm
Location: Germany
Contact:

A "functional" processor architecture

Post by schoppenhauer » Thu Feb 16, 2012 5:48 pm

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.
Sorry for my bad english.
Visit my blog http://blog.uxul.de/

nuntius
Posts: 538
Joined: Sat Aug 09, 2008 10:44 am
Location: Newton, MA

Re: A "functional" processor architecture

Post by nuntius » Fri Feb 17, 2012 6:58 pm

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.

Post Reply