It's not easy, using Google, to get a good overview of what's out
there, and whether particular implementations are maintained
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.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.
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
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.
On Friday, October 21, 2022 at 5:40:51 PM UTC-4, Klapaucius Klapaucius wrote: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.
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
popular with those who simply enjoy arguing.
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
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.
Lorem Ipsum <gnuarm.del...@gmail.com> writes:
Mecrisp is already ported to a large number of targets, both types ofhttps://mecrisp.sourceforge.net/
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.
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.
...
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.
https://mecrisp-stellaris-folkdoc.sourceforge.io/new-projects.html
https://mecrisp-stellaris-folkdoc.sourceforge.io/new-projects.html
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.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.
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
This one: https://github.com/organix/pijFORTHos looks pretty promising. Looks like mecrisp is also active and pretty portable.Hi,
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.
Lorem Ipsum <gnuarm.deletethisbit@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.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
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.
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.
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.
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.
dxforth <dxforth@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.
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).
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.
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.
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.
On 25/10/2022 3:19 am, Paul Rubin wrote:
dxforth <dxforth@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
In article <87h6zvfurp.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
Lorem Ipsum <gnuarm.deletethisbit@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.
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.
dxforth <dxforth@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.
dxforth <dxforth@gmail.com> wrote:
On 25/10/2022 3:19 am, Paul Rubin wrote:
dxforth <dxforth@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
That does _not_ look like output from "optimizing native compiler".
AFAICS this is essentially subroutine threaded code.
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 writtenWhat/who is "middle man" depends on point of view. For me assembler
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.
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.Why not? AFAIK each of them has C compiler and compiler differences
Relying on compatible c-programming environments on a plethora of
boards is *not* the way to go.
that matter for Forth are due to assembler and machine language,
so one needs to handle them anyway.
AFAICS this is essentially subroutine threaded code.There's a hard and fast definition for what constitutes an "optimizing
native compiler"?
anti...@math.uni.wroc.pl schrieb am Dienstag, 25. Oktober 2022 um 04:08:31 UTC+2:
albert <albert@cherry.(none)> wrote:
In article <87h6zvf...@nightsong.com>,What/who is "middle man" depends on point of view. For me assembler
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.
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.Why not? AFAIK each of them has C compiler and compiler differences
Relying on compatible c-programming environments on a plethora of
boards is *not* the way to go.
that matter for Forth are due to assembler and machine language,
so one needs to handle them anyway.
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.
In article <87h6zvfurp.fsf@nightsong.com>,
Paul Rubin <no.email@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.
Waldek Hebisch--
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 <dxforth@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 <dxf...@gmail.com> writes:
I'd be interested to know how Mecrisp compiles that same Forth code.AFAICS this is essentially subroutine threaded code.There's a hard and fast definition for what constitutes an "optimizing native compiler"?
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.
I think there are different possible levels of "optimisation" in
Forth. ...
https://joldosh.blogspot.com/2019/12/optimized-msp430-assembly-in-mecrisp.html
Try your own definitions and SEE generated code!
I had thought the MSP430 always had a hardware multiplier!
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!
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.
By the way, constant folding, level 1, looks like this: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
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,
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.
Matthias Koch <m.cook@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 <m.cook@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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 470 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 82:16:04 |
| Calls: | 9,457 |
| Calls today: | 1 |
| Files: | 13,599 |
| Messages: | 6,115,095 |