Been quitely iterating on Blue, my colorForth dialect/assembler. In v7 I have made some simplifications to the colors/interpreter which I believe may be of interest. Also just to note, I wouldn't be surprised if others have stumbled upon these or similar things, but there's not a lot of colorForth discussions that I've found, so everything in Blue is self-found, ai/llm free. I have seen screenshots/videos of the traditional colorForth system but have never used it.

Since Blue is bytecode based, I serialize it for source control and external viewing, in this case as html. The following is written for x86_64/Linux.

To get started, this is an html view of likely the most minimal Blue program that will emit a valid binary (124 bytes):

https://jbirddog.codeberg.page/blue/example/x86_64/true.b.html

However the one I'd like to show is more representative of an actual Blue program and shows how one goes from hand jit'ing with green numbers to higher level words, macros, variables and assemble-time execution of user defined words. This yields a 129 byte binary:

https://jbirddog.codeberg.page/blue/example/x86_64/true2.bl.html

There is a lot to unpack here, but for an overview of how the bytecode is interpreted: The interpreter starts each time with a clean slate - there are no built in words. The dictionary and data stack only exist at assemble time.

Color tag bytes have the sign bit set, so values between 0-127 are skipped, which allows for comments/whitespace in the bytecode.

The simplifications I'd like to mention are a reduced color set and dropping the `forth` and `macro` modes.

First, the colors for v7 have been reduced to:

red word: define label

green word: compile call/jmp to word in output

green number: write number to output

blue word: execute word at assemble time

blue number: push number onto the data stack

magenta word: push address of word onto the data stack

By default every color is immediate, however any color can be postponed. This allowed removing the `macro` and `forth` words that toggle the interpreter's mode - which lead to the ability to remove yellow and cyan words. This simplified the interpreter which dropped to 172 lines of non code-golfed asm.

For example, to define `;` its red(;) postpone(green(0xC3)) green(0xC3). Then when you write a blue(;) it will execute the postponed code to compile the number 0xC3 into the output, then hits the already compiled 0xC3, which is `ret` and returns to the call site. In short, `;` is a macro that when called does the exact same thing as if you had just written a green(0xC3). A very simple example but it shows the mechanics of it all.

In Blue a `;` following a green word does not implicitly turn the call into a jmp. I have found that error prone (since it basically looks back 5 bytes for 0xE8), so instead you set a flag on the green word to signal a jmp vs call. Likewise, magenta words can be flagged to return either the assemble time or runtime address of the word.

Anyway, sorry that got long, just wanted to share some colorForth. Happy hacking.

Hi everybody,

I've been very busy working on my game engine SUPERSHOW and a spooky little flagship platformer called Untitled KVN Game.

The genre of it is a mixture of horror, roguelite, and action-puzzle-platformer and it takes influence from various beloved games of mine including Super Mario Bros 2, Prince of Persia, and even Dark Souls.

A Russian artist I teamed up with on Discord conceived it and did the art and music, and an audio-engineer-musician friend from Baltimore did the sound effects.

I thought that SUPERSHOW was going to be released by now, but this game, originally meant to be a simple "demo" game, turned into something more serious than expected and I decided to dive right into attempting to go into business for myself as an indie developer, delaying SUPERSHOW's release. All the better - 1.0 will be more polished when it does release, probably sometime around mid-December. I think it's going to be something special that people will have fun with.

SPUNK, the same room-based framework as the one used in its spiritual prequel, KVN, is reused (updated for the latest engine). UKG also shows off a few technical advancements, including a brand spanking new physics-modelled CRT filter and advanced platformer physics. In addition, all of the maps were created with a proprietary level editor.

Here is a link to the pre-announce on itch.io:

https://inkajoo.itch.io/untitled-kvn-game/devlog/1717552/my-spooky-indie-game-releases-on-friday

Gameplay videos:

https://www.youtube.com/@cardboard-tv-games

I played with Forth about Forthy years ago (pun intended) while taking a break from BASIC. Now I program almost exclusively in Python. But I was wondering, if I wanted a targeted helper function that needs to be fast and it's simple enough to write in assembly (which I don't know), could I write it in Forth instead? I work on PCs and I should mention that I am an amateur programmer (in any language).

And when it come to fast (size is no longer an issue) does Forth have advantages over C?

If so, how would you do it? Which Forth interpreter / compiler do you recommend on a PC?

I guess what I am asking is, aside for the fun of it, is there any practical reason to dust off my Forth?

Thanks

So I have been making Inspiration run bare metal in QEMU using the limine boot loader. Having a higher half "kernel" makes things really interesting. In my mind, a bare metal Forth would start at the lowest memory address possible and dictionary grows up with heap at the high end of memory growing down.

There's a lot going on here. The system boots, it sets up the MMU so 4K pages can be allocated as needed and address ranges mapped in to the CPU's virtual space. Some things, like the incomplete NVME driver, need whole pages for internal structures, and some things like LAPIC need mmo address range mapped into virtual addresses with no cache and write thru attributes.

There's also an ethernet driver in progress for the e1000 series that is in the Thinkpad I intend to make this run on. It is finding the card's MAC address, which means a lot of it may be working. I need to study up on the qemu command line arguments to get it connected to my local network.

CPU 0 is the BSP or boot processor. It is the only one running initially and it does the initial setup. It sets up CPU 1 as a dedicated graphics processor that updates the display's frame buffer from an offscreen buffer where all rendering is done (for speed, the frame buffer accesses are slow).

The ConsoleDevice logic renders characters to the screen, displays and hides the green text cursor, scrolls up as text is printed past the bottom line. What you see in the screen shots is a rendered bitmap, not PC text mode.

CPUs 1-n (n is the number of processors in the machine) are started and each has its own round robin priority based Task scheduler. Only CPU 0 has any tasks that do anything, but all the CPUs but CPU1 have an IdleTask that runs when there are no active Tasks to run.

Tasking supports Task Local Storage, which took a lot of reading and trial and error to get right. This involved having the linker (ld) script gather the TLS variables into TLS data and TLS bss that need to be allocated and copied per task (BSS is zeroed). The C++ compiler uses FS:address to access the TLS variables, so FS has to be set up per task properly and maintained when switching tasks.

The InitTask is started in BSP. It spawns BootTask which sets up the FAT32 filesystem from the ATA drive initializes the Forth environment and starts INCLUDE-ing Forth sources from the 4th/ folder.

The Forth is the same one as in Inspiration - C++ functions.

To be useful on bare metal on my laptop, Forth++ must support the NVME drive and ethernet adapter. There's no use for the laptop if you can't read and write files and you can't back them up over TCP/IP.

I have not built this on Linux in a while, but it was building and running a week or so ago. I can post again when it is truly building and running there if you need linux to try it.

The repo is at https://codeberg.org/mschwartz/aforth

I have chosen to rename it to forth++ because of the amount of C++ involved and the nature of the Forth implementation. The repo still says "aforth."

As usual, I used no AI to make this. I relied heavily on my own repo for a prior bare metal C++ hobby OS effort I did as well as some others. I also relied on the osdev wiki. As well, I have no issue with using third party code, like jemalloc and lwip (TCP/IP stack).

Hello,

I am proposing a special challenge to this community.

I am currently rewriting my own inference engine. I am using eForth Windows.

The source code is here:

https://github.com/MPETREMANN11/eForth-Windows/tree/main/INFERENCE

Why choose eForth?

The Windows version uses 64-bit integers and addressing. This means there is plenty of room for code and examples.

eForth is available for ESP32, Windows, and as a web version...

The code is currently under development.

I am sharing it "as-is":

* to share ideas regarding its evolution,

* and to provide real motivation for this group.

An inference engine is not AI. An inference engine uses facts and rules to draw conclusions. It is applicable to any field.

When you use AI, you submit a prompt and the AI ​​provides an answer. However, you do not know if the answer is correct or how it was derived.

With an inference engine, you control the premises (the facts) used to deduce other facts based on rules that are also under your control.

If the inference engine malfunctions, it is because the rules or facts were poorly written. This writing process is something you can control.

With 10 facts, you could potentially have 2^10 rules to process. In reality, however, far fewer are processed.

Developing the rules allows you to formalize a problem with great precision. When establishing a rule, you focus on just one "atom" of the overall problem. The rules are interconnected with the facts being processed.

My inference engine prototype currently operates using only forward chaining.

Documentation will be written as development progresses.

The goal of the engine is not to recreate a version of Prolog or Guru. I am prioritizing FORTH, while ensuring the code is as readable as possible. Example:

\ RULES example

:CONDITION ." this is a condition" TRUE ;

:ACTION ." - this is an actionaction" ;

RULE: test1

rules test1

Thank you for your attention.

Hi, does anyone remember GraForth for PC/DOS? I found a Russian version that happens to be broken in some places and buggy in others. It means nothing at this point but a childhood memory, but I think that's good for something. Anyway, I was hoping someone could direct me to a fully functional English version.

Hi, I was curious about which implementation of forth would be the most flexible, maintainable, and high-performance, so I wrote a stack machine interpreter using various techniques. https://github.com/br1n0/stack-machine-interpreter-comparing/tree/master I managed to implement them all using the same data structure; this way, the program is expressed identically across versions, allowing for a direct comparison. I wrote a test program that runs a long execution loop, consisting of 2,000 subtractions and one multiplication, executed 4,000,000 times. In my opinion, the best implementation is the one using Token Threaded Code with dispatch via a function table, and is easy to extends. There is an interpreter overhead of about 25%; to measure it, I wrote a test where I execute the "words" directly from C, bypassing the interpreter.

I was surprised that GCC failed to optimize this program, even with -Ofast enabled. I thought this might be of interest to someone. Ciao

[ Removed by Reddit on account of violating the content policy. ]

Hi all, A small FORTH I wrote for the CH32X035:

• Runs in ~16 KiB FLASH, interactive REPL over USB CDC ACM
• Includes a minimal USB device stack written in assembly
• Tail-call optimization, cooperative multitasking

https://github.com/ebreak/ch32x035-forth

I'll be doing updates every week as I get this long-running project off my plate. Next up is keyboard handling!

Hi everyone,

I'm quite new to Forth. So far I really fell in love with the language, and perhaps I'm approaching it perhaps from a non-traditional angle (not sure, I'm saying that from all the material about Forth implementation I can find online which focuses a lot on hardware). I'm not interested in bare-metal hardware or low-level performance optimization. Instead, I'm building a high-level Forth VM hosted on top of a Python object model extension + runtime to act as a DSL and meta-compilation engine.

My underlying Python object model represents a modular environement (modular synth) relying on async thread-based actors. The Python runtime handles the graph of objects, their lifecycle, dynamic ports, threads, and interconnections, which eventually sink into MIDI synthesizers (and hopefully later to analog synth using control voltages). My goal is to use Forth to construct a clean, highly structured, and expressive API layer on top of this system while allowing users the possibility to extend the vocabulary and let them create their own abstraction on top of it if needed.

I'm currently focusing on linguistic design: What are the different DSL/API patterns that exist in Forth, specifically regarding the kinds of sentences they allow me to build?

So far, reading "Programming a Problem-Oriented Language", browsing "Thinking Forth", and looking to some kernel implementations, I observed 4 kind of core "sentence structures" quite often:

1. postfix fluent sentences: like BLUE 4 THICKNESS 10 30 LINE, where data is pushed on the stack and the last word resolves their usage.
2. scoped boundary sentence (context-block): like PATCH[ LFO1 output> >speed LFO2 ] 24 120 CLAMP ;PATCH where a kind of shared description data is created with possibility to set optional configuration for the underlying created data.
3. declarative prefix sentence: like SWITCH OfficeLight TURN-ON, which inverse the native postfix feel.
4. literal stream parsing sentences (don't know a better name): ROUTE 192.168.1.1 TO eth0 where each word is manually parsed.

Perhaps also a fifth one: tabular/matrix sentences? Currently I still didn't see that one often yet, but it seems quite powerful also.

I know that there is countless ways of manipulating the language, and the multitude of Forth implementations shows that, but most are really dedicated to extend the language at a lower level, and those higher level sentences to build higher-level DSL/API are sometimes not that easy to observe or extract.

My question to the community:

What other high-level sentence structures or API patterns have you seen or designed in Forth? How do you traditionally tackle complex querying, or configurations sentences with heavily optional parameters without falling into a stack-juggling hell?

I would love to read your architectural thoughts, points to specific papers, or classical Forth projects that pushed the boundaries of language-oriented programming.

If I'm totally out of scope or context, please let me know and feel free to bring me back to the right path.

Thank you!

Probably saying too much already, mostly found it on topic and amusing.

Previously I had released a very simple Asteroids clone, 'Rocks', for zeptoforth on the PicoCalc using the RP2350. (Sorry, but this requires hardware single-precision floating point.)

Now I have added significant enhancements to it, including shields, a number of different power-ups (extra lives, extra shields, retro-rockets, and rapid fire ─ and yes, I did slow down firing by default), the ability to pause, and alien enemies that can shoot at you, as seen in the image in blue.

The source code is still where it was before, at https://github.com/tabemann/zeptoforth/blob/master/test/rp2350/picocalc_rocks.fs.

My toy forth-like byte-code compiled language for Arduino chugs along. After a long pause, now I got me a real project, writing code for a morse key. I decided I want to learn morse, and so I am building a simple bug type key with a single paddle or blade. Push right for dit's and left for dah's. Sound via a buzzer for now.

The point is that the microcontroller generates the correct length dits and dahs and proper spacing, as long as I manage to give input at proper rate. The idea, which if one is to believe youtube experts, is that what matters is learning the proper sound of each character.

For lack of a better name, I call it aforth. Any suggestions for a better name?

I was working on a template for C++ bare metal programs for AMD64 and got far enough that it seemed like it might be fun to port the Forth (written in C++) from Inspiration to it.

And it works...

It boots using the limine bootloader. A bit of code was done to create a timer interrupt, keyboard handler, frame buffer text rendering (see the screenshot above), a solution for C++ try/throw/catch, thread local variables.

I also had implemented an ATA driver for disk I/O, and a FAT32 (read-only) file system that works - as you can see by the directory listings above.

I'm currently working on the Files wordset so I can INCLUDE/REQUIRE/etc., Forth source files from the FAT32 volume.

No AI used to make this. I did start with the limine barebones code from the osdev wiki. I expect I will be using 3rd party “contrib” software, like jemalloc, libpng, ilwip (tcp stack), and these sorts of libraries. I still have to write the device drivers myself.

The repo is here:

https://codeberg.org/mschwartz/aforth

Lots of goodies, including html improvements and high-level "data science" words.

Full details on the forum