
Lisp CPU - auvi
http://www.frank-buss.de/lispcpu/
======
TD-Linux
This would be interesting, but it looks like it has been barely started - the
CPU is barely what I would call a CPU, let alone a Lisp interpreter.

Verilog isn't a programming language (it tries to be, unfortunately). For
synthesis, it is a hardware description language. Someday I'll write up some
decent Verilog tutorials because there aren't any good ones on the Internet.

~~~
jff
My thoughts exactly. When I saw "Perhaps the Verilog language is not so good,
because some nice standard language featuers (forever-loop etc.) are missing
in the Xilinx-Tools.", I had flashbacks to VHDL class, students writing loops
and then wondering why they couldn't synthesize the code. You have to get
yourself into a hardware mindset, thinking about clocks and state machines and
enable lines rather than infinite loops.

~~~
AceJohnny2
Yeah, it looks like this guy needs to learn more Verilog before he can make
progress on the CPU implementation.

It reminds of teaching some VHDL in a hackerspace a few years ago (I had
learned it in college some years previously), and this software guy was
constantly trying to write functions and loops, and was having trouble with
the concept that all signals were propagated concurrently rather than
sequentially!

Sure, it _looks_ like code (in fact, VHDL's syntax is purposefully similar to
ADA), but it sure _isn 't_ code.

~~~
spacemanmatt
Would it be fair to describe it as concurrently executed code?

~~~
AceJohnny2
hah, that's only the tip of the iceberg...

From memory:

\- HDL code doesn't have variables the way programming code does. Sure, you
can store state in latches (and other more roundabout ways), but a good design
tries to avoid this.

\- You can have "functions" that take parameters, but what you're really doing
is instantiating blocks of hardware according to said parameters.

\- Instead of variables to functions, what you really care about is signals as
input and output to hardware blocks. (and ultimately at the final hardware
implementation, propagation time and power of said signals. Especially the
clock. OMG the clock...)

Honestly, I found VHDL made complete sense from approaching it after drawing
digital circuit diagrams, as the description code mapped pretty clearly to
that. Approaching it from an "imperative programming" background makes little
sense, and saying it's "concurrent programming" just ends up confusing the
issue more, IMHO.

~~~
ioseph
Absolutely agree with learning digital circuit design first. Before writing a
single line of HDL, you should know exactly what you want to be synthesized.

Unfortunately all to many courses approach like learning a new programming
language. To me this is like teaching CAD before teaching how to draw a
rectangle.

------
mhewett
You need to look at The Architecture of Symbolic Machines by Peter Kogge. It
contains a machine you can implement. I have implemented it in the Jatha LISP
interpreter (
[http://sourceforge.net/projects/jatha/](http://sourceforge.net/projects/jatha/)
).

------
jff
I'd like to point out that the code he has on there isn't a Lisp CPU and I
don't think will even work in a real FPGA. I don't know Verilog, just VHDL,
but that business in the INIT state looks sketchy to say the least. Even if it
does work, it just loads a few instructions into memory & executes them; these
instructions blink an LED on the board. The Lisp architecture is barely
described beyond a few sparse notes about a tagged memory arch (not
implemented).

I'm not attacking the original author; these look like personal notes as he
explores an FPGA and realizes that hardware design is complicated. But don't
get your hopes up on this being... well, anything.

~~~
simias
yeah it's definitely not synthesizable in its current state, not to mention
that he's going to have a bad time if he messes with the clock the way he does
in this code (the way he generates his slowClock, unless his tools are clever
enough to recognize this pattern and do the right thing).

It's a cool project though, but if I were him I'd learn the language with some
simpler and smaller designs, maybe some stuff he'll be able to re-use in his
final CPU.

As it is it reads a bit like someone who wants to write a kernel in C while
not understanding how pointers work.

------
ChuckMcM
This was started back in 2004 and the last update was in 2007 apparently [1],
not a lot of the content changed. Building CPUs in FPGAs is fun, a lot of the
demo boards available these days already have memory and often either an SD
card type interface or some sort of NAND flash attached. A good place to start
if your interested is fpgacpu.org ( not exactly a 'live' site but there is
good info in there ) or opencores.org.

[1] [http://web.archive.org/web/*/http://www.frank-
buss.de/lispcp...](http://web.archive.org/web/*/http://www.frank-
buss.de/lispcpu/)

------
jonjacky
These more recent projects also made Lisp machines in FPGAs. It looks like
they got further than the original post here:

LispmFPGA (2008)
[http://www.aviduratas.de/lisp/lispmfpga/](http://www.aviduratas.de/lisp/lispmfpga/)

[https://groups.google.com/forum/?fromgroups=#!topic/comp.lan...](https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.lisp/36_qKNErHAg)

IGOR (2008)
[http://opencores.org/project,igor](http://opencores.org/project,igor)

[https://www.flickr.com/photos/kaitorge/sets/7215760944571932...](https://www.flickr.com/photos/kaitorge/sets/72157609445719327/)

------
wes-exp
I'd like to see a modern CPU that handles dynamic typing in hardware.
Registers can store values as well as the type, e.g. 32 value bits and a few
type bits. Basic arithmetic like addition can automatically compare the type
bits and just do the right thing with a single instruction (fixnum add, float
add, bignum add, etc.).

Would this be cool or am I dreaming?

~~~
eudox
I'm pretty sure it was already done in the Symbolics Lisp Machine.

~~~
rjsw
Also in the LMI K-machine [1].

I got part way through building type checking hardware to use with Franz Lisp
on 68k CPUs. Franz Lisp allocated objects of a single type in each page and
the 68k had function code pins that meant you could tell whether a bus read
was for data or instruction fetch, the idea was that I would modify the
compiler to read a latched type value just after a Lisp object had been read
into a register.

[1]
[http://fare.tunes.org/tmp/emergent/kmachine.htm](http://fare.tunes.org/tmp/emergent/kmachine.htm)

------
TazeTSchnitzel
Wouldn't a "Lisp CPU" be like the one in the classic Lisp Machines, which
didn't execute Lisp directly, but were optimised for executing it?

~~~
rjsw
The ideas on the web page are closer to the Scheme-79 chip [1] than a Lisp
Machine.

[1]
[http://dspace.mit.edu/handle/1721.1/6334](http://dspace.mit.edu/handle/1721.1/6334)

------
swetland
Jeff's LispMicrocontroller is another example of this sort of thing (but a bit
further along, it seems):
[https://github.com/jbush001/LispMicrocontroller](https://github.com/jbush001/LispMicrocontroller)

------
adrianm
This looks like a really fun project. I'd be interested in any good Verilog
resources anyone can recommend. Also, does anyone know if there is there an
affordable way to get components you design manufactured on a small scale?
(Not in the thousands of units, I mean.)

~~~
peaton
FPGAs are definitely the way to go. They are cheap and reprogrammable. One
awesome devboard is the Zedboard. It includes 2 (?) ARM cores and a 28nm FPGA.

------
daveloyall
I'm not familiar with Verilog. I wonder if something like this[1] would be a
useful tool in this developer's belt.

1:
[http://www.cs.colby.edu/djskrien/CPUSim/](http://www.cs.colby.edu/djskrien/CPUSim/)

------
listic
What are the good convenient and modern FPGA's good for a modern computer?

I'm not sure what I'm asking here, really. I would ask for a PCE-Express
board, but I've switched to a laptop as my main machine, with external
monitor, keyboard and mouse when in home/office. I guess a PCE-Express board
that could in principle be used in a rack-mount server would be useful.

~~~
wmf
Probably a Zedboard.

~~~
listic
I don't see a PCI-Express one. Alternatively, which one do you find
convenient? I think the external board should have some kind of case so that I
won't have to worry about short-circuiting it.

~~~
pjc50
When you say you want a PCIe one, do you really want to start by writing your
own PCI slave? It's a bit of a pain. And having the FPGA on the PCI bus lets
it crash your development PC when you get it wrong.

~~~
listic
You're right, I wouldn't want to write my own PCI slave and have it crash my
PC. Unless the board developer already took care of that, it's probably better
to go with standalone board for now. I hope we'll see more convenient FPGA
development boards that will be no more hassle to use than an extra videocard
in your PC now, as Moore's law hits the wall and FPGA's become more
ubiquitous.

------
Brashman
As written, that INIT section is really going to limit clock speed. I also
don't understand why currentState is double clocked.

~~~
scott_wilson46
It's not going to limit clock speed, its just not going to work. To write
multiple values to different ram locations (considering a ram has at most two
ports) would require you to stay in the INIT state for 9 cycles and do
something like:

    
    
      INIT:
        begin
        if (count == 9) begin
          next_count == 0;
          nextState = `EVALUATE;
        end
        else 
          next_count == count + 1;
        case (count)
          0: begin ram_wr_addr = count; ram_wr_data = `CMD_LED_ON; ram_wr_en = 1; end
          1: begin ram_wr_addr = count; ram_wr_data = `CMD_LOAD_NEXT_TO_ACCU; ram_wr_en = 1; end
          etc....
        end
    

usually you have a ram module that takes an address and some write_data,
wr_en, etc rather than accessing the array directly.

~~~
jff
I think we've come back to "original author doesn't actually know how to write
logic, thinks he's writing sequential code" as the core problem

------
moron4hire
It always surprises me to see these sorts of projects NOT based on Racket. I
guess that is the danger of Scheme, it's so easy to reimplement the base
language that everyone is doomed to spending lifetimes reimplementing the
standard libraries.

~~~
stcredzero
Perhaps the next "next Java" or "next C++" had better focus on also being a
more or less universal platform, such that the reimplementation of standard
libraries becomes a thing of the past? The CLR strove to be this, but this
didn't take off because of its association with Microsoft.

The "designed to be hosted" structure of Clojure points the way to how this
could be approached. Stallman's designs for Scheme and GUILE are along these
lines as well.

~~~
pjmlp
Since UNCOL people keep on trying, but in the end it always ends up not quite
there.

