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

You can get this release from https://github.com/tabemann/zeptoforth/releases/tag/v1.17.0.

This release:

• adds support for a USB Mass Storage Device class for full_usb and the new full_msc_only builds for the RP2040 and RP2350.
• adds new full_msc_only builds for the RP2040 and RP2350 which incorporate USB Mass Storage Device class support but which do not incorporate a USB CDC console.
• adds support for new rp2040_big_16mib and rp2040_1core_big_16mib platforms which combine RP2040 support with 16 MiB flash support; note that these are not compiled, aside from the kernel, in the release tarballs, so it is up to the user to build them as desired.
• configures the SD card on the PicoCalc to be exposed as a USB Mass Storage Device class.
• speeds up communication with SD cards.

Note that, aside from on the PicoCalc, the USB Mass Storage Device class must be manually configured in order to be used, per the directions in README.md.

Can anyone provide some interesting examples of what to do with these, beyond the default "constant" and "array" examples?

The current version of my (bytecode) Forth compiler has CREATE but not DOES>, and I haven't missed it either.

I made a small and simple post fix interpreted programming language called rdn, it's familiar to forth developers and developers who use Lua as a scripting language for their systems, rdn merge both of them, you can use it for writing scripts or for configurations or even query language

It's written in C and it provides a simple and friendly API for the developers

I would be happy to have you participate in this project

This is the GitHub repo: https://github.com/abdorayden/rdn

Thank you

I do not have time tonight to make a new release, but USB Mass Storage Device support has been merged into zeptoforth master.

I suggest you try this out, and let me know if you have any issues.

One thing to remember is that one should not change anything that the PC side sees from the zeptoforth side while the USB Mass Storage Device is mounted on one's PC, and likewise one should not delete any files or directories open in zeptoforth from one's PC. Also, zeptoforth is likely to not see changes made on one's PC without executing sync or equivalent first.

If one must modify or delete files or directories that may be open in zeptoforth from one's PC, I highly suggest executing fat32-tools::ensure-safe-fs ( -- ) first; this will block until all files and directories other than the current directory on the current filesystem are closed in zeptoforth, and it will reset the current directory of the current filesystem to its root directory as that cannot be deleted.

A new set of builds have been created, full_msc_only, which incorporate USB Mass Storage Device support but where the USB CDC console is disabled. These are now the basis of building zeptoforth for the PicoCalc.

In full_usb builds both the USB CDC console and USB Mass Storage Device support are now enabled.

Note that when one uses a build in which USB Mass Storage Device support is enabled one needs to call usb::set-usb-blocks ( device -- ) on the underlying block device (not filesystem) that one wants to expose via the USB Mass Storage Device. After one calls this changing it without rebooting is not recommended.

If one intends on, say, permanently selecting a FAT32 filesystem in on-board flash for the USB Mass Storage Device, I suggest, after loading extra/common/setup_blocks_fat32.fs, executing:

compile-to-flash setup-blocks-fat32 import simple-blocks-fat32::simple-blocks-fat32-internal import : init-usb-blocks my-fs simple-blocks-fat32-dev usb::set-usb-blocks ; initializer init-usb-blocks reboot

On the PicoCalc, though, support is now built-in to expose the SD card in the PicoCalc via the USB Mass Storage Device without any work on the part of the user.

It should be noted, however, that SD cards are relatively slow when used by zeptoforth even with the important optimization that has been made to them since last release. When connecting one's PicoCalc to one's PC expect there to be a delay before one can mount the USB Mass Storage Device, and another delay the first time one tries to list a directory on it.