[racket] Staapl (Re: Scheme's place in the world)

Sorry for 1.5 year late reply.  I just ran into this online searching 
for Staapl.  I'm not reading any lists these days...


On 11/21/2012 10:35 PM, Hugh Aguilar wrote:
> I am familiar with STAAPL. It looks pretty cool!
>
> It is for the PIC18 which is largely obsolete now.

I must say that after working with 16 and 32 bit microcontrollers for a 
while, stuffing things into 8 bit words does feel a bit awkward, but I 
wouldn't call the PIC18 obsolete yet.

The interesting part is that it's still a very simple chip which has 
always seemed like a good idea from the point of correctness.  However 
I've never done much with that idea in any formal way or so.


> Tom told me that he might upgrade to the PIC24, but I'm not aware that 
> he has done so yet.
I probably won't do this.  The PIC24/dsPIC isn't a bad chip, but I'd 
rather use a chip with an open set of build tools as are available for ARM.

If there is another target for Staapl it will most likely be an ARM 
Cortex M0 targeting newer devices like the LPC810, a 32bitter in a DIP8 
package!  And possibly some macros for cortex M4F DSP operations.  That 
would be just to get 32bits. Overall I don't see the point moving to 
modern register architectures.

The thing is that the quirky PIC18 architecture and a Forth machine 
model are a really good match.  Staapl's simple peephole optimizer does 
a pretty good job if you compare it to the mess that comes out of a 
PIC18 C compiler.

Once there is more than one working register, the problem of code 
generation becomes something else entirely.   There it looks like an 
LLVM target makes more sense.

I'm actually more inclined to look the other way: smaller special 
purpose stack machines on FPGA.



> The PIC18 is more powerful than the AVR8 that is used in the Arduino 
> (and I don't know what you mean by "Processing"). I like MicroChip as 
> they provide very good development tools and customer service --- 
> although the PIC18 isn't exactly cutting edge anymore, it is still a 
> reasonable choice.
>
> Tom's system isn't truly Forth, because the user can't write 
> compile-time code in Forth as is generally expected, but must write 
> that stuff in Scheme --- only the run-time code is written in Forth.

Yes and no.  There is no feedback from the run time system to the 
compiler in the way that forth is "reflective".  The Staapl approach is 
essentially inherited from Racket's language tower approach and this has 
been a good thing.

However writing macros in the Forth DSL is largely the point of Staapl.  
This is done in an implicit way -- macros and Forth words are mostly 
interchangeable -- as opposed to Forth's explicit way of manipulating 
execution tokens and inserting them into the code stream.  This leads to 
a compile time language that's very much like Joy.

For the schemers: it's a bit like the distinction between syntax-rules 
and syntax-case but that analogy breaks down at some point.

I lack the vocabulary to explain this properly but basically it's built 
around eager partial evaluation at compile time which is also the 
assembly code peephole optimizer.

The compile time language has Scheme datatypes that get eliminated 
before the code hits the target, at which point it's all just 8 bit numbers.

I tried to explain it here:  "expand and contract"
zwizwa.be/staapl/flunk-20131120/index.html



> Still though, it looked pretty interesting. Now that I'm getting into 
> Scheme, I may delve into STAAPL myself as a learning exercise --- I 
> might be able to borrow ideas for my own system. :-)

If anyone want's to try, I've been working on it again recently and have 
some time for support.  Email me directly.

I'm using it now as a platform to build a tiny digital/analog synth 
hybrid.  Some long standing bugs in the USB driver are fixed so it's 
gotten a lot easier to use.  If you don't need any obscure features it's 
possible to just flash a kernel once and use a single USB cable for repl 
and racket interaction.

USB currently supports serial and MIDI. Adding new USB interface 
descriptors is straightforward.  There's a something resembling a 
descriptor DSL :)

To start you'll need a PIC programmer (e.g. cheap $15 pickit2 clone on 
eBay) and a board with a USB PIC18F.  I've been using this one:

http://100mhz.com/pic-dspic-pic32-pic24/development-boards/pic-18f4550-usb-demo-development-board-pic18f4550-microcontroller-1073.html

>
> Are there any other compilers written in Scheme? From what I've 
> learned about Scheme so far, it seems like a pretty good language for 
> writing a compiler.

Racket is simply great for writing compilers as macro layers on top of 
Scheme.
I've learned so much from Racket's module & macro approach and continue 
to do so.

BTW, I never said thank you.

Thank you!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140719/bb267720/attachment.html>