[racket] Dr. Racket for FPGA development

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Sat Sep 17 13:22:36 EDT 2011

Matthias Felleisen wrote at 09/17/2011 12:27 PM:
> What we really need is a #lang pre. 

Would modules done in "#lang pre" provide an intermediate 
representation, so that different target architecture backends could 
require the module and emit FPGA HDL, JVM bytecode, some assembler, etc.?

If so, I wonder whether someone has enough a priori knowledge that they 
could do "#lang pre" from the start, or whether they'd have to work 
through at least a couple diverse target architectures before the 
abstractions "#lang pre" provides start to stabilize?  (I don't know 
enough a priori knowledge myself, but someone else might.)

One way someone could get to this "#lang pre" incrementally: (1) 
develop, say, "#lang  pre-fpga", focused on the mechanics of 
translation, not on modularity; (2) separate the "pre" and "fpga" parts 
into separate modules; (3) develop, say, "#lang pre-arm", using the same 
"pre" module from before, which means refactoring the "pre", "fpga", and 
"arm" modules together, and possibly adding units; (4) make a "#lang 
pre" based on the "pre" module, which might mean more refactoring of all 
of the modules to make an IR; (5) maybe do a third target architecture, 
or get other people using "#lang pre" for other targets, and refine 
"pre" based on that.

Note that step #1 above might be the most engaging way to start, with 
the most immediate gratification: you start typing code in a DrRacket 
window and hitting the Run button, and in half an hour you are starting 
to generate something that looks like code, and you go from there.  The 
other steps might not be as fun, so we have to bait&switch.

An alternative loosely-coupled community process is for a few people to 
independently start the fun step #1 for different targets, and then 
maybe one of them gets hooked and decides to take it to "#lang pre", and 
they can all compare notes and code for the different targets.

Then there's LLVM, which you might use in some capacity, or you might 
decide there's a simpler or better way for your needs.


Posted on the users mailing list.