Bootstrapping Forth on JVM, .NET CLR, etc.


    Sponsored Links


  • 1. Mutual recursion in FORTH
    I've been thinking about the best way to do mutual recursion between two words A (which calls B) and B (which calls A). Standard FORTH doesn't provide for forward references. So if I compile A before B, then I can't compile the reference to B in the usual way. RECURSE is of no help, since it can only compile a call to the word currently being compiled. One solution is to defer the resolution of B to run time e.g. 0 VALUE TICKB : A TICKB EXECUTE ; : B A ; ' B TO TICKB But this adds overhead to the call. So I thought it might be it possible to resolve B at compile time e.g. 0 VALUE REFB : NOP ; : A [ HERE TO REFB ] NOP ; : B A ; ' B REFB ! This works on a traditional compiler, which compiles an execution token for NOP that I can override later when I know the address of B. But I believe an optimizing compiler is free to compile nothing for NOP, so this won't work in that case. Is there a portable way to implement mutual recursion with no additional call overhead?
  • 2. FORGET
    Dnia 18.05.2010 Anton Ertl < XXXX@XXXXX.COM > napisaa: >>> Seems to be one of most basic words... >> >> Not really. It's not in CORE, and it was deemed obsolescent (to be >> removed from the standard). It has a significant number of fans, but >> that does not make it basic. After some time flew already, I would to mention, that FORGET indeed is helpful at least in quick-trying modification of the created words - it's simply more convenient to temporarily "overwrite" the word under creation - or while "polishing" - and then decide, whether new version is better, or there's a need for FORGET, to get back to the old one. Theoretically MARKER makes the same thing, but only requiring planning in advance - and it's about this "only": while using FORGET I'm able even to "stack" several newer "versions" of word one-on-another, without this I've got to "mark" each step; indeed it's less convenient. FORGET seems to be "increasing interactivity". If possible - and not requiring serious amount of implementation time - it could be worthy to keep it for (current and future) novice Forthers. >> I have not used it in 20 years. As experienced Forth-programmer - you don't have to anymore. ;) -- Zbigniew
  • 3. EDIT
    What's the stack signature for EDIT (to invoke the built in block editor). I'm basically working to Forth-83 standards, but EDIT is of course not part of the standard. I guess it could be either: EDIT ( address -- ) or EDIT ( block -- ) Currently, my version is the former, and partners with BLOCK: 50 BLOCK EDIT I'd kind of prefer just 50 EDIT I guess I could just make a new word? : ED ( block -- ) BLOCK EDIT ; Mark

Bootstrapping Forth on JVM, .NET CLR, etc.

Postby joel reymont » Tue, 07 Aug 2007 14:38:01 GMT


Suppose I wanted to bootstrap a Forth on a JVM, .NET CLR or another
existing VM.

Where would I start?

I'm learning Forth on a Mac (gForth) and don't want to use Windows.

My goal is to create a network link from my Mac to the target VM for
interactive development with cross-compilation and debugging happening

    Thanks, Joel

Re: Bootstrapping Forth on JVM, .NET CLR, etc.

Postby joel reymont » Tue, 07 Aug 2007 15:53:42 GMT

To be more precise... Suppose I started up gforth and I'm at the
interpreter prompt.

I want EXECUTE to generate the appropriate bytecode and run it on the
linked VM.

How do I make sure that EXECUTE is not the one that gforth supplies?

Do I hack at the gforth source code to build the cross-compiled Forth
and if so then is gforth the right Forth to start with?

I see no reason to re-implement the "outer interpreter" (right
expression?) and would like to let gforth parse my Forth code. I can't
envision how I would replace the code generation part, though.

    Thanks, Joel

Re: Bootstrapping Forth on JVM, .NET CLR, etc.

Postby Dmitry Ponyatov » Fri, 10 Aug 2007 03:01:27 GMT

You can use your own byte-code interpreter (a.k.a. inner interpreter =
engine = virtual machine) written in Java/C#, and cross-compiler
written in FORTH which generates byte-code from Forth-like language

Re: Bootstrapping Forth on JVM, .NET CLR, etc.

Postby Dmitry Ponyatov » Fri, 10 Aug 2007 03:04:52 GMT

at  http://www.**--****.com/ 
build upon this principle -- simple virtual forth machine in C with
some C++ elements and cross-compiler for SP-FORTH (I still now
understand vocabularies and use lower-cased words for FVM commands and
some non-standard language elements like { } var const buffer)

Similar Threads:

1.JVM vs CLR

2.Micro Focus COBOL runtime, /clr:pure, etc.

Pete raised this issue in another thread, and coincidentally I ran
smack up against it yesterday.

A .NET application compiled using the Micro Focus Net Express add-in
for Visual Studio will not run on a system which lacks the Micro Focus
COBOL runtime DLLs. I infer from the reference to accountants, that
the cost per seat to license the runtime is high. This rules out
redistribution on my part.

Interested developers could just download and install the same free
tools as I've already used to create my non-commercial project. I've
posted instructions on the Barbarian's CodePlex page, which explain
how to acquire and install these tools: Net Express 5.1 Personal
Edition, and the Visual Studio Shell which is its minimal requirement
for installation.

Granted, nobody should do this while on the clock. My application is a

Tell me, though, does the Micro Focus COBOL compiler have any command
line option similar to /crl:pure? This compiler option for Visual C++
2008 generates assemblies which run with nothing more than the .NET

One last technical question. When working with other languages, the
command line arguments for the compiler are displayed in Visual
Studio's project properties. Does the Micro Focus add-in provide this
feature somewhere?

If I've violated the Net Express Personal Edition license agreement by
releasing a Micro Focus-dependent EXE to CodePlex, somebody please
tell me, so I can kill that project now.


 - Matt Fisher

3.a tutorial on bootstrapping forth?

For a while now I've been trying to find a good tutorial on implementing a
forth system from scratch.  I haven't found one yet so I decided to ask here
and see if anybody knows of one.

From my research I've learned about the inner/outer interpreters.  I've even
heard that some people have written extremely basic forth compilers in
assembly that support only a handful of words (e.g. get/set a byte, colon,
semicolon and a few others) and then they "cross-compile" forth code for
the two interpreters into full featured Forth system.

Does anybody know what the minimal set of words would be for the
"cross-compile" bootstrapping method?  Does anybody know of forth source for
an inner and outer interpeter combo?


4.Forth bootstrapping framework - Bootforth

5.Bootstrapping a Forth in 40 lines of Lua code

6. Cleaning up ANS Forth variables, values etc

7. Fw: Using Forth to send a windows message to a MS application (spell checking etc)

8. FORTH v GO plan9 etc

Return to forth


Who is online

Users browsing this forum: No registered users and 28 guest