Proposal: Using FORTH instead of the VM makes MicroBlocks from a teaching toy to a real tool.

[Riceball LEE]

The FORTH language is widely used in embedded systems because of its simplicity and efficiency, and you can find ported FORTH systems in almost any embedded chips.

• Capacity to get and access the bitfield of the MCU‘s registers live.
• Interactivity, that alone is so unique, nothing more gratifying than trouble shooting on every ”word” you
  are creating. Think of it as live function calling and seen the result of that as you add them to your program.
• ITC(Indirect Threaded Code) is a fundamental value to embedded systems, been able to change a word (think of
  this of live changing a function of the code) and immediately seen the results this is quite unique, and if
  properly implemented, you can do minimal OTA near live upgrades, you don‘t re flash and reboot the MCU, you
  just update/compile the code for those changes.

Refs

• FlashForth - a Forth stamp system implemented on the Microchip 8-bit PIC18F and 16-bit PIC24, 30, 33 and the Atmel Atmega microcontroller families. FlashForth also works on the popular Arduino UNO and MEGA boards.
• Mecrisp - A family of optimising native code Forth implementations for MSP430, ARM Cortex M, RISC-V RV32IM(C), MIPS M4K, FPGAs etc.
• FORTH Systems Overview(Sorted by Target)

‌

[John Maloney]

FORTH is a nice language for microcontrollers since it is tiny and gives you access to hardware registers. However,I doubt that a MicroBlocks VM written in FORTH would be any faster or more memory efficient than the current VM written in C/C++,

This is not something we have the resources to explore, but if anyone does port the MicroBlocks VM to FORTH I'd be curious to know how it comes out. The source code for the MicroBlock VM is all in the vm folder of this repository.

[Riceball LEE]

@John_Marion FORTH is closer ASM. Forth is both an extensible language and a realtime interactive program development methodology. I feel like FORTH and Microblocks are a very good fit. Each block means a FORTH word. Multiple blocks form a new word. You can interact with new words immediately.

As a language, FORTH begins with a powerful set of standard commands(words), then provides the mechanism by which you can define your own commands(words) by terminal communication(UART). The structured process of building definitions upon previous definitions is FORTH's equivalent of high-level coding. Alternatively, words may be defined directly in assembler mnemonics, using FORTH's assembler. All commands are interpreted by the same interpreter and compiled by the same compiler, giving the language tremendous flexibility.

FORTH is fast. High-level FORTH executes faster than other high-level languages and between 20 and 75% slower than
equivalent assembly-language programs, while time-critical code may be written in assembler to run at full processor speed. Without a traditional operating system, FORTH eliminates redundancy and needless run-time error checking.

FORTH compiled code is compact. FORTH applications require less memory than their equivalent assembly-language programs! Written in FORTH, the entire operating system and its standard word set reside in less than 8K bytes. Support for a target application may require less than 1K bytes.

Therefore, there is no need for a compiler and an interpreter, if FORTH is used. The FORTH is very simple and easy to implement.

I have no idea where to start to understand the compilation and interpretation process of micoblocks.

I'm too stupid to understand the codes. It seems that the Chunk like the words of FORTH.

Does the CodeChunkRecord means word definitions here? But it seems to have other uses as well.

OBJ is 32bit integer or a pointer:

• The lowest bit is the flag bit of the integer type. So the actual integer is a signed 31-bit integer.
• 0-4 is boolean. 0 is false, 4 is true. BTW, compareObjects can not compare boolean.

• Complex Type(pointer): the first 32bit int is type flag.

  • StringType flag is 4, so check boolean type first. the string(char *) is in &obj[1].
  • ListType flag is 9. using newObj to allocate mem...

‌

[John Maloney]

You've made a good start at understanding. Yes, a chunk is like a word in FORTH, except that some chunks don't have a name. Those correspond to block and scripts in the scripting area that can be run just by clicking on them.

Your description of how integers, booleans, and dynamically allocated objects (pointers) is correct.

CodeChunkRecords are used to store variable names (used by the decompiler) and other records, as well as chunks, in persistent Flash memory.

You might check out https://wiki.microblocks.fun/virtual_machine for an overview of about how the interpreter works.

You can surely learn some useful things by looking at the MicroBlocks virtual machine, but if your eventual goal is to create a blocks interface to FORTH, you might consider starting with a working FORTH system and making a blocks editor for it, perhaps using Blockly (https://github.com/google/blockly).

[Riceball LEE]

@John_Marion Thanks for your answer and kindness.

I don't want to create a block interface for Forth. IMO, the Forth system is closer to assembly both in terms of performance and readability, and the code is less readable. It's great as a device layer, but it's not very suitable as a high-level language.

With Forth, I would like to solve the following problems encountered in 'MicroBlocks':

1. It should not always be compiled to Flash(flash life is very limited). In interactive test mode, it should run in RAM, or the IDE can control the board remotely.

   • Should be used as a compile option, allowing users to choose the compile mode:

     1. Compile code to Board Flash
     2. Compile code to Board RAM
     3. Compile code for PC and Remote Control Board
     4. Compile code for PC and Simulate Board on PC

2. Able to freely simulate various boards and various sensors on the PC

3. Can optimize and compile the released firmware: only compile the functions and codes used in this project into the firmware

4. Instructions can be dynamically expanded, compiled and loaded on demand

   • The device function is not solidified in the board firmware
   • Operation instructions such as buttonA_op, mbTilt_op, mbDisplay_op should be compiled and loaded to the board according to the device capabilities, and it is allowed to have no such instructions.

These days I spend my spare time looking for suitable FORTH systems. By searching and reading their source codes, I have initially selected two FORTH systems, each with its own advantages and disadvantages:

1. µEForth

   • Advantage:

     1. C language development, easy transplantation and maintenance
     2. minimalist C kernel
     3. The execution mode is ITC(Indirect Threaded Code), which can directly decompile advanced words
     4. Thanks to the various function libraries of PlatformIO, it is easy to develop without knowing the hardware details of the board

   • Disadvantages:

     1. Relatively weak performance
     2. You need to realize the function of compiling to Flash by yourself
     3. Restricted by the PlatformIO library, optimization needs to be recompiled the firmware

2. Mecrisp

   • Advantage:

     1. Fully optimized, strong performance
     2. Can choose to compile to RAM, and compile to Flash
     3. New sensor functions can be added without recompiling the firmware

   • Disadvantages:
     4. Native asm development, troublesome transplantation and maintenance
     5. The execution mode is closest to the STC (Subroutine Threaded Code), which can only be decompiled into assembly code.
     6. You need to use FORTH to write the function library yourself

If you choose Mecrisp, you can take full advantage of the advantages of FORTH: new hardware functions can be expanded without recompiling the firmware; real-time interactive testing does not require a compiler; performance and storage space are also optimal. But developers are required Very proficient in the board hardware itself. If you add a new board, you must first master the machine language of the board before it can be transplanted.

If you choose µEForth, it means that you can only interact with the IDE in the following ways:

1. Use the full-featured firmware to interact with the board through remote control on the IDE. When the function verification is completed, compile and burn the project firmware.
2. Simulate the operation of the board on the IDE. When the function verification is completed, compile and burn the project firmware.

From the perspective of maintainability and development difficulty, µEForth is the best choice. I still feel a little bit reluctant to Mecrisp, which is the best optimized Forth system I have ever seen.

Going back to MicroBlocks, MicroBlocks gives me the direct feeling that it makes the development of embedded devices easier and more intuitive, and enables instant interactive testing. This can be said to be a big step forward in the development of embedded devices.
So why can't MicroBlocks become a new tool for developing embedded devices? In the future, unit tests can even be generated in such a visual and automated way.

Compared with FORTH, MicroBlocks' VM includes more functions. For example, FORTH has built-in serial communication (text shell) for interaction: define new functions (words), run specified functions (words), and return results.

Therefore, MicroBlocks and even GPBlocks can be simplified to better focus on visualization and optimize GP syntax. The only thing that needs to be done is to continue to improve the binary serial communication protocol and let FORTH use the binary serial communication protocol instead of the text protocol. .

However, due to the lack of internal implementation documents of MicroBlocks and GPBlocks, and my understanding of GPBlocks is not enough, and my free time is limited, my progress will be very slow.