Hacker News Reader

Comment by dobbsbob | Hacker News Reader

Any active projects turning FPGAs into Lisp machines? Should hopefully get more interest in this since every system we currently have is infested with backdoors and closed source firmware. Would be nice, as Stallman put it to press halt, be able to change source and resume without having to re-compile.

View on HN

I've worked on a GA144 into a 24-core (24 cores of 6 F18 cores working together) Lisp Machine, with some success. I was able to define a tiny Lisp in under 16 bytewords of F18 code, with the rest of Lisp being á la carte, and distributed across those six cores.

Because the core design is modular and all the cores are the same the GA144 is much harder to backdoor and it's easier to detect if it is.

this sounds very interesting, is it open source? I am wondering how you made a processor made specifically for a stack based language (ColorFORTH) for Lisp work.

I don't know about Forth - but I one worked on a project where I was writing code in Lisp and PostScript and there is a definite "lispness" about RPN languages like PostScript and possibly Forth. This might make the mapping from Lisp to Forth easier that you might think.

I haven't open sourced it.

The stack based language works quite nicely with Lisp; in fact, Lisp machines were traditionally stack based.

Holy cow, that is very cool. I have a question about the GA144. How do you get the code to the cores? Once it's there, does it change at all?

You send the code to the cores with a bootstream from your SPI or Async port. It's a bucket brigade for code.

Once it's there, yes you could change it, but in practice changing all of it, all the time, is hard, and that's one of the challenges with this hardware. It was originally developed for embedded, a use case that needs so little code that it doesn't need to change afterwards, but I want it to be fully general, and moving it in and out without paying forbidding time penalties is a bit hard.

Interesting. That makes me wonder what architectures are (or used to be) out there that do support rapidly reconfiguring the cores. Obviously, if deploying the code is so time-intensive that you'd lose the benefits of the parallelism for dynamic use cases, there's no point. It's a little reminiscent of the situation with GPGPU where the overhead of marshalling all the data can eat away your computational speedup.

The program I'm working on (a kind of JIT compiler) is inching ever more towards a strict dataflow model in which the computations are divided into blocks and each block knows exactly which downstream blocks to send its outputs to. The ultimate output of the computation is simply the last downstream block that collects whatever outputs were originally requested and pushes them back to the client. Seems like a sweet spot for an array-based architecture. However, it would need to rapidly reconfigure the cores. Each time a block finishes its work, its core would go back into the available pool and (hopefully soon afterward) be reprogrammed with the code for some other block as the compiler produces it. The scheduler would also try to position blocks near their downstream neighbors. All of this would have to be dynamic. So, a poor fit for the GA144 given what you're saying.

If the above makes sense, I'd be curious to hear what alternatives come to mind.

Running this code on such an architecture is not currently a priority, but it does excite my curiosity—it seems so obviously doable in principle.

Well, so it's hard to do in part because you need code to load code, and there's only 64 words of RAM. But if you got the code to the core, let's say you're only changing 32 words of code, about five-ten functions, you'd have to use 32* ~10 ns = 320 ns to do the reload. Not too shabby, but you have to get it there, and that means using other cores. It's hard, but in theory there is no outstanding reason it would be a problem. Is the GA144 a poor fit? Barring that you crack the problem of getting the code there, yes, it's a poor fit.

I'd forgotten that there's so little RAM to work with. It might be doable; the blocks I'm talking about are mostly very primitive operations.

Do you think the benefits are valuable enough to be worth all the trouble of figuring out how to program this architecture, or is it more just a fun puzzle?

Unfortunately, Lisp Machine software was not particularly secure. Everything ran in the same address space, with no protection; ordinary user code could, for instance, just call a low-level disk driver. And the code running in this environment was written in pre-Morris-worm days, when no one had ever heard of a remote code execution vulnerability. (I remember some people needed to be convinced that running an "eval server" --- a server that would execute code that came over the network from unauthenticated sources --- was a REALLY BAD IDEA. In this environment!)

I know of two such projects:

  0. LISP CPU: http://www.frank-buss.de/lispcpu/

  1. LispmFPGA: http://www.aviduratas.de/lisp/lispmfpga/

Maybe there are others.

IGOR, a 2008 class project at a Norwegian university:

http://opencores.org/project,igor

http://www.idi.ntnu.no/news/index.php?news=163

http://www.flickr.com/photos/kaitorge/sets/72157609445719327...

Stanislav at loper-os.org is one of my absolute favorites, because he is an absolutist. I know he wrote previously about remaking a proper computer on an FPGA, but I don't know how he's progressing.

There has been work done on an FPGA implementation of the MIT CADR by Brad Parker, he also wrote the software emulator for it.

I see. He named the revised version of CADR as CADDR :) From here: http://www.unlambda.com/cadr/

If you are interested in the hardware side, look at Hardware-Assisted and Target-Directed Evaluation of Functional Programs, by Matthew Francis Naylor.

Reply on news.ycombinator.com