4 ms·

Any active projects turning FPGAs into Lisp machines? Should hopefully get more interest in this since every system we currently have is infested with backdoor

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.

auvi 13y ago
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.
- jonjacky 13y ago
  IGOR, a 2008 class project at a Norwegian university: http://opencores.org/project,igor http://opencores.org/project,igor http://www.idi.ntnu.no/news/index.php?news=163 http://www.idi.ntnu.no/news/index.php?news=163 http://www.flickr.com/photos/kaitorge/sets/72157609445719327/show/ http://www.flickr.com/photos/kaitorge/sets/72157609445719327...
rjsw 13y ago
There has been work done on an FPGA implementation of the MIT CADR by Brad Parker, he also wrote the software emulator for it.
- auvi 13y ago
  I see. He named the revised version of CADR as CADDR :) From here: http://www.unlambda.com/cadr/ http://www.unlambda.com/cadr/
daniel-cussen 13y ago
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.
- auvi 13y ago
  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.
  - daniel-cussen 13y ago
    I haven't open sourced it. The stack based language works quite nicely with Lisp; in fact, Lisp machines were traditionally stack based.
  - arethuza 13y ago
    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.
- gruseom 13y ago
  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?
  - daniel-cussen 13y ago
    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.
    - gruseom 13y ago
      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.
reginaldjcooper 13y ago
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.
rst 13y ago
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!)
- deleted 13y ago
  [deleted]
  - rjsw 13y ago
    I don't know about the internals of Symbolics ones but the MIT/LMI/TI machines didn't have any hardware assistance for bounds checking.
Tyr42 13y ago
If you are interested in the hardware side, look at Hardware-Assisted and Target-Directed Evaluation of Functional Programs, by Matthew Francis Naylor.

auvi 13y ago

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.

jonjacky 13y ago
IGOR, a 2008 class project at a Norwegian university: http://opencores.org/project,igor http://opencores.org/project,igor http://www.idi.ntnu.no/news/index.php?news=163 http://www.idi.ntnu.no/news/index.php?news=163 http://www.flickr.com/photos/kaitorge/sets/72157609445719327/show/ http://www.flickr.com/photos/kaitorge/sets/72157609445719327...

rjsw 13y ago

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

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

daniel-cussen 13y ago

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.

auvi 13y ago
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.
- daniel-cussen 13y ago
  I haven't open sourced it. The stack based language works quite nicely with Lisp; in fact, Lisp machines were traditionally stack based.
- arethuza 13y ago
  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.
gruseom 13y ago
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?
- daniel-cussen 13y ago
  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.
  - gruseom 13y ago
    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.

reginaldjcooper 13y ago

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.

rst 13y ago

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!)

deleted 13y ago
[deleted]
- rjsw 13y ago
  I don't know about the internals of Symbolics ones but the MIT/LMI/TI machines didn't have any hardware assistance for bounds checking.

Tyr42 13y ago

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