[racket] OPERATING SYSTEM ON A FPGA

From: Hugh Aguilar (hughaguilar96 at yahoo.com)
Date: Wed Dec 5 22:51:08 EST 2012

What would a Racket OS on an FPGA be used for???

I wrote the assembler/compiler/simulator development package MFX for the MiniForth processor, which ran Forth as its native language. That thing had a specific use --- it was for a motion-control board, primarily used in a laser etcher. The MiniForth was built on a Lattice isp1048 PLD, not an FPGA, but most of the same ideas apply. There have been several Forth-engines built on FPGAs, as well as several built as hard processors, although I only worked on the MiniForth.

I really don't think that you are going to get Racket, or any other dynamic-OOP language, to run on an FPGA. Slava is interested in getting Factor, which is dynamic-OOP, to run on micro-controllers and compete against Java --- but he told me that the smallest processor that could support Factor would be the ColdFire. I'm not really interested in such big processors. Factor is a better choice than Racket for that kind of thing though, as it compiles to machine-code and doesn't have a VM or JIT or any of that other stuff that adds complication at run-time.

I'm writing my own language now, which I call Straight Forth. This will target small processors, such as the PIC24, that Factor can't run on. This language borrows heavily from Scheme though! I have closures, which Forth has never had (and never will, from what I've seen of Forth-200x). My closures are pretty similar to Factor's quotations; they have access to the creator function's local variables. They have these limitations:
1.) You can't use closures after the creator function has gone out of scope (trying to do so will cause the program to abort with a helpful error message).
2.) You can't nest closures inside of each other; each creator function only gets one level of closures. This means you can't use them as control structures the way that Factor does.

My closures are primarily supposed to be used for iterators. You have an iterator function that traverses some data structure, and it is given a closure as an input parameter, and it calls that closure for every node in the data structure. This is similar to my EACH in my novice package (http://www.forth.org/novice.html), except that the closure will communicate with the creator function through its local variables, rather than on the stack like I did in the novice package (and which was a major PITA).

I think that it is a very bad idea to try to get a dynamic-OOP language to run on a micro-controller. This might work in smart-phones, which is what Slava is aiming for, but it won't work on micro-controllers. You can't have GC on a micro-controller!

I think that it is a much better idea to do what I'm doing, or something like it --- make a Forth that borrows some of the high-level aspects of Scheme (mostly closures) --- but which does not have tagged data such as Scheme and Factor do, which is not appropriate for a micro-controller. It has been said that the language of the future will look like Lisp --- but that doesn't mean that it will be Lisp --- it will just borrow the appropriate ideas and reject the inappropriate ideas. Lisp and Scheme will never be used for real-time programming --- the micro-controllers just aren't that powerful, and even if they were, GC would still throw a monkey wrench in the works by making the thing stutter. On the other hand, Forth will never be a good choice for desktop-computer programming --- Scheme and Lisp, and pretty much everything else, are better choices.

I have said (on comp.lang.forth) many times that Forth should not try to be general purpose, as it becomes "a jack of all trades and a master of none" --- but that the Forthers should focus on micro-controllers, which is what Forth is good at. The same thing can be said about Racket though --- that the Racketeers should focus on desktop-computers, which is what Scheme is good at. It may be possible however, for Forth to borrow some ideas from Scheme (I'm borrowing closures), and for Racket to borrow some ideas from Forth (better support for integer arithmetic) --- meet in the middle!

cheers --- Hugh



Message: 1

Date: Wed, 5 Dec 2012 10:30:59 -0800
From: Patrick Li <patrickli.2001 at gmail.com>
To: users at racket-lang.org
Subject: Re: [racket] OPERATING SYSTEM ON A FPGA
Message-ID:
    <CANDUn1Qa9G_Sx5srFzLCN4uzF8a1epWn0kWxwU7z-5qCaw80Mw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I am personally also very interested in this topic, if Matthias and Erich
would shed some light on it.

I have only done system programming in assembly and C, and found that I
frequently did a lot of manual placement and shuffling of data in memory,
with the usual pointer tricks.

Off the top of my head, I do not how those same tasks would be accomplished
in a dynamically typed, and garbage-collected language like Scheme. Would
anyone be able to explain the gist of it?

Of course, there are real systems that are actually built upon such
languages. The Symbolics machines and Wirth's Oberon systems come to mind.
I am still reading through resources to figure out how they did it.

Thank you for any insight offered.
  -Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121205/88b6e459/attachment-0001.html>

Posted on the users mailing list.