Lisp CPU
frank-buss.de
frank-buss.de
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.
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.
Computer science grad here. I had to keep reminding myself about the HDL part of VHDL. It's not algorithmic description like programming is, but hardware description.
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.
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.
And this kind of distinction was what we were having trouble conveying to said software guy (I say this as a software guy myself), and I think the author of the LISP CPU is having the same problem.
That's not a bad thing.
Maybe this is why a Lisp processor doesn't exist. Not only do you have to know Lisp well, which only a minority of programmers do, but you also need to want to know hardware. Which is something software people don't want to do. This guy already has a leg up.
For some strange reason I can't explain it's easier to imagine a software guy building hardware than a hardware guy writing a Lisp.
Now, most people who do primarily hardware work probably aren't that interested in Lisp, because there's not really much Lisp focus out there. I'm a computer engineer, I know how to write HDL and lay silicon, I like Lisp... actually it would be a pretty fun project to do in an FPGA.
Sounds like he hadn't written much software in a language with an actor-model. It's not nearly as hard a jump to VHDL if you've ever debugged an Erlang supervision tree, or a miscommunicating set of SOA web services.
Behavioral descriptions are very, very similar to programming, and a lot of programming concepts and skills (e.g. modularization) translate very well to HDLs.
The only thing in HDLs I remember that is totally alien to programmers is propagation delays. Well, even that is somewhat similar to multi-threading issues.
Unfortunately, the digital circuit book also doesn't have a modern table of content: SR flip-flops and 7400TLS are not exactly related to Verilog much at all.
Is there a place where such issues can be discussed?
EDIT: I started https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...
You don't build more complex functions like adders or multiplexers from individual gates anymore, so don't put beginners into this outdated mindset. Sure, explain how to build a half-adder from ANDs and XORs, but make it clear that they shouldn't do this for anything except experimentation; you don't need any specific parts like the 7400s for this. Instead, teach them proper design techniques with HDLs (as horrible as VHDL and Verilog are, they are better than schematic designs).
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.
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.
[1] http://web.archive.org/web/*/http://www.frank-buss.de/lispcp...
LispmFPGA (2008) http://www.aviduratas.de/lisp/lispmfpga/
https://groups.google.com/forum/?fromgroups=#!topic/comp.lan...
IGOR (2008) http://opencores.org/project,igor
https://www.flickr.com/photos/kaitorge/sets/7215760944571932...
Would this be cool or am I dreaming?
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.
There were also extra bits in each word for cdr-coding lists, which was a way to internally implement a list as an array.
There might have also been an extra bit for GC, maybe for mark-and-sweep.
Smalltalk on a RISC (SOAR) is a simple, Von Neumann computer that is designed to execute the Smalltalk-80 system much faster than existing VLSI microcomputers. The Smalltalk-80 system is a highly productive programming environment but poses tough challenges for implementors: dynamic data typing, a high level instruction set, frequent and expensive procedure calls, and object-oriented storage management. SOAR compiles programs to a low level, efficient instruction set. Parallel tag checks permit high performance for the simple common cases and cause traps to software routines for the complex cases. Parallel register initialization and multiple on-chip register windows speed procedure calls. Sophisticated software techniques relieve the hardware of the burden of managing objects. We have initial evaluations of the effectiveness of the SOAR architecture by compiling and simulating benchmarks, and will prove SOAR's feasibility by fabricating a 35,000-transistor SOAR chip. These early results suggest that a Reduced Instruction Set Computer can provide high performance in an exploratory programming environment.
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.
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
Also, the use of a clock divider in this way is bad practice and another trap for beginners. Use clock that are on global clock lines, and use a clock enable to slow things down.
If you are going to build a Lisp processor, then you probably don't want a Lisp compiler or interpreter in the traditional sense, which is what Racket gives you. Maybe what you want is an interpreter in hardware.
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.