jonesforth VS stoneknifeforth

Cool. Here are some other resources that I've encountered along the way of learning Forth:

- JonesForth: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

This is legit a text that goes the an x86 Forth implementation. Actually, it's just an implementation with really extensive comments. That said, including whitespace and comments, it's just 2000 lines and the pedagogy is excellent. Highly recommended for anyone who would rather see behind the curtain before picking up a larger text.

- SmithForth: https://dacvs.neocities.org/SF/

So, Smith decided to hand-write a Forth directly in x86-64 opcodes (well, the corresponding ascii hex bytes). It's incredibly slim and enlightening how you can bootstrap a language in just a couple hundred bytes or so.

This project actually inspired me to really learn the x86-64 architecture, so I ended up hand-decompiling the SmithForth binary instead of going through his commented implementation. Hand-decompilation is an absolutely fascinating exercise. You learn all about ELF structure, opcode encodings, and actually start to see the gaps where microarchitectural details shine through. Highly recommended for any hacker that really wants to grok low level details.

- Mecrisp: https://mecrisp.sourceforge.net/

An amazingly fast Forth implementation for MSP430, ARM, RISC-V, MIPS, and some FPGAs. This gave me one really nice understanding of Forth as

    A REPL into your hardware!

I've git-cloned JonesFORTH (https://github.com/nornagon/jonesforth/blob/master/jonesforth.S) and achieved to compile it (i.e. run make w/o an error. When I start the executable, it presents me with an empty line, and when I say BYE, it says PARSE ERROR: bye.

Is there any particular language you're looking for? I've found some languages hideous until I understood them and could appreciate their respective graces. Off the top of my head the I can think of a couple.

The first is Jones Forth (https://github.com/nornagon/jonesforth), start with jonesforth.S and move into jonesforth.f. I really enjoyed following along with it and trying my hand at making my own stack based language.

The other is Xv6, a teaching operating system from MIT (https://pdos.csail.mit.edu/6.828/2021/xv6.html), not all the code or implementations are top notch but it shows you non-optimized versions (just because they're simple and more readable) of different concepts used in OS design.

If you're interested in the embedded world, there is a really neat project I've been following that feels a more structured and safe (as in fault-tolerant) while still staying pretty simple (both conceptually and in the code itself): Hubris and Humility (https://hubris.oxide.computer/).

Very low hardware requirements, so basic industrial control at the level where you'd otherwise use an Arduino or so but on scavenged hardware. Forth is ridiculously simple to get an implementation running.

https://github.com/nornagon/jonesforth/blob/master/jonesfort...

Is a nice starting point. It's obviously not as compact as say 'Brainfuck' but it is far more versatile.

OP mentioned jonesforth, but linked to a nasm port of it. Which is probably good it’s just that the documentation in the comments with ascii art doesn’t look right on my screen. So here’s a more common repo: https://github.com/nornagon/jonesforth

Rip the asm macros for the basic FORTH words out of this and then embed them in a C binary, statically linked with your favourite libs for whatever task. Although I haven't tried this yet, I'm planning on doing it with ncurses for my own Roguelike. From there, if you can convert the function calls and your parameters down to raw numbers, you can send instructions to ncurses or whatever other API you like, directly from a FORTH stack.

or the mirror of this site in github: https://github.com/nornagon/jonesforth

a problem that a lot of these series run into is that the author runs out of steam before they finish writing them. crenshaw's otherwise excellent series suffers from this, for example

so far the author of this one has only written the first chapter

i've written a few didactic compilers that are complete enough to compile themselves, though nothing else

https://github.com/kragen/stoneknifeforth (from a forth-like language to an i386 linux elf executable)

https://github.com/kragen/peg-bootstrap/blob/master/peg.md (from a peg language description with semantic actions to javascript)

http://canonical.org/~kragen/sw/urscheme (from a subset of scheme to at&t-syntax i386 assembly)

Look at how much room you have for data! I wonder what we can fit in there.

More seriously, a metacircular example to draw from would be: https://github.com/kragen/stoneknifeforth

i wasn't able to get a runnable forth to less than a couple of pages written in itself https://github.com/kragen/stoneknifeforth but schönfinkel's ski-combinators are maybe the simplest practical basis

    s f g x → f x (g x)

I've done all these things (except designing the hardware) and I agree that it can be very painful. I did some of them in 02008, for example: https://github.com/kragen/stoneknifeforth

The thing is, though, you can also not do all those things. You can use variables, and they don't even have to be allocated on a stack (unless you're writing a recursive function, which you usually aren't), and all the NIP TUCK ROT goes away, and with it all the Memory Championship tricks. You can test each definition interactively as you write it, and then the fact that the language is absurdly error-prone hardly matters. You can use metaprogramming so that your code is as DRY as a nun's pochola. You can use the interactivity of Forth to quickly validate your hypotheses about not just your code but also the hardware in a way you can't do with C. You can do it with GDB, but Forth is a lot faster than GDBscript, but that's not saying much because even Bash is a lot faster than GDBscript.

But Yossi was just using Forth as a programming language, like a C without local variables or type checking, not an embedded operating system. And, as I said, that's really not Forth's strength. Bash and Tcl aren't good programming languages, either. If you try to use Tcl as a substitute for C you will also be very sad. But the way they're used, that isn't that important.

I explained a more limited version of this 12 years ago: https://yosefk.com/blog/my-history-with-forth-stack-machines...

So, I don't think Forth is only useful when you have the freedom to change the problem, though programs in any language do become an awful lot easier when you have that freedom.

That's powerful enough to conveniently write, for example, a numerical root finding program for an arbitrary arithmetic expression.

But I think that within a complexity budget of 150 lines of code you can maybe be even more ambitious than that.

The example compiler in https://github.com/darius/parson/blob/master/eg_calc_compile... is a bit more stripped down than that, but in its 32 lines of code it compiles arithmetic assignment statements to a three-address RISC-like code (though using an unbounded number of registers). https://github.com/darius/parson/blob/master/eg_calc_to_rpn.... is a 16-line version that compiles the same language to a stack machine like your tutorial example.

In 66 lines of code in https://github.com/kragen/peg-bootstrap/blob/master/peg.md I wrote an example compiler which compiles a PEG grammar into a JavaScript parser for that grammar. Admittedly those 66 lines do not include an implementation of JavaScript to run the code on. It compiles the language it's written in.

In 132 lines of code in https://github.com/kragen/stoneknifeforth/blob/master/tinybo... I wrote an example compiler which compiles a crippled Forth dialect into i386 machine code, including an ELF header so you can run the result. It also compiles the language it's written in. It also doesn't include an i386 emulator to run it on.

In 83 lines of code in http://canonical.org/~kragen/sw/dev3/neelcompiler.ml Neel Krishnaswami wrote a compiler from the untyped λ-calculus to a simple assembly language for a register machine. It also doesn't include an implementation of the assembly language.

In 18 lines of code in http://canonical.org/~kragen/sw/dev3/meta5ix.m5, a simplification of META-II, I wrote a compiler from grammar descriptions to an assembly code for a parsing-oriented virtual machine. It compiles the language it's written in. A Python interpreter for the machine is in http://canonical.org/~kragen/sw/dev3/meta5ixrun.py (109 lines of code) and a precompiled version of the compiler-compiler for bootstrapping is in http://canonical.org/~kragen/sw/dev3/meta5ix.generated.m5asm.

A slightly incompatible variant of Meta5ix which instead compiles itself to C is in http://canonical.org/~kragen/sw/dev3/meta5ix2c.m5 (133 lines of code, depending on how you count). (No C compiler is included.) The precompiled C output for bootstrapping is in http://canonical.org/~kragen/sw/dev3/meta5ix2c.c.

Meta5ix is extremely weak and limited, really only enough for a compiler front-end; it can't, for example, do the kinds of RPN tricks we're talking about above.

Title effectively says it all. The only thing I have found is StoneKnife Forth (implementation is in tinyboot1.tbf1) but this file is implemented in the same dialect of forth it implements, which due to being minimal makes it difficult to read and comprehend efficiently (I also can't find the origin of some words such as 'byte' used in the code but not implemented by the interpreter). I would prefer something in the C family to look at but anything should do as long as it's clean enough that I could use it as a reference to reimplement the compiler without much difficulty. Thank you in advance for any help with what is seemingly quite a narrow request.

I'm pretty sure Linux ELF has always allowed you to specify the initial load address. When I first wrote StoneKnifeForth https://github.com/kragen/stoneknifeforth its load address was 0x1000, but at some point Linux stopped allowing load addresses lower than 0x10000 by default (vm.mmap_min_addr). I originally wrote it in 02008, using the lower load address, and fixed it in 02017. It's still not using 0x804800 like normal executables but 0x20000. ASLR does not affect this.

Maybe you mean that before ELF support, Linux a.out executables had to be loaded at a fixed virtual address? That's possible—I started using Linux daily in 01995, at which point a.out was already only supported for backward compatibility.