Maybe we shouldn't be focusing on FPGAs and instead focus on memristors. On Dec 7, 2012 1:37 AM, "Eugen Leitl" <[email protected]> wrote:
> ----- Forwarded message from Tomasz Rola <[email protected]> ----- > > From: Tomasz Rola <[email protected]> > Date: Thu, 6 Dec 2012 23:58:57 +0100 (CET) > To: [email protected] > Subject: Re: [info] [racket] OPERATING SYSTEM ON A FPGA (fwd) > > > ---------- Forwarded message ---------- > Date: Wed, 5 Dec 2012 19:51:08 -0800 (PST) > From: Hugh Aguilar <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [racket] OPERATING SYSTEM ON A FPGA > > 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 <[email protected]> > To: [email protected] > Subject: Re: [racket] OPERATING SYSTEM ON A FPGA > Message-ID: > <candun1qa9g_sx5srfzlcn4uzf8a1epwn0kwxwu7z-5qcaw8...@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 > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > > _______________________________________________ > info mailing list > [email protected] > http://postbiota.org/mailman/listinfo/info > > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
