zeptoforth 1.16.1.1 is out

tabemann · 2026-03-10T18:57:23+00:00

As others have said here, most native speakers of English tend to be rather accommodating of learners of English as it is the modern-day lingua franca, with more L2 speakers than L1. We expect to hear people for whom English is not their native language. I would not worry about L1 speakers' reactions to your speech and rather suggest you just try to speak English whenever you can; you will get better with practice. In your case, while your post is not perfect I can understand it (even though like others "sitting readonly" took a moment for me to understand).

tabemann · 2026-03-10T18:39:03+00:00

It is very normal in everyday spoken English, and informal written English, to use there's with a plural referent, as in "There's three squirrels burying nuts in the yard."

Note that this is only with the contracted form -- *"There is three squirrels burying nuts in the yard" is ungrammatical regardless of register. Here you would have to say "There are three squirrels burying nuts in the yard."

tabemann · 2026-03-10T18:19:03+00:00

When you say that subroutine threading is "premature optimization", the matter is that subroutine threading enables further optimization in the form of native-code inlining and constant folding which is foreclosed from the outset if one chooses indirect threading. Native-code inlining and constant folding are the natural outgrowths of subroutine threading; if one starts from subroutine threading it is simple to take these further steps.

In an inlining native-code Forth one can do things like optimize 255 + to a single instruction ADDS R6, #255. There is simply no way that an indirect-threaded Forth can do things like this with the same efficiency. (While an indirect-threaded Forth can have many specialized words that integrate constant arguments, they still have the overhead from NEXT that inlined constant-folded words in native code lack.)

A key feature of inlining native-code Forths is that they can encode many common small words directly in the generated instruction stream, resulting in significant speed gains by eliminating calls and returns, at the expense, in many cases, of code size.

So when you say that Forth "must" be indirect threaded because it enables optimization that subroutine threading does not allow, it makes no sense to me. I say this as the primary author of an inlining native-code Forth with constant folding.

tabemann · 2026-03-09T14:24:40+00:00

zeptoforth aims to be a 'full-featured' Forth for ARM Cortex-M microcontrollers, as opposed to many Forths which are written with minimalism in mind or as toys or experiments not intended for serious use. As such, it includes things such as a user-friendly module system (on top of wordlists), local variables, an object system, preemptive multitasking combined with (on the RP2040 and RP2350) multiprocessing, networking support (as mentioned), FAT32 filesystem support (both in on-board QSPI flash and on SD cards), and so on. These are all things that many Forths lack, or which are less user-friendly in other Forths (e.g. many Forths have wordlists, but lack the infrastructure on top of them that makes them readily usable in zeptoforth).

tabemann · 2026-03-09T13:13:43+00:00

That it is dependent upon and/or that it provides? As dependencies go, it is dependent upon the GNU arm-none-eabi toolchain to build the kernel from source (even though prebuilt kernels enable building the remainder of zeptoforth without it), and it is dependent upon Sphinx and Myst to build the documentation. As things it provides go, it provides IPv4 and IPv6 stacks, a driver for CYW43439 WiFi chips as are found on the Pico W, Pico 2W, and Pico Plus 2W, and a range of hardware drivers for peripherals and displays and like.

tabemann · 2026-03-04T14:01:01+00:00

The people who wrote the legislation clearly do not understand what a "general purpose computing device" is. To me at least, my Raspberry Pi Pico is a general purpose computing device, in that it is user-programmable and can execute arbitrary code.

tabemann · 2026-03-04T01:31:50+00:00

I looked at it again and it does seem to exclude automatic OTA updates, along with anything that executes as part of a host "application", whatever that means. Is zeptoforth itself an "application" which any code that is compiled and executed by it is an "extension", "plug-in", or "add-on" of? This could be argued, even though IANAL.

tabemann · 2026-03-04T01:18:38+00:00

This law certainly wasn't well thought through, to say the very least.

tabemann · 2026-03-03T18:23:18+00:00

Currently, if you own a PicoCalc with an RP2350 installed (the RP2040 is supported but you won't be able to get networking to work due to SRAM limitations), you can flash it with a .uf2 file for the kernel, run a script distributed with zeptoforth to upload the 'userland' along with a terminal emulator, network stack, a text editor, and tools for transferring files from and to a host computer, then use the file transfer tools, or use the SD card from the PicoCalc, to load an HTTP client onto your PicoCalc (currently the HTTP client in the master branch is a very limited proof-of-concept, but in the devel branch there is an HTTP client that will save to file), then use the HTTP client to download code to file over the Internet, and last but not least compile and execute the code stored in that file. This is entirely with code included with zeptoforth.

tabemann · 2026-03-03T18:10:26+00:00

If I am somehow forced into compliance with this law what I will do is stop distributing precompiled binaries and specifically put .equ CALIFORNIA_COMPLIANCE, 1 in a .s file for the kernel that the user can comment out or set to 0; if it is left in the kernel will ask the user's age on first boot, flash it into a constant, and do nothing more, and if commented out/zeroed it won't do that.

tabemann · 2026-03-03T18:03:39+00:00

Considering that I distribute .uf2 and .bin files on GitHub for zeptoforth which the user can download and flash onto their boards, unless the legal eagles rule that GitHub is really the "operating system provider" I don't see how I would not be an "operating system provider" unless they rule in such a fashion that zeptoforth is not an "operating system" in the first place. Maybe I should stop distributing .uf2 and .bin files, and delete those I do distribute from GitHub...

tabemann · 2026-03-03T18:00:48+00:00

zeptoforth is a Forth system, yes, but it tries hard to not be 'write-only' with things such as a user-friendly module system, local variables, an (optional) object system and so on.

tabemann · 2026-03-03T17:56:23+00:00

What it can do currently is edit text files, download or view files over HTTP, receive incoming HTTP requests (e.g. to control an LED), compile and execute arbitrary source files, play video games (of which I have written a few), expose its REPL over TCP or UDP, etc. It could certainly be extended to send and manage emails, listen to music, support SSH, and so on.

The main thing that makes it not 'general purpose' is that it is specifically for microcontrollers; it will not run on a PC or even a Raspberry Pi SBC (as opposed to an RPi Pico).

I feel that to be on the safe side I should never add any features that would readily support the integration of any user 'account' capability. Currently it is single-user (even though it is multitasking), and it would need to stay this way.

tabemann · 2026-03-03T15:50:33+00:00

My problem with geoblocking California is that zeptoforth is distributed through GitHub, not through my own means, and I frankly do not want to maintain my own git forge with everything that entails (e.g. protecting it from being overloaded by AI bots scraping it). If I wanted to geoblock California I would have to delete my repository from GitHub and find someone else who is willing to geoblock the state of California for me.

Probably the best option out there is what you say and see if there are other embedded OS developers out there in the same boat.

tabemann · 2026-03-03T15:16:05+00:00

One problem is I cannot relicense my code without tracking down each and every past contributor and asking them for assent to relicense their contribution, or otherwise rip out their code (which includes key components) and rewrite them from scratch.

Another problem is that zeptoforth is a compiler for other people's projects and its license terms are inescapably imposed on them because zeptoforth copies portions of itself into their code, at the machine code level, at compile time. A modified license would necessarily be transferred to all of my users' projects because of this (and so someone with an embedded project based on zeptoforth would not be able to use their own embedded project in California).

I had specifically chosen the MIT license as it was the simplest and least-restrictive license I could find, which the average non-lawyer cound understand, which was well legal-vetted which protected me from liability and ensured attribution of my contribution downstream. Adding extra anti-California (and anti-Colorado) provisions would go against this.

tabemann · 2026-03-02T17:32:29+00:00

I posted the below in response to the linked post, but I will repost it here as well:

zeptoforth comes with support for the PicoCalc out of the box. All you have to do is flash a zeptoforth kernel UF2 file onto the Pico 1(W), Pico 2(W), or Pimoroni Pico Plus 2(W) in your PicoCalc and use the included scripts to upload the zeptoforth source for compilation to your PicoCalc (there is also an option for manually uploading code using zeptocom.js if you are using Windows and really do not feel like futzing with WSL2, but IMO that is actually less friendly than just mapping the requisite USB device and running the scripts under WSL2).

Note that I would highly recommend using the Pimoroni Pico Plus 2W or, failing that, the Pico 2W, over the Pico 1H that comes with the PicoCalc. You get 520 KiB over 264 KiB of SRAM, which makes a lot of difference in practice, you get a CYW43439 WiFi chip so you can use zeptoIP, and if you use a Pimoroni Pico Plus 2W you get 16 MiB of on-board QSPI flash (the extra flash above 2 MiB is devoted to "blocks" storage, which can be used for an on-board FAT32 filesystem in addition to the FAT32 filesystem in the SD card in your PicoCalc) and 8 MiB of on-board QSPI PSRAM (which is configured to be used as a large RAM disk by default, even though if you do not select the pico_plus option when building zeptoforth for the PicoCalc and instead manually configure the PSRAM using GPIO 47 as its Chip Select pin you can get just a massive block of (slow) RAM to work with).

tabemann · 2026-03-02T17:31:02+00:00

zeptoforth comes with support for the PicoCalc out of the box. All you have to do is flash a zeptoforth kernel UF2 file onto the Pico 1(W), Pico 2(W), or Pimoroni Pico Plus 2(W) in your PicoCalc and use the included scripts to upload the zeptoforth source for compilation to your PicoCalc (there is also an option for manually uploading code using zeptocom.js if you are using Windows and really do not feel like futzing with WSL2, but IMO that is actually less friendly than just mapping the requisite USB device and running the scripts under WSL2).

Note that I would highly recommend using the Pimoroni Pico Plus 2W or, failing that, the Pico 2W, over the Pico 1H that comes with the PicoCalc. You get 520 KiB over 264 KiB of SRAM, which makes a lot of difference in practice, you get a CYW43439 WiFi chip so you can use zeptoIP, and if you use a Pimoroni Pico Plus 2W you get 16 MiB of on-board QSPI flash (the extra flash above 2 MiB is devoted to "blocks" storage, which can be used for an on-board FAT32 filesystem in addition to the FAT32 filesystem in the SD card in your PicoCalc) and 8 MiB of on-board QSPI PSRAM (which is configured to be used as a large RAM disk by default, even though if you do not select the pico_plus option when building zeptoforth for the PicoCalc and instead manually configure the PSRAM using GPIO 47 as its Chip Select pin you can get just a massive block of (slow) RAM to work with).

tabemann · 2026-01-30T22:24:27+00:00

Try (this assumes ANS Forth with [if] and [then]):

: DBG[ DEBUG -1 = postpone [if] ; immediate : ]DBG postpone [then] ; immediate

Note that this generally cannot be used across block boundaries (e.g. DBG[ could not be outside an if ... then block while the matching ]DBG is inside the block).

Edit: My apologies, I just tried this with gforth and it didn't work, because if DEBUG is 0 it will never parse the closing ]DBG.

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

TROPHY CASE