Overview of maintained, free Forths for single board computers

[Klapaucius Klapaucius]

I'm trying to make up my mind whether to spend some time with forth on more recent SBCs like the MicroBit, ESP32s, RiscV boards etc. I've done a bit of work with Micropython, but would not mind getting some work done in Forth.

It's not easy, using Google, to get a good overview of what's out there, and whether particular implementations are maintained and free to use. I don't mind doing a bit of porting, but I'd prefer to have a native implementation, and I'd really like to use the network. Luckily, many of the SBCs have some RTOS version that I would think makes networking a bit easier, but OTOH, I haven't found any freely available forth network stacks.

This one: https://github.com/organix/pijFORTHos looks pretty promising.
Looks like mecrisp is also active and pretty portable.

I wouldn't mind doing a little bit of porting, and I don't particularly care for standards compliance.

If there are good writeups or summaries that I can/should read, I'd really appreciate pointers.

I can compose a digest of the responses if there is interest.

[Paul Rubin]

Klapaucius Klapaucius <klapa...@gmail.com> writes:
> It's not easy, using Google, to get a good overview of what's out
> there, and whether particular implementations are maintained

The Forthfreak wiki is unfortunately defunct. The old content is
mirrored on github somewhere, so it is not lost, but it's no longer so
easy for random people to update.

http://forth.org/software.html is another good location where this type
of info could live, but it is not easily editable either, and isn't
maintained much, it looks to me.

https://en.wikibooks.org/wiki/Forth might be a good place to park the
info, so people could update it as desired.

[Lorem Ipsum]

Mecrisp is already ported to a large number of targets, both types of CPUs and individual boards.

It is always the information on finding and using the various forths that is lacking. Mecrisp has something to work with at least. I would have hoped that Matthias Koch would have posted his info here, but I think he found this group to be a bit too popular with those who simply enjoy arguing.

I'm pretty sure it is ported to the ESP32, the RISC-V and even the FPGA hosted J1 processor by James Bowman.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[dxforth]

On 22/10/2022 12:41 pm, Lorem Ipsum wrote:
> On Friday, October 21, 2022 at 5:40:51 PM UTC-4, Klapaucius Klapaucius wrote:
>> I'm trying to make up my mind whether to spend some time with forth on more recent SBCs like the MicroBit, ESP32s, RiscV boards etc. I've done a bit of work with Micropython, but would not mind getting some work done in Forth.
>>
>> It's not easy, using Google, to get a good overview of what's out there, and whether particular implementations are maintained and free to use. I don't mind doing a bit of porting, but I'd prefer to have a native implementation, and I'd really like to use the network. Luckily, many of the SBCs have some RTOS version that I would think makes networking a bit easier, but OTOH, I haven't found any freely available forth network stacks.
>>
>> This one: https://github.com/organix/pijFORTHos looks pretty promising.
>> Looks like mecrisp is also active and pretty portable.
>>
>> I wouldn't mind doing a little bit of porting, and I don't particularly care for standards compliance.
>>
>> If there are good writeups or summaries that I can/should read, I'd really appreciate pointers.
>>
>> I can compose a digest of the responses if there is interest.
>
> Mecrisp is already ported to a large number of targets, both types of CPUs and individual boards.
>
> It is always the information on finding and using the various forths that is lacking. Mecrisp has something to work with at least. I would have hoped that Matthias Koch would have posted his info here, but I think he found this group to be a bit too popular with those who simply enjoy arguing.

I think it's the other way around. He only needs to post an update because the
group is more than capable of answering anyone who comes here asking 'what forth
is available for XYZ'.

[Paul Rubin]

Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> Mecrisp is already ported to a large number of targets, both types of

> CPUs and individual boards.... I'm pretty sure it is ported to the

> ESP32, the RISC-V and even the FPGA hosted J1 processor by James
> Bowman.

https://mecrisp.sourceforge.net/

MSP430 (original version), Stellaris (ARM Cortex) a rewrite, Quintus
(Risc-V) another rewrite, and J1 (Swapforth, whatever that is, but looks
related to the MSP430 version. I don't see anything about ESP32.

It is a very capable Forth with an optimizing compiler, but it is
written mostly in assembly language rather than in Forth. So targeting
it to a different architecture takes a lot of rewriting. I would be
interested to know why Matthias did it that way, since Forth is
traditionally written in itself.

ESP32 (Xtensa) is similar enough to RISC-V that maybe an Xtensa target
would be easier to write than a totally new target. On the other hand,
Espressif seems to be moving away from the Xtensa architecture, and
instead using RISC-V in its more recent parts. So if you want to use
Mecrisp on an ESP32, you can choose from the models that use RISC-V.
Several of those are already available, and future models seem likely to
use it.

[Lorem Ipsum]

https://mecrisp-stellaris-folkdoc.sourceforge.io/new-projects.html

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[dxforth]

On 23/10/2022 7:50 am, Paul Rubin wrote:
> ...

> MSP430 (original version), Stellaris (ARM Cortex) a rewrite, Quintus
> (Risc-V) another rewrite, and J1 (Swapforth, whatever that is, but looks
> related to the MSP430 version. I don't see anything about ESP32.
>
> It is a very capable Forth with an optimizing compiler, but it is
> written mostly in assembly language rather than in Forth. So targeting
> it to a different architecture takes a lot of rewriting. I would be
> interested to know why Matthias did it that way, since Forth is
> traditionally written in itself.

Don't know but kernels written in forth usually require a metacompiler
which adds another level of complication.

[Paul Rubin]

Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> https://mecrisp-stellaris-folkdoc.sourceforge.io/new-projects.html

Oh, nice page. I see a mention there of "ESP32-C3 SVD2FORTH-V3". Note
that ESP32-C3 uses a RISC-V core, not the Xtensa core used in the
original ESP32 and some other models.

[Jos Ven]

Op vrijdag 21 oktober 2022 om 23:40:51 UTC+2 schreef Klapaucius Klapaucius:

Hi,
For the ESP32 and the ESP8266 I use Cforth of Mitch Bradley.
The main advantage is that you can choose to compile Forth-code into flash memory
or into ram memory.
In the latest version an extra serial port can be used.
Its can be downloaded from: https://github.com/Jos-Ven/cforth/tree/WIP
Cforth is multiplatform and runs on a wide range of systems.
Jos

[none albert]

In article <87h6zvf...@nightsong.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>Lorem Ipsum <gnuarm.del...@gmail.com> writes:
>> Mecrisp is already ported to a large number of targets, both types of
>> CPUs and individual boards.... I'm pretty sure it is ported to the
>> ESP32, the RISC-V and even the FPGA hosted J1 processor by James
>> Bowman.
>
>https://mecrisp.sourceforge.net/
>
>MSP430 (original version), Stellaris (ARM Cortex) a rewrite, Quintus
>(Risc-V) another rewrite, and J1 (Swapforth, whatever that is, but looks
>related to the MSP430 version. I don't see anything about ESP32.
>
>It is a very capable Forth with an optimizing compiler, but it is
>written mostly in assembly language rather than in Forth. So targeting
>it to a different architecture takes a lot of rewriting. I would be
>interested to know why Matthias did it that way, since Forth is
>traditionally written in itself.

He could have made the same observation I have. ciforth's are written
in assembler, because since decennia there has been one assembly
language: the i86. (now it is changing). So the main systems
linux, MS-windows and Mac can have the same assembly file for a
host-based ciforth.
Killing the middle man of high level Forth (or worse c) has many advantages.
The ARM version of ciforth had at a certain point problems with the
io space. Using the "politically correct" way of using the
Raspberry c libraries get me nowhere. Now it is implemented in a
one or two variables and one Forth definition.

Mecrisp is available on a truckload of SBC with the same processor.
Relying on compatible c-programming environments on a plethora of
boards is *not* the way to go.

Mecrisp is intended to be a practical system. Speed is essential,
and it is comes cheap. MSP430 assembly language is portable
across hundreds of msp430 boards.


Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Zbig]

> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Completely on a side note: the above link to your site doesn't work anymore
(either no index.html or wrong permissions, probably).

[Paul Rubin]

albert@cherry.(none) (albert) writes:
> Killing the middle man of high level Forth (or worse c) has many
> advantages. The ARM version of ciforth had at a certain point
> problems with the io space. Using the "politically correct" way of
> using the Raspberry c libraries get me nowhere.

Traditionally you'd have a small amount of assembly code, and then high
level Forth. C didn't come into it.

> Mecrisp is intended to be a practical system. Speed is essential,

Mecrisp has an optimizing compiler, so shouldn't that mostly solve the
speed issues of interpreted Forth? We've certainly heard that about
VFX.

And, is the speed of the compiler that important? If not, what does it
say about Forth, if the implementer chooses assembly language over Forth
for writing something as high level and complex as a compiler?

> and it is comes cheap. MSP430 assembly language is portable
> across hundreds of msp430 boards.

I suspect the MSP430 is a minority platform even for Mecrisp these days.
I can understand if the limited code space in the smaller MSP430's made
the assembly code necessary, but the ARM and RISC-V platforms generally
aren't quite so constrained.

OTOH, maybe this is interesting:

https://www.cnx-software.com/2022/10/22/10-cents-ch32v003-risc-v-mcu-offers-2kb-sram-16kb-flash-in-sop8-to-qfn20-packages/

[dxforth]

On 24/10/2022 6:08 am, Paul Rubin wrote:
> albert@cherry.(none) (albert) writes:
>> Killing the middle man of high level Forth (or worse c) has many
>> advantages. The ARM version of ciforth had at a certain point
>> problems with the io space. Using the "politically correct" way of
>> using the Raspberry c libraries get me nowhere.
>
> Traditionally you'd have a small amount of assembly code, and then high
> level Forth. C didn't come into it.
>
>> Mecrisp is intended to be a practical system. Speed is essential,
>
> Mecrisp has an optimizing compiler, so shouldn't that mostly solve the
> speed issues of interpreted Forth? We've certainly heard that about
> VFX.

VFX is a full-blown megabyte development system which can optionally target
compile. Not sure the comparison is valid.

Regarding "small amount of assembly code, and then high level Forth" it
depends on the goal. The following file descriptions come from Bill Muench,
author of eForth:

EFORTH.X86 - eForth source
A simple Forth system for DOS, mostly written in hilevel Forth. eForth
should be considered a model, not a working Forth development system.

EFORTHO.X86 - eForth source optimized
The same word set as EFORTH.X86 but many more routines coded in assembly.

So despite eForth's 'model' status even Bill found 'small amount of assembly
code' problematic. His working development system and target compiler at
this time (1989-1997) was bFORTH - a 30Kb MS-DOS exe.

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> EFORTHO.X86 - eForth source optimized
> The same word set as EFORTH.X86 but many more routines coded in assembly.
>
> So despite eForth's 'model' status even Bill found 'small amount of
> assembly code' problematic. His working development system and target
> compiler at this time (1989-1997) was bFORTH - a 30Kb MS-DOS exe.

Eforth is a pure interpreter whose "model" implementation tried to use a
bare minimum of asm words, at a big cost in speed. Iirc it even
implemented multiplication in Forth. Mecrisp generates native machine
code that probably attempts more optimization than Swiftforth does,
though less than VFX. So it seems odd that the compiler itself is
written mostly in asm, iirc. It is many KLOC of asm code, not a few
optimized functions here and there.

[dxforth]

Flashforth is an optimizing native code compiler that's written in pure asm.
Supports AVR8 and some PICs. Perhaps the authors feel more comfortable - or
feel they can extract more - doing it this way. Portability may be low
priority.

[none albert]

In article <e780cf26-af33-4c92...@googlegroups.com>,

There was a change on hccnet.nl. index.tml had execute permission,
that bothered the security, Now fixed,

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> Flashforth is an optimizing native code compiler that's written in
> pure asm. Supports AVR8 and some PICs. Perhaps the authors feel more
> comfortable - or feel they can extract more - doing it this way.
> Portability may be low priority.

That's interesting, I didn't know that about Flashforth. I thought
Forth was supposed to be easier to program in than asm, besides having
portability advantages. This kind of thing makes me wonder. Forth in
some ways seems like an asm language for a machine with just 2 or 3
registers. A lot of work goes into arranging the instructions to avoid
hitting memory, unlike a machine with more registers to hold
intermediate results. Thanks.

[Stephen Pelc]

On 21 Oct 2022 at 23:40:49 CEST, "Klapaucius Klapaucius"

<klapa...@gmail.com> wrote:
>
> It's not easy, using Google, to get a good overview of what's out there, and
> whether particular implementations are maintained and free to use. I don't
> mind doing a bit of porting, but I'd prefer to have a native implementation,
> and I'd really like to use the network. Luckily, many of the SBCs have some
> RTOS version that I would think makes networking a bit easier, but OTOH, I
> haven't found any freely available forth network stacks.

All MPE products are now available under the community licence - free of
charge for non-commercial use.

The 32 bit cross compilers include TCP/IP and USB stacks.

Stephen

--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612,
+34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[Brian Fox]

On Sunday, October 23, 2022 at 11:20:00 PM UTC-4, Paul Rubin wrote:
> Mecrisp generates native machine
> code that probably attempts more optimization than Swiftforth does,
> though less than VFX. So it seems odd that the compiler itself is
> written mostly in asm, iirc.

I can tell you that my hobby cross-compiler is a neat thing to see and
I find it rewarding to see Forth written in Forth. I even use Forth Assembler.
It is however a rather complicated thing to understand, at least for a
mere mortal like me.
It hinges around a lot of making Forth search different wordlists under
different states so that a given word does a cross-compiling function
instead of what you would expect it to do in a Forth kernel. So this can
be tricky to get right. Once it's working though it's pretty cool.

By comparison an Assembler Forth is pretty much WYSIWYG.
Macros's can hide some ugly header/dictionary creation and judicious
choice of label names makes the code read well.

I know Brad Rodriguez used to maintain his own cross-compiler but
I believe he does not any more. I have never heard why he switched
but I can guess that the ease of using off-the-shelf tools removes one
big layer of headaches and maintenance.
Brad's Camel Forth also has a version written in C now.

Perhaps the real challenge is making a good Forth Assembler for modern
machines. (?) I would need someone else with real experience to weigh in.

[dxforth]

On 25/10/2022 3:19 am, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
>> Flashforth is an optimizing native code compiler that's written in
>> pure asm. Supports AVR8 and some PICs. Perhaps the authors feel more
>> comfortable - or feel they can extract more - doing it this way.
>> Portability may be low priority.
>
> That's interesting, I didn't know that about Flashforth. I thought
> Forth was supposed to be easier to program in than asm, besides having
> portability advantages.

That's certainly true when writing apps. However it's not every day that
one writes a forth kernel. Can you blame a forth developer for wanting to
keep it as small and tight as possible? Here's an example taken from the
Flashforth kernel:

; ... 16 for c@+ 2 h.n space next ...

Were that written in Flashforth it would have compiled to:

rcall DOLIT
.word 16
rcall TOR
rjmp DUMP3
DUMP2:
rcall CFETCHPP
rcall DOLIT
.word 2
rcall HDOTN
call SPACE_
DUMP3:
rcall XNEXT
brcc DUMP2
pop t1
pop t0

Seeing the loop is never entered with count=0, the author saved bytes by
hand-coding it as:

rcall DOLIT
.word 16-1
rcall TOR
DUMP2:
rcall CFETCHPP
rcall DOLIT
.word 2
rcall HDOTN
call SPACE_
rcall XNEXT
brcc DUMP2
pop t1
pop t0

[anti...@math.uni.wroc.pl]

albert <albert@cherry.(none)> wrote:
> In article <87h6zvf...@nightsong.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
> >Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> >> Mecrisp is already ported to a large number of targets, both types of
> >> CPUs and individual boards.... I'm pretty sure it is ported to the
> >> ESP32, the RISC-V and even the FPGA hosted J1 processor by James
> >> Bowman.
> >
> >https://mecrisp.sourceforge.net/
> >
> >MSP430 (original version), Stellaris (ARM Cortex) a rewrite, Quintus
> >(Risc-V) another rewrite, and J1 (Swapforth, whatever that is, but looks
> >related to the MSP430 version. I don't see anything about ESP32.
> >
> >It is a very capable Forth with an optimizing compiler, but it is
> >written mostly in assembly language rather than in Forth. So targeting
> >it to a different architecture takes a lot of rewriting. I would be
> >interested to know why Matthias did it that way, since Forth is
> >traditionally written in itself.
>
> He could have made the same observation I have. ciforth's are written
> in assembler, because since decennia there has been one assembly
> language: the i86. (now it is changing). So the main systems
> linux, MS-windows and Mac can have the same assembly file for a
> host-based ciforth.
> Killing the middle man of high level Forth (or worse c) has many advantages.

What/who is "middle man" depends on point of view. For me assembler
is a middle man. And in case of ciforth "m4". To explain more:
there is bunch of primitives that naturally are written in
assembler. But most of ciforth code is essentially dictionary
content. Forth is capable of managing dictionary, assembler is
for bootstrap. But there are alternative ways of bootstrap,
that you may dislike but folks like myself find much more
appealing.

> Mecrisp is available on a truckload of SBC with the same processor.
> Relying on compatible c-programming environments on a plethora of
> boards is *not* the way to go.

Why not? AFAIK each of them has C compiler and compiler differences
that matter for Forth are due to assembler and machine language,
so one needs to handle them anyway.

> Mecrisp is intended to be a practical system. Speed is essential,
> and it is comes cheap. MSP430 assembly language is portable
> across hundreds of msp430 boards.

Speed of generated code, yes. Speed of compiler, unlikely.
MSP430 MPU tend to be quite small, so you will have small
programs. Relative to size they are quite fast, so moderate
inefficiency in compiler should not be bad. OTOH size matters
a lot for MSP430. One claim to fame of threaded Forth is that
one gets better code density than form assembler, so using
_theread Forth_ to implement compiler would be quite natural.

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

That does _not_ look like output from "optimizing native compiler".
AFAICS this is essentially subroutine threaded code.

--
Waldek Hebisch

[dxforth]

No optimization in that instance - hence the example.

> AFAICS this is essentially subroutine threaded code.

There's a hard and fast definition for what constitutes an "optimizing
native compiler"?

[minf...@arcor.de]

Many hobby Forthers seem to have a rather fundamentalist viewpoint on this.
On a commercial stage costs/time for development and maintenance, and
time to market are dominant factors. This is where C comes in, particularly
when you have to serve different, sometimes incompatible, hardware platforms.
Many manufactures give or sell you precompiled drivers. Nobody reengineers
vendor libraries just to make them more Forthyish. If there are bugs, they are the
vendor's fault, and I always found OEMs speedy and friendly and helpful to iron
things out. Within this context, assembler is only good for micro-optimization.

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
>> AFAICS this is essentially subroutine threaded code.
> There's a hard and fast definition for what constitutes an "optimizing
> native compiler"?

I'd be interested to know how Mecrisp compiles that same Forth code.
The Flashforth output looks almost like a pessimizing compiler. I'd say
a rudimentary compiler just emits machine instructions corresponding to
Forth primitives, pushing and popping stuff onto a stack. An optimizing
compiler makes some effort to collapse out do-nothing sequences like
SWAP SWAP, and a fancier one will cache the top several stack items in
registers so your loop example would look about like a hand-coded asm
version. Mecrisp does that with up to 3 or maybe 5 registers, if I
remember right. I believe VFX has a serious register allocator like a
fancy C compiler would have, that uses the machine's whole register set,
does clever instruction selection, etc.

[dxforth]

Where's the excitement? Using C is like dining out at McDonald's each night.

[none albert]

In article <a4a00ccc-3e6b-4189...@googlegroups.com>,

May I plug ciasdis once more?
It is a framework for making assemblers, and it is easy.
The "de luxe" version has interactive (!) instruction completion
with absolute error detection for 8086, 80386, Pentium, Dec Alpha, 8080,
6809.
The "tear down version" (present in ciforth) has a 32/64 i86
assembler able to handle the same source, in a dozen screens.
(Up till Pentium I )

https://github.com/albertvanderhorst/ciasdis

An example is the disassembly and reassembly of the 32 bit lina 4.0.5
Forth compiler.
This extracts sensible labels from the executable, and the source
switches a zillion times between data and code assembly.

[An example is the disassembly and reassembly of the 64 bit lina 5.3.0
Forth compiler exists but has not been uploaded to github yet.]

Groetjes Albert

[none albert]

In article <tj7get$rp3$1...@gioia.aioe.org>, <anti...@math.uni.wroc.pl> wrote:
>albert <albert@cherry.(none)> wrote:
>> In article <87h6zvf...@nightsong.com>,
>> Paul Rubin <no.e...@nospam.invalid> wrote:

>> Mecrisp is available on a truckload of SBC with the same processor.
>> Relying on compatible c-programming environments on a plethora of
>> boards is *not* the way to go.
>
>Why not? AFAIK each of them has C compiler and compiler differences
>that matter for Forth are due to assembler and machine language,
>so one needs to handle them anyway.

That is not true. There are a plethora of boards and one wants
to real money for a C compiler that has all the interfaces
for interrupts and io on board, if at all present.
Forth is more often than not the first language running on a new computer.
Remember the original Mac?

> Waldek Hebisch

[dxforth]

All that requires resources. Since Mecrisp doesn't support AVR8 it's
hard to compare what the same optimizations would have cost (or benefited).

[Mike]

The FlashForth optimisations for Atmega are fairly simple and not as extensive as in Mecrisp.
FF combines DUP and 0= with the zero check in IF WHILE UNTIL.
It caches the TOS in registers.
A literal followed by + - AND OR are combined to operate on the cached TOS.
And FF does the tail call optimization.
Inlining of position independent short words is done based on the INLINE flag in the word header.

Some more optimisation could be done but it was not worth the effort on the AVR or PIC18.
PIC18 and PIC24 have similar optimization.

The 16-bit PIC24 has a simple peephole optimiser that tries to keep the TOS in a register.

On PIC18 every SRAM position can be used as a ALU so there the stack handling code is quite different
from AVR where you have to load and store before doing an ALU operation.

I see no point in optimising stupid code like SWAP SWAP. The coder can to that with the keyboard.

[Matthias Koch]

I think there are different possible levels of "optimisation" in Forth.

0) Classic subroutine threaded Forth implementations, maybe with inlining of manually flagged or short definitions

1) Do constant folding (Mecrisp-Ice which is a stack machine on FPGA, enhanced fork of J1 design) Note: Constant folding could be also done in threaded Forths.

2) Merge folded constants directly with suitable opcodes, if possible (classic Mecrisp for MSP430, classic Mecrisp-Stellaris, Mecrisp-Quintus without Acrobatics)

3) Do register allocation on basic blocks and automatically inline short definitions using local register set (Mecrisp-Stellaris RA, data stack only due to shortage of CPU registers on M0; Mecrisp-Quintus with Acrobatics, handling both data and return stack)

4) Global optimisation, automatically inline every definition that is used in one place only, dead code elimination starting from the vector table also collapsing control structures based on constant folding results, perform register allocation across control structures and handle variable or unpredictable stack effects gracefully, without canonical fallback (Mecrisp-Across for MSP430)

5+) Loop unrolling, pattern matching of common algorithms, temporary caching of memory contents across multiple ! and @ in registers (This is the realm of GCC. I am not aware of a Forth implementation capable of this, please comment)

It might be an interesting idea for someone to explore using level 4 style optimisations in a Forth that allows traditional incremental compilation, technically performing global optimisation every time based on what is known so far. I think this is what the VFX compiler does internally.

A very simple example to demonstrate register allocation on basic blocks (level 3 as defined here):

Mecrisp-Stellaris RA 2.6.4 for Linux by Matthias Koch
: graycode ( u -- x ) dup 1 rshift xor ; ok.
see graycode
00116B80: 0873 lsrs r3 r6 #1
00116B82: 405E eors r6 r3
00116B84: 4770 bx lr
ok.

Mecrisp-Quintus 1.0.0 for RISC-V RV32IMC Linux by Matthias Koch
Acrobatics - A register allocator for Mecrisp-Quintus
: graycode ( u -- x ) dup 1 rshift xor ; ok.
see graycode
0011472E: 5713 srli x14, x8, 1
00114730: 0014
00114732: 8C39 c.xor x8, x14
00114734: 8082 c.jr x1
ok.

Here is what to expect with global optimisation (level 4):

https://joldosh.blogspot.com/2019/12/optimized-msp430-assembly-in-mecrisp.html

Try your own definitions and SEE generated code!

[Paul Rubin]

Matthias Koch <m.c...@gmx.net> writes:
> I think there are different possible levels of "optimisation" in

> Forth. ...

Matthias, thanks for that informative post. I wonder if you could
comment on what considerations made you decide to write so much of
Mecrisp in assembler instead of Forth? I'm not saying it was a wrong
choice, but rather, I'm asking more about the trade-offs involved.

Here is a new, super cheap RISC-V MCU that might be an interesting
Mecrisp target:

https://www.cnx-software.com/2022/10/22/10-cents-ch32v003-risc-v-mcu-offers-2kb-sram-16kb-flash-in-sop8-to-qfn20-packages/

Note that it implements the RISC-V E (embedded) profile, which has only
16 registers instead of the full 32. I don't know if that stops
Mecrisp-Quintus from working on it.

[Paul Rubin]

Matthias Koch <m.c...@gmx.net> writes:
> https://joldosh.blogspot.com/2019/12/optimized-msp430-assembly-in-mecrisp.html
> Try your own definitions and SEE generated code!

That is really impressive! It's not so easy for me to try it myself,
without a working MSP430 setup, but that's ok. Any chance of doing
similar things with the other targets (ARM, RISC-V)? Also the RISC-V
embedded profile, which has only 16 registers instead of 32.

I had thought the MSP430 always had a hardware multiplier! I also
didn't realize that the Cortex M0 had fewer registers than the other
models.

I do have some Launchpad boards and an RP2040 board, so I should start
playing with Mecrisp on them. Unfortunately I have nothing with Risc-V.

[Matthias Koch]

Paul,

I started Forth with a FIG Forth listing in assembler. When I began the original Mecrisp for MSP430, writing it in assembler just felt natural to me. Original Mecrisp needs 11 kb, and is therefore suitable for chips starting at 16 kb.

I rewrote the code in ARM assembler because I needed faster analog digital converters and a lot of RAM for my doctoral thesis in biophysics. I did not want to experiment with alternative implementation choices at this point in time because I needed a practical Forth for sciencitic data capture up and running quickly and went the route I was already familiar with. Classic Mecrisp-Stellaris fits in 14 to 16 kb, depending on chip specific support code, and I recommend chips starting at 32 kb.

Later, when Mecrisp-Stellaris was already supporting many chips, I got interested in stronger optimisations, especially for digital signal processing on the microcontroller itself, and fell into the rabbit hole of compiler design books, with too much options to implement. So I set myself a challenge: I gave it an additional 4 kb, and tried to fit as much as possible in terms of compiler infrastructure within. The result, Mecrisp-Stellaris RA, fits in 20 kb, and therefore is still suitable for chips of 32 kb of flash.

With all my scientific needs done, I started Mecrisp-Quintus in my usual way - as a compact rewrite of the ARM assembly code, which also is in the 16 kb ballpark on RV32IMC. But the 4 kb of the register allocator in Stellaris - which many folks call a masterpiece with astonishing capabilities - is a convoluted piece of spaghetti code that pulls every trick I could imagine.

With the RISC-V architecture requiring a different approach for code generation, me doing this for fun this time, and given that most RISC-V and MIPS chips have plenty of memory, I decided I wanted a more readable and approachable implementation this time and wrote the Acrobatics add-on register allocator in Forth, which weighs in at an additional 25 kb on RV32IMC. Note that the weaker compiler is still there, and one can switch between both.

My hint: Write as much of the primitives and speed-critical routines in assembler for performance; go for assembler in the compiler if you need the smallest possible binary size. It certainly helps with compilation speed, too, but I found FIND, the dictionary search, to be the main bottleneck for compilation performance.

Matthias

[Matthias Koch]

RV32EC processor is fine for Mecrisp-Quintus without Acrobatics, but 16 kb are full with the Forth core alone, and an embedded Forth without any way to permanently store user definitions isn't that much fun :-) Ask again when a similiar chip with 32 kb flash shows up!

[Matthias Koch]

By the way, constant folding, level 1, looks like this:

https://github.com/badgeteam/mch2022-firmware-ice40/blob/master/projects/Forth/fw/common-forth/nucleus-16kb-quickstore.fs#L1096-L1162

Reaching level 2 requires that some primitives get an addendum using the folded constants directly. For example "42 +" is one opcode, and "$40001080 !" or "1 PORTA !" is common and saves on stack movements. This requires few in terms of infrastructure, but already gains a lot in terms of performance. Finding the best optimisations is often an iterative process in compiling your application and watching the output of the compiler with a disassembler, picking the low hanging fruits until performance goal is reached.

Mastering level 3 is a lot of work. See mecrisp-quintus-1.0.0/common/acrobatics.txt if you are curious, which is 2000 lines of Forth.

[David Schultz]

On 10/26/22 2:34 AM, Paul Rubin wrote:
> I had thought the MSP430 always had a hardware multiplier!
>

Some do and some don't. But the access is kind of a pain as it is
basically a peripheral. Store the arguments in particular memory
locations and the result appears in another.

--
http://davesrocketworks.com
David Schultz

[Paul Rubin]

It looks like there is a family of them! I don't know about prices or
whether they use the EC instruction set. Unfortunately they all have
more package pins and therefore bigger packages. The 16KB one has a
3x3mm QFN20 package. Some of the ones below have QFN28 but I don't know
the dimensions. I don't read Chinese and have not yet tried machine
translation.

https://www.wch.cn/products/categories/26.html?pid=5#data

[none albert]

In article <tjavf6$2ehsq$2...@dont-email.me>,

See forthlectures.html on my site below, with a generalistion of constant
folding.

Groetjes Albert

[Brian Fox]

It's wonderful to read your posts on Mecrisp here Matthias.
Vielen dank.

[anti...@math.uni.wroc.pl]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Matthias Koch <m.c...@gmx.net> writes:
> > https://joldosh.blogspot.com/2019/12/optimized-msp430-assembly-in-mecrisp.html
> > Try your own definitions and SEE generated code!
>
> That is really impressive! It's not so easy for me to try it myself,
> without a working MSP430 setup, but that's ok. Any chance of doing
> similar things with the other targets (ARM, RISC-V)? Also the RISC-V
> embedded profile, which has only 16 registers instead of 32.
>
> I had thought the MSP430 always had a hardware multiplier!

All MSP430 that I have lack hardware multiplier.

> I also
> didn't realize that the Cortex M0 had fewer registers than the other
> models.

Cortex M0 has the same "general purpose" registers as other models.
Trouble is with intructions, only handful of instructions can
use R8 up to R12. AFAICS only MOV, ADD, CMP, BLX, BX, MRS
and MSR. Basically only way to initialize them is to
use MOV, which needs value in another register. And not much
can be done once you have value there. So, simple compiler
may decide to pretend that they does not exist.

> I do have some Launchpad boards and an RP2040 board, so I should start
> playing with Mecrisp on them. Unfortunately I have nothing with Risc-V.

I have few boards with Risc-V, unfortunately I am to busy with other
projects to try them...

--
Waldek Hebisch

[none albert]

In article <tji0rk$1kju$1...@gioia.aioe.org>, <anti...@math.uni.wroc.pl> wrote:
>Paul Rubin <no.e...@nospam.invalid> wrote:
>> Matthias Koch <m.c...@gmx.net> writes:
>> > https://joldosh.blogspot.com/2019/12/optimized-msp430-assembly-in-mecrisp.html
>> > Try your own definitions and SEE generated code!
>>
>> That is really impressive! It's not so easy for me to try it myself,
>> without a working MSP430 setup, but that's ok. Any chance of doing
>> similar things with the other targets (ARM, RISC-V)? Also the RISC-V
>> embedded profile, which has only 16 registers instead of 32.
>>
>> I had thought the MSP430 always had a hardware multiplier!
>
>All MSP430 that I have lack hardware multiplier.
>
>> I also
>> didn't realize that the Cortex M0 had fewer registers than the other
>> models.
>
>Cortex M0 has the same "general purpose" registers as other models.
>Trouble is with intructions, only handful of instructions can
>use R8 up to R12. AFAICS only MOV, ADD, CMP, BLX, BX, MRS
>and MSR. Basically only way to initialize them is to
>use MOV, which needs value in another register. And not much
>can be done once you have value there. So, simple compiler
>may decide to pretend that they does not exist.

Porting my arm linix compilers to RP2040 was a pain caused by those
restrictions , but I solved it.
Running a more or less straight assembler binary on the RP2040
using the supplied development system was the point I gave
up (at least for the time being.)
Mecrisp had this solved and maybe I take it as an example.

>
>> I do have some Launchpad boards and an RP2040 board, so I should start
>> playing with Mecrisp on them. Unfortunately I have nothing with Risc-V.
>
>I have few boards with Risc-V, unfortunately I am to busy with other
>projects to try them...
>
>--
> Waldek Hebisch