{"id":23344288,"url":"https://github.com/ttsiodras/miniforth","last_synced_at":"2025-04-10T02:32:41.384Z","repository":{"id":40265739,"uuid":"380595296","full_name":"ttsiodras/MiniForth","owner":"ttsiodras","description":"A tiny Forth I built in a week. Blog post: https://www.thanassis.space/miniforth.html","archived":false,"fork":false,"pushed_at":"2021-12-07T16:50:27.000Z","size":724,"stargazers_count":93,"open_issues_count":0,"forks_count":8,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-03-24T04:03:52.912Z","etag":null,"topics":["arduino","cpp","forth"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ttsiodras.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-06-26T21:00:44.000Z","updated_at":"2025-03-11T17:34:43.000Z","dependencies_parsed_at":"2022-07-24T18:02:30.061Z","dependency_job_id":null,"html_url":"https://github.com/ttsiodras/MiniForth","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ttsiodras%2FMiniForth","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ttsiodras%2FMiniForth/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ttsiodras%2FMiniForth/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ttsiodras%2FMiniForth/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ttsiodras","download_url":"https://codeload.github.com/ttsiodras/MiniForth/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248144290,"owners_count":21054902,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["arduino","cpp","forth"],"created_at":"2024-12-21T06:26:12.697Z","updated_at":"2025-04-10T02:32:41.367Z","avatar_url":"https://github.com/ttsiodras.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"\n*( Wrote [a blog post about this here](https://www.thanassis.space/miniforth.html) )*\n\nIt was raining hard, a week ago.\n\nAnd what could you possibly do on a rainy Saturday afternoon?\n\nWell...\n\nYou can make a Forth interpreter/compiler from scratch...  \n...then put it inside a 1.5$ Blue Pill microcontroller...  \n...and finally, inside an Arduino UNO...  \n... within its tiny 2K RAM!\n\nClick on the image to watch it blinking the LED of my Arduino:\n\n[![Here's a video of it action, blinking my Arduino :-)](https://img.youtube.com/vi/xePollbCzow/0.jpg)](https://www.youtube.com/watch?v=xePollbCzow)\n\nI haven't done anything even *remotely* close to this in decades...  \nI *loved* building it.\n\nThe rainy afternoon turned into a week-long hackfest *(was looking\nforward every day to the post-work FORTH-tinkering in the afternoon...)*\n\nThe result: a tiny, mini, micro Forth. In portable C++ :-)\u003cbr\u003e\nIt has...\n\n- basic arithmetic\n- star-slash (double-word accurate muldiv)\n- literals\n- constants\n- variables\n- direct memory access\n- string printing\n- reseting\n- comments\n- nested DO/LOOP\n- comparisons\n- nested IF/ELSE/THEN\n- ...and of course, functions (Forth words)\n\nHere's an ascii-cast recording of it in action:\n\n[![Recording of building and uploading on an Arduino UNO](https://asciinema.org/a/423649.svg)](https://asciinema.org/a/423649?autoplay=1)\n\nRead the test scenario below to see my supported Forth constructs.\n\n# Portability, ArduinoSTL and Valgrind/AddressSanitizer checks\n\nI meant it when I said \"portable\". Part of my reasoning was, that\nin addition to targeting multiple platforms (e.g. BluePill and\nArduino) I wanted to be able to use Valgrind and AddressSanitizer\nto detect - in the host! - any issues I have with my memory handling. \n\nSince I had embedded targets in mind, I tried ArduinoSTL - but it was too\nwasteful memory-wise. It also made the build process significantly slower.\nI therefore built my own [memory pool, as well as list, tuple and string-like\nC++ templates](https://github.com/ttsiodras/MiniForth/tree/master/src/mini_stl.h). It was a nice challenge, re-inventing a tiny C++ STL...  \n\nAnd I understand STL a lot better now, after building small pieces of it myself :-)\n\n# Simulation / Debugging\n\nI setup simulation via [simavr](https://github.com/buserror/simavr.git).\nThis tremendously improved my developing speed, since a simulator\nspawns and runs much faster than the real board. Due to the code\nbeing portable, debugging took place mostly in the host GDB;\nand after Valgrind and AddressSanitizer gave their blessing, I usually\nfound out that the simulator (and the real board) worked fine as well.\n\n# BluePill vs Arduino UNO\n\nThanks to ArduinoSTL, I quickly reached the point of running inside the\nBluePill. The 1.5$ mini-monster has 10 times more SRAM than an Arduino UNO;\nso in a couple of days, I had a [working branch](https://github.com/ttsiodras/MiniForth/tree/BluePill-STM32F103C).\n\n![The 1.5$ 'Beast'](contrib/BluePill.jpg \"The 1.5$ 'Beast'\")\n\nBut as said above, that wasn't nearly enough to make it work in my\nArduino UNO. That required far more work *(see below)*.\n\nAs for the BluePill, I should note that, as in all my other embedded targets,\nI prefer a development workflow that is based on normal bootloaders\n*(not on programmers)*.  I therefore burned the\n[stm32duino](https://github.com/rogerclarkmelbourne/STM32duino-bootloader)\nbootloader on the BluePill, which allowed me to easily program it\nin subsequent iterations via the USB connection (and a simple `make upload`).\n\nThe same USB connection would then function as a serial port immediately\nafterwards - allowing me to interact with the newly uploaded Forth in the\nBluePill.\n\nThe screenshot below is from a `tmux`: on the left, the output from `make upload`;\nand on the right, I used `picocom` to interact with my mini-Forth\nover the serial port:\n\n![Compiling, uploading and testing](contrib/itworks.jpg \"Compiling, uploading and testing\")\n\n# Memory - the final frontier\n\nThat covered the first two days.\n\nBut when I tried compiling for the Arduino UNO, I realised that the ArduinoSTL\nwas not enough. I run out of memory...\n\nSo I built my own [mini-STL](https://github.com/ttsiodras/MiniForth/tree/master/src/mini_stl.h),\nand tightly controlled *all* memory utilisation.\n\nI also used macro-magic to move all strings to Flash at compile-time\n(see `dprintf` in the code)... And saved memory everywhere I could,\nre-using error messages across various operations - and storing the\nentire array of native operations in Flash.\n\nNothing flexes your coding muscles as much as optimising; whether it is\nfor speed or for space. See the implementation of \".S\" for example,\nwhere the (obvious) stack reversal code is also the most wasteful...\nChanging it to a slower but memory-preserving algorithm allowed me\nto use \".S\" even when almost all my memory is full.\n\n# C++ vs C\n\nI know that many developers hate C++. I even wrote a\n[blog post](https://www.thanassis.space/cpp.html) about it.\n\nAnd I understand why - they see code like this...\n\n    #include \"mini_stl.h\"\n    \n    template\u003cclass T\u003e\n    typename forward_list\u003cT\u003e::box *forward_list\u003cT\u003e::_freeList = NULL;\n    \n...and they start screaming - \"what the hell is that\", \"incomprehensible\nmadness\", etc.\n\nBut there are very important benefits in using C++ - and templates \nin particular. You write less code, with no additional run-time or\nmemory overhead compared to C, and with a lot more compile-time checks\nthat watch your back (for things that would otherwise blow up in your face).\n\nSee my Optional\u003cT\u003e for example, that emulates (badly) the optional\ntype of Rust/OCaml/F#/Scala/Kotlin etc. It **forces** you to check\nyour returned error codes:\n\n    Optional\u003cint\u003e Forth::needs_a_number(const __FlashStringHelper *msg)\n    {\n        if (_stack.empty())\n            return error(emptyMsgFlash, msg);\n        auto topVal = *_stack.begin();\n        if (topVal._kind == StackNode::LIT)\n            return topVal._u.intVal;\n        else\n            return FAILURE;\n    }\n\nYou can't \"forget\" to check the potential for a failure coded inside \nyour returned value - because your code has to \"unwrap\" it. I could have\ndone this better, but I chose to implement it via simple tuples\n(this was a one-weeks-afternoons hack, after all :-)\n\nAs for the template \"magic\" incantation above - it *is* true magic: My\n`forward_list` template is using free-lists to store the `pop_front`-ed\nelements and reuse them in subsequent allocations. I wanted these free-lists to\nbe global (i.e. static members) because lists of the same type must re-use a\nsingle, commonly-shared free-list. The magic spell tells the compiler I want to\ninstantiate these globals *once*, for each type T that I use in any \nlists in my code.\n\n# My Forth test scenario - including a FizzBuzz!\n\nYep, FizzBuzz - we are fully Turing complete. And would surely pass\nJoel's interview :-)\n\n    .\" Reset... \" RESET\n    .\" Check comments... \" \\ Yes, we support the new-style comments :-)\n    .\" Computing simple addition of 3 + 4... \" 3 4 + .\n    .\" Is 1 = 2 ?... \" 1 2 = .\n    .\" Is 1 \u003e 2 ?... \" 1 2 \u003e .\n    .\" Is 1 \u003c 2 ?... \" 1 2 \u003c .\n    .\" Define pi at double-word precision... \" : pi 355 113 */ ;\n    .\" Use definition to compute 10K times PI... \" 10000 pi .\n    .\" Check: 23 mod 7... \" 23 7 MOD .\n    .\" Defining 1st level function1... \" : x2 2 * ;\n    .\" Defining 1st level function2... \" : p4 4 + ;\n    .\" 2nd level word using both - must print 24... \" 10 x2 p4 . \n    .\" Defining a variable with value 123... \" 123 variable ot3\n    .\" Printing variable's value... \" ot3 @ .\n    .\" Defining The Constant (TM)... \" 42 constant lifeUniverse\n    .\" Printing The Constant (TM)... \" lifeUniverse .\n    .\" Setting the variable to The Constant (TM)... \" lifeUniverse ot3 !\n    .\" Printing variable's value... \" ot3 @ .\n    .\" Setting the variable to hex 0x11... \" $11 ot3 !\n    .\" Printing variable's value... \" ot3 @ .\n    .\" Setting the variable to binary 10100101... \" %10100101 ot3 !\n    .\" Printing variable's value... \" ot3 @ .\n    .\" Defining helper... \" : p5 5 U.R . ;\n    .\" Defining 3 times loop... \" : x3lp 3 0 DO I p5 LOOP ;\n    .\" Calling loop... \" x3lp\n    .\" Defining loop calling loop 2 times... \" : x6lp 2 0 DO x3lp LOOP ;\n    .\" Nested-looping 2x3 times... \" x6lp\n    .\" Inline: \" : m 3 1 DO 3 1 DO CR J p5 I p5 .\" = \" J I * p5 LOOP LOOP ;\n    .\" Use inline loops with two indexes... \" m\n    .\" Make multiples of 7 via DUP... \" : m7s 10 0 DO DUP I * . LOOP DROP ;\n    .\" Print them and DROP the 7... \" 7 m7s\n    .\" Reset... \" RESET\n    \\ Time for Turing completeness...\n    .\" Let's do Fizz-Buzz! \" \\ Turing Completeness check...\n    \\ fizz ( n -- 0_or_1 n )\n    .\" Define fizz... \" : fizz DUP 3 MOD 0 = IF .\" fizz \" 1 ELSE 0 THEN SWAP ;\n    \\ buzz ( n -- 0_or_1 n )\n    .\" Define buzz... \" : buzz DUP 5 MOD 0 = IF .\" buzz \" 1 ELSE 0 THEN SWAP ;\n    \\ emitNum ( 0_or_1 0_or_1 n -- )\n    .\" Define emitNum... \" : emitNum ROT ROT + 0 = if . ELSE DROP THEN ;\n    \\ mainloop ( n -- )\n    .\" Define mainloop... \" : mainloop .\" ( \" fizz buzz emitNum .\" ) \" ;\n    \\ fb ( -- )\n    .\" Define fizzbuzz... \" : fb 37 1 DO I mainloop LOOP ;\n    .\" Run it! \" fb\n    .\" Report memory usage... \" .S\n    .\" All done! \"\n\n# Automation\n\nI am a strong believer in automation. The final form of my `Makefile`\ntherefore has many rules - e.g. `make arduino-sim` - that automate\nvarious parts of the workflow.\n\nHere's what they do:\n\n- **arduino**: Compiles the code for Arduino UNO - builds `src/tmp/myforth.ino.{elf,hex}`\n\n- **arduino-sim**: After building, launches the compiled mini-Forth in `simduino`.\n\n- **upload**: After building, uploads to an Arduino attached to the port\n\t      configured inside `config.mk`.\n\n- **terminal**: After uploading, launches a `picocom` terminal with\n\t        all appropriate settings to interact with my Forth.\n\n- **x86**: Builds for x86. Actually, should easily build for any native target (ARM, etc).\n\n- **test-address-sanitizer**: Uses the x86 binary to test the code, executing\n\tall steps of the scenario shown above. The binary is built with the\n\taddress sanitizer enabled (to detect memory issues).\n\n- **test-valgrind**: Same, but with Valgrind.\n\n- **test-simulator**: Spawns `simavr` and sends the entire test scenario shown\n\t              above to it - while showing the responses received from it.\n\n- **test-arduino**: Sends the entire test scenario shown above to an\n\t            Arduino Uno connected to the port specified in `config.mk`\n\t            and shows the responses received over that serial port.\n\n- **blink-arduino**: Sends the \"hello word\" of the HW world: a tiny\n\t             [Forth program](testing/blinky.fs) blinking the Arduino's LED.\n\nAnother example of automation - the complete test scenario shown in the \nprevious section, is not just an example in the documentation; it is \nextracted automatically from this README and fed into the Valgrind and\nAddressSanitizer tests... and also into the Python testing script that\nsends the data to the board in real-time.\n\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself), folks.\n\n# Conclusion\n\nI thoroughly enjoyed building this. I know full well that Forths are not\nsupposed to be built in C++; they are supposed to be built in assembly,\nand also, utilise the Flash to store the user-compiled code at run-time.\n\nBut that wasn't the point of this - the point was to have fun and learn Forth.  \nAnd what better way to learn a language than to actually implement it! :-)\n\nAnd... as a child of the 80s...  I now know first-hand what\n[Jupiter Ace](https://en.wikipedia.org/wiki/Jupiter_Ace) was about :-)\n\nFork the code, and enjoy tinkering with it!  \nThanassis.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fttsiodras%2Fminiforth","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fttsiodras%2Fminiforth","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fttsiodras%2Fminiforth/lists"}