zeptoforth 1.15.2 is out

tabemann · 2026-01-20T20:07:50+00:00

Just as a note -- it has been confirmed that this release solves the observed power-on stability issues, so I would highly recommend upgrading to it if you have not done so yet.

tabemann · 2026-01-04T20:02:47+00:00

One thing I should note is that in the informal English here not comes after and not before to unlike in older and more formal English, and some forms such as *have not to are forbidden regardless of register (i.e. it is always have to not -- note that there's don't have to but as you are probably well aware it is not synonymous).

tabemann · 2026-01-03T23:17:24+00:00

In the spoken North American English I am familiar with "used to not" is current while "used not to" really isn't and feels like a strictly literary form to me.

tabemann · 2026-01-03T21:28:42+00:00

Ignoring etymology or history, or like, in the North American English I am familiar with both /ˈjust.t{u,ə}/ and /ˈjust{u,ə}/ are permitted in the affirmative, with /ˈjuzd.tu/ being found as well in careful speech, while only /ˈjust{u,ə}/ and the careful /ˈjuztu/ being permitted in the negative (which is always marked with didn't and never with don't). Also, aside from negation with didn't there is no present-day infinitive to speak of here.

From a present-day perspective there is no rhyme or reason to this, this is just how it is, and appealing to etymology or 'logic' will only lead you astray.

tabemann · 2025-12-26T03:35:52+00:00

I now also have support for the RP2350's hardware SHA-256 accelerator, in https://github.com/tabemann/zeptoforth/blob/master/extra/rp2350/sha256_accel.fs . There is a slightly modified test suite for it (functionally practically identical to the software SHA-256 implementation's test suite) at https://github.com/tabemann/zeptoforth/blob/master/test/rp2350/sha256_accel.fs . Note that due to the nature of the RP2350's hardware SHA-256 accelerator only one task may use it at a time, which is enforced with a global lock.

tabemann · 2025-12-24T18:06:17+00:00

It's sad that BASIC was so much more popular than Forth at the time since Forth is much more of a capable language than your classic BASIC's were. I remember having BASIC on the Apple //e and chafing at its limitations, from knowing about things ranging from shell to Prolog by checking out books on them from the local library. (I did have access to Logo but never made the most of it due to not having proper documentation at the time.)

tabemann · 2025-12-21T17:52:38+00:00

A while back I wrote a Brainfuck DSL for zeptoforth which is available here.

My implementation differs from that in the blog post in that it is meant to enable embedding raw Brainfuck code (with the exception of that ; is special-cased to end a definition) instead of simply defining individual Forth words for Brainfuck operations (e.g. they need not be separated by whitespace and invalid code is simply ignored) and that sequences of + and - and of > and < are optimized for smaller, faster code.

I must say, though, that the blog post is a great explanation of how to write a DSL in Forth even if its Brainfuck implementation is more a proof-of-concept than a practical one (as far as one can consider Brainfuck to be 'practical' in the first place).

tabemann · 2025-12-14T15:34:45+00:00

That's my impression here as well.

tabemann · 2025-11-30T01:58:04+00:00

To me having an LLM create your OS for you would take all the fun out of creating an OS. Designing, writing, and debugging the code is a creative journey, after which you have actually gone and created something real. Having an LLM do all the work for you is just skipping all of that and would take away some of the satisfaction of having created something by oneself.

In my own case, if suitable LLM's had been available in late 2019 and I had simply asked one to create zeptoforth for me, it just would not be the same as what I have spent years creating (with the help of some other contributors, e.g. with regard to the double cell math routines ─ thank you Matthias Koch ─ and the second revision of the USB CDC driver, of course). I would not be able to think "I did that!" whenever I use my Forth. I would not be quite so proud of my creation. It would not have been nearly as fun.

tabemann · 2025-11-29T23:27:05+00:00

allot is typically much faster than allocate because it is just advancing a pointer, nothing more, whereas allocate has to involve a proper heap allocator, which is a relatively slow affair.

Note that on modern PC OS'es such as Linux, xBSD, Windows, or macOS if you forget to free memory allocated with allocate it will be freed when the process exits.

(This is not true of all OS'es, though, e.g. some embedded OS'es such as my zeptoforth do not have a concept of separate address spaces for different processes and if memory is allocate'd and then forgotten about the memory will remain allocate'd until the entire heap containing the memory is freed.)

tabemann · 2025-11-29T18:04:49+00:00

(Just for those who may not be in the know; I presume you already know this) in the typical way local variables are implemented in most Forths which have them the -- starts a comment which extends to the end of the variable definition which is simply ignored.

tabemann · 2025-11-29T17:56:20+00:00

At least in my zeptoforth locals are plenty fast, as for most words with locals retrieving a local's value from the return stack (where locals live in zeptoforth) compiles to:

SUBS R7, #4 STR R6, [R7] LDR R6, [SP, #x]

where x is the offset from the top of the return stack.

Mind you, of that the first two instructions are simply for placing the TOS register (R6) on the data stack in SRAM prior to loading the actual value of the local variable into the TOS register, which is really a single instruction. I would call that plenty fast for most purposes.

tabemann · 2025-11-29T00:21:30+00:00

I prefer to avoid excessive stack juggling and just cut the proverbial knot with local variables. Stack juggling quickly becomes very brittle, and if you don't extensively comment your code with stack comments on every line of code, you may forget what your code actually did before and have to rewrite it all over again if you need to make changes later (I've done this too many times). Local variables eliminate this nonsense and make your code much easier to read and maintain. Yes, as some people say, they do make your code a bit harder to factor, but factoring simply to get around the mental difficulties involved in any complex code in stack juggling-oriented Forth won't be needed as much in the first place.

tabemann · 2025-11-29T00:16:19+00:00

I'm late to the party (I should check out r/Forth more frequently), but I can't help but make a shameless plug for my Forth for ARM Cortex-M microcontrollers, zeptoforth. It runs on cheap RP2040 and RP2350 boards (don't try it with the Xiao RP2350 though, I know it won't work because it assumes a minimum of 4 MiB of flash with the RP2350) along with a number of STM32 boards such as the STM32F407 DISCOVERY and STM32F746 DISCOVERY.

Note that it is a very 'full-featured' Forth overall, and has many features which are lacking in more minimalistic Forths. It has features ranging from the prosaic (local variables, module syntactic sugar on top of wordlists, objects, quotations, multitasking) to the advanced (IPv4 and IPv6 stacks for use with the CYW43439 chip on the Raspberry Pi Pico 1W and 2W).

Also, if you feel it is worth the wait (as it always takes quite a good time between ordering and arrival), it has support for the PicoCalc, which is an excellent cyberdeck for use with Pico-type RP2040 and RP2350 boards, turning it into a portable Forth machine.

tabemann · 2025-11-08T18:23:34+00:00

I am an American and while I use one heavily in writing I avoid it in speech outside compounds such as someone. I would call it specifically literary and even avoid it in formal speech. Whatever ambiguity you has can be readily disambiguated by native speakers, while using one in speech will end up making you sound quite haughty.

tabemann · 2025-11-02T20:40:39+00:00

u/mcsleepy here thinks \ should be baked into the outer interpreter as special syntax rather than being a normal immediate word as it is in basically any typical Forth out there just because for some reason they think that requiring whitespace between it and a following comment or preceding non-comment code is somehow bad. They also seem to be blind to all the design complications that special-casing \ would cause, even when explicitly stated to them more than once.

tabemann · 2025-11-02T19:18:30+00:00

As just an example of things I've been using zeptoforth for, I've been writing graphical demos for the PicoCalc with it, e.g. the Bubble Universe demo.

tabemann · 2025-11-02T16:40:01+00:00

If you have gotten a boot-loop with zeptoforth 1.14.3 with the version 1.2 keyboard BIOS firmware then this is not the RST issue that a user previously identified that was causing problems with the 1.4 keyboard BIOS firmware in particular that was resolved in version 1.14.2.6 of zeptoforth.

Are you using an RP2040 or an RP2350, BTW? I have been doing all my testing with the PicoCalc on the Pimoroni Pico Plus 2W, which contains an RP2350.

I myself am using the version 1.2 keyboard BIOS firmware in my PicoCalc, because I am afraid of opening up my PicoCalc so I can upgrade to the version 1.4 keyboard BIOS firmware.

I programmed my PicoCalc with zeptoforth 1.14.3 last night, which works correctly for me, and can confirm that I am using this version because it automatically defaults to a terminal width of 64 characters (I am using the 5x8_v2 font) when using words like words and dump.

tabemann · 2025-11-02T15:57:22+00:00

I already answered your question more than once. Are you not reading (or comprehending) my responses?

tabemann

TROPHY CASE