amforth-devel — Development discussion and user support

[Amforth] Amforth & Micropython

[John S. <jsa...@gm...>]

Hi Everyone,
Our investigation into using Amforth with Micropython shows this is a very
powerful combination as demonstrated on the RP2350 (Pico 2). Where
Micropython lacks in
performance it can be provided by Amforth on Arm Cortex or Riscv cores and
where Amforth lacks in high speed IO this can be provided by the PIO. The
Amforth assembler routines can be called directly from Micropython whether
residing on the Cortex (Arm) or Riscv core.

Regards to all,
John S

Re: [Amforth] amforth32 release 1.0

[John S. <jsa...@gm...>]

Hi Martin & Tristan,
Better still, our current work being used (amforth riscv - or glanForth)
can easily be synched
to your code base without much effort. The CH32X033 is still being used
with glanForth with the GLANN communication interface, the RP2350 (Pico 2)
also now being added as computational nodes in a physical neural network
which could get quite large. CLIPS V7.0 (our version) to manage the
network. Since the RP2350 also has Arm32 cores along with Riscv (Hazard)
cores and PIO (programmable IO) things could get quite interesting.

Thanks again,
John S

On Sun, Apr 19, 2026 at 9:42 PM John Sarabacha <jsa...@gm...> wrote:

> Hi Martin,
> This definitely helps, the RP2350 (Pico 2) is our next target device in
> our research.
> Would like to benchmark Amforth32 against micropython (there should be no
> contest performance wise).
> They both could also co-exist on separate cores (Arm or Riscv).
>
> Thank you for this information,
> John S
>
>
>
> On Sun, Apr 19, 2026 at 5:50 PM Martin Kobetic <mko...@gm...> wrote:
>
>> Hi John
>>
>> We don't have a porting guide yet, but (as with the original AmForth)
>> the structure is purposely set up to facilitate porting. There are
>> multiple layers at which portability decisions are made. There is the
>> shared core, then the two main CPU architectures: ARM and RISC-V and
>> then within each of those there are various MCUs (directories
>> arm/mcu/... and rv/mcu/...). Porting to a new MCU within one of the
>> supported architectures should be reasonably straightforward, the key
>> bit to implement is the UART for the connection to the board. Probably
>> the best canonical/minimal example is one of the qemu MCUs that target
>> the virtual `qemu -M virt`, you can pick whether you're more
>> interested in the arm/mcu/qemu or rv/mcu/qemu. The main file is alway
>> amforth.s supported by the corresponding linker file (qemu.ld in this
>> case). The core readme [1] describes the directory structure in a bit
>> more detail. The user guide [2] discusses how the build system and
>> other development aspects are set up [2].
>>
>> Probably the easiest way to start is to copy the mcu/<arch>/qemu
>> directory and start modifying it for the new MCU. Hope this helps.
>>
>> Best regards,
>> Martin
>>
>> [1] https://github.com/amforth32/amforth32/blob/main/core/readme.md
>> [2] https://amforth32.github.io/amforth32/00-ug/00.00-Overview.html
>>
>> On Sun, Apr 19, 2026 at 2:49 PM John Sarabacha <jsa...@gm...>
>> wrote:
>> >
>> > Are the hardware dependencies reasonably isolated for porting?
>> > Thanks,
>> > John S
>> >
>> > On Sun, Apr 19, 2026 at 1:30 PM John Sarabacha <jsa...@gm...>
>> wrote:
>> >
>> > > Definitely good news.
>> > >
>> > > John S
>> > >
>> > > On Thu, Apr 16, 2026 at 1:34 PM <ho...@tj...> wrote:
>> > >
>> > >> Fellow AmForthers,
>> > >>
>> > >> Martin Kobetic and I are pleased to announce the initial release of
>> > >> amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM
>> > >> and RISC-V variants of AmForth. As many will know, a RISC-V target
>> was
>> > >> introduced in AmForth release 6.7 in 2018 [1], joined by two ARM
>> targets
>> > >> in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth
>> > >> running on the ARM based Arduino(R) UNO R4, there was a great
>> > >> opportunity to restart the development of the 32 bit variants of
>> AmForth
>> > >> in a conserted way, resulting in amforth32. Below is a link to the
>> > >> precompiled binaries with instructions on their use.
>> > >>
>> > >> https://github.com/amforth32/amforth32/releases/tag/v1.0
>> > >>
>> > >> Intrinsically, amforth32 is AmForth at heart; an ITC Forth with
>> > >> recognisers. However, the codebase, build system and ecosystem have
>> > >> changed quite a bit since the 6.8 release.
>> > >>
>> > >> One key change is the adoption of QEMU virtual machines as first
>> class
>> > >> targets, alongside their close (or not so close) real mcu
>> counterparts.
>> > >> This allows non-mcu dependant elements of the codebase to be subject
>> to
>> > >> automated testing. It also means that hardware is not required to try
>> > >> out amforth32 or to participate in the project.
>> > >>
>> > >> There is also a Forth debugger, a dynamic transpiler, a flash
>> framework
>> > >> and ports to obtainable development board targets [3]. More details
>> on
>> > >> the documentation website [a] and repo [b]
>> > >>
>> > >> [a] amforth32.github.io/amforth32
>> > >> [b] github.com/amforth32/amforth32
>> > >>
>> > >> Most of all, it has been a lot of fun getting this far. Of course,
>> there
>> > >> are still things missing, and things which can be improved. We very
>> much
>> > >> welcome participation, and contributions should be a little easier to
>> > >> make.
>> > >>
>> > >> A little early for May 4th be with you, but happy Forthing
>> nevertheless.
>> > >>
>> > >> Best wishes,
>> > >> Tristan / Martin
>> > >>
>> > >> [1] https://sourceforge.net/p/amforth/mailman/message/36375091/
>> > >> [2] https://sourceforge.net/p/amforth/mailman/message/36511255/
>> > >> [3] and some less obtainable ones too
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> Amforth-devel mailing list for http://amforth.sf.net/
>> > >> Amf...@li...
>> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> > >>
>> > >
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] amforth32 release 1.0

[John S. <jsa...@gm...>]

Hi Martin,
This definitely helps, the RP2350 (Pico 2) is our next target device in our
research.
Would like to benchmark Amforth32 against micropython (there should be no
contest performance wise).
They both could also co-exist on separate cores (Arm or Riscv).

Thank you for this information,
John S



On Sun, Apr 19, 2026 at 5:50 PM Martin Kobetic <mko...@gm...> wrote:

> Hi John
>
> We don't have a porting guide yet, but (as with the original AmForth)
> the structure is purposely set up to facilitate porting. There are
> multiple layers at which portability decisions are made. There is the
> shared core, then the two main CPU architectures: ARM and RISC-V and
> then within each of those there are various MCUs (directories
> arm/mcu/... and rv/mcu/...). Porting to a new MCU within one of the
> supported architectures should be reasonably straightforward, the key
> bit to implement is the UART for the connection to the board. Probably
> the best canonical/minimal example is one of the qemu MCUs that target
> the virtual `qemu -M virt`, you can pick whether you're more
> interested in the arm/mcu/qemu or rv/mcu/qemu. The main file is alway
> amforth.s supported by the corresponding linker file (qemu.ld in this
> case). The core readme [1] describes the directory structure in a bit
> more detail. The user guide [2] discusses how the build system and
> other development aspects are set up [2].
>
> Probably the easiest way to start is to copy the mcu/<arch>/qemu
> directory and start modifying it for the new MCU. Hope this helps.
>
> Best regards,
> Martin
>
> [1] https://github.com/amforth32/amforth32/blob/main/core/readme.md
> [2] https://amforth32.github.io/amforth32/00-ug/00.00-Overview.html
>
> On Sun, Apr 19, 2026 at 2:49 PM John Sarabacha <jsa...@gm...>
> wrote:
> >
> > Are the hardware dependencies reasonably isolated for porting?
> > Thanks,
> > John S
> >
> > On Sun, Apr 19, 2026 at 1:30 PM John Sarabacha <jsa...@gm...>
> wrote:
> >
> > > Definitely good news.
> > >
> > > John S
> > >
> > > On Thu, Apr 16, 2026 at 1:34 PM <ho...@tj...> wrote:
> > >
> > >> Fellow AmForthers,
> > >>
> > >> Martin Kobetic and I are pleased to announce the initial release of
> > >> amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM
> > >> and RISC-V variants of AmForth. As many will know, a RISC-V target was
> > >> introduced in AmForth release 6.7 in 2018 [1], joined by two ARM
> targets
> > >> in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth
> > >> running on the ARM based Arduino(R) UNO R4, there was a great
> > >> opportunity to restart the development of the 32 bit variants of
> AmForth
> > >> in a conserted way, resulting in amforth32. Below is a link to the
> > >> precompiled binaries with instructions on their use.
> > >>
> > >> https://github.com/amforth32/amforth32/releases/tag/v1.0
> > >>
> > >> Intrinsically, amforth32 is AmForth at heart; an ITC Forth with
> > >> recognisers. However, the codebase, build system and ecosystem have
> > >> changed quite a bit since the 6.8 release.
> > >>
> > >> One key change is the adoption of QEMU virtual machines as first class
> > >> targets, alongside their close (or not so close) real mcu
> counterparts.
> > >> This allows non-mcu dependant elements of the codebase to be subject
> to
> > >> automated testing. It also means that hardware is not required to try
> > >> out amforth32 or to participate in the project.
> > >>
> > >> There is also a Forth debugger, a dynamic transpiler, a flash
> framework
> > >> and ports to obtainable development board targets [3]. More details on
> > >> the documentation website [a] and repo [b]
> > >>
> > >> [a] amforth32.github.io/amforth32
> > >> [b] github.com/amforth32/amforth32
> > >>
> > >> Most of all, it has been a lot of fun getting this far. Of course,
> there
> > >> are still things missing, and things which can be improved. We very
> much
> > >> welcome participation, and contributions should be a little easier to
> > >> make.
> > >>
> > >> A little early for May 4th be with you, but happy Forthing
> nevertheless.
> > >>
> > >> Best wishes,
> > >> Tristan / Martin
> > >>
> > >> [1] https://sourceforge.net/p/amforth/mailman/message/36375091/
> > >> [2] https://sourceforge.net/p/amforth/mailman/message/36511255/
> > >> [3] and some less obtainable ones too
> > >>
> > >>
> > >> _______________________________________________
> > >> Amforth-devel mailing list for http://amforth.sf.net/
> > >> Amf...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >>
> > >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] amforth32 release 1.0

[Martin K. <mko...@gm...>]

Hi John

We don't have a porting guide yet, but (as with the original AmForth)
the structure is purposely set up to facilitate porting. There are
multiple layers at which portability decisions are made. There is the
shared core, then the two main CPU architectures: ARM and RISC-V and
then within each of those there are various MCUs (directories
arm/mcu/... and rv/mcu/...). Porting to a new MCU within one of the
supported architectures should be reasonably straightforward, the key
bit to implement is the UART for the connection to the board. Probably
the best canonical/minimal example is one of the qemu MCUs that target
the virtual `qemu -M virt`, you can pick whether you're more
interested in the arm/mcu/qemu or rv/mcu/qemu. The main file is alway
amforth.s supported by the corresponding linker file (qemu.ld in this
case). The core readme [1] describes the directory structure in a bit
more detail. The user guide [2] discusses how the build system and
other development aspects are set up [2].

Probably the easiest way to start is to copy the mcu/<arch>/qemu
directory and start modifying it for the new MCU. Hope this helps.

Best regards,
Martin

[1] https://github.com/amforth32/amforth32/blob/main/core/readme.md
[2] https://amforth32.github.io/amforth32/00-ug/00.00-Overview.html

On Sun, Apr 19, 2026 at 2:49 PM John Sarabacha <jsa...@gm...> wrote:
>
> Are the hardware dependencies reasonably isolated for porting?
> Thanks,
> John S
>
> On Sun, Apr 19, 2026 at 1:30 PM John Sarabacha <jsa...@gm...> wrote:
>
> > Definitely good news.
> >
> > John S
> >
> > On Thu, Apr 16, 2026 at 1:34 PM <ho...@tj...> wrote:
> >
> >> Fellow AmForthers,
> >>
> >> Martin Kobetic and I are pleased to announce the initial release of
> >> amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM
> >> and RISC-V variants of AmForth. As many will know, a RISC-V target was
> >> introduced in AmForth release 6.7 in 2018 [1], joined by two ARM targets
> >> in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth
> >> running on the ARM based Arduino(R) UNO R4, there was a great
> >> opportunity to restart the development of the 32 bit variants of AmForth
> >> in a conserted way, resulting in amforth32. Below is a link to the
> >> precompiled binaries with instructions on their use.
> >>
> >> https://github.com/amforth32/amforth32/releases/tag/v1.0
> >>
> >> Intrinsically, amforth32 is AmForth at heart; an ITC Forth with
> >> recognisers. However, the codebase, build system and ecosystem have
> >> changed quite a bit since the 6.8 release.
> >>
> >> One key change is the adoption of QEMU virtual machines as first class
> >> targets, alongside their close (or not so close) real mcu counterparts.
> >> This allows non-mcu dependant elements of the codebase to be subject to
> >> automated testing. It also means that hardware is not required to try
> >> out amforth32 or to participate in the project.
> >>
> >> There is also a Forth debugger, a dynamic transpiler, a flash framework
> >> and ports to obtainable development board targets [3]. More details on
> >> the documentation website [a] and repo [b]
> >>
> >> [a] amforth32.github.io/amforth32
> >> [b] github.com/amforth32/amforth32
> >>
> >> Most of all, it has been a lot of fun getting this far. Of course, there
> >> are still things missing, and things which can be improved. We very much
> >> welcome participation, and contributions should be a little easier to
> >> make.
> >>
> >> A little early for May 4th be with you, but happy Forthing nevertheless.
> >>
> >> Best wishes,
> >> Tristan / Martin
> >>
> >> [1] https://sourceforge.net/p/amforth/mailman/message/36375091/
> >> [2] https://sourceforge.net/p/amforth/mailman/message/36511255/
> >> [3] and some less obtainable ones too
> >>
> >>
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] amforth32 release 1.0

[John S. <jsa...@gm...>]

Are the hardware dependencies reasonably isolated for porting?
Thanks,
John S

On Sun, Apr 19, 2026 at 1:30 PM John Sarabacha <jsa...@gm...> wrote:

> Definitely good news.
>
> John S
>
> On Thu, Apr 16, 2026 at 1:34 PM <ho...@tj...> wrote:
>
>> Fellow AmForthers,
>>
>> Martin Kobetic and I are pleased to announce the initial release of
>> amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM
>> and RISC-V variants of AmForth. As many will know, a RISC-V target was
>> introduced in AmForth release 6.7 in 2018 [1], joined by two ARM targets
>> in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth
>> running on the ARM based Arduino(R) UNO R4, there was a great
>> opportunity to restart the development of the 32 bit variants of AmForth
>> in a conserted way, resulting in amforth32. Below is a link to the
>> precompiled binaries with instructions on their use.
>>
>> https://github.com/amforth32/amforth32/releases/tag/v1.0
>>
>> Intrinsically, amforth32 is AmForth at heart; an ITC Forth with
>> recognisers. However, the codebase, build system and ecosystem have
>> changed quite a bit since the 6.8 release.
>>
>> One key change is the adoption of QEMU virtual machines as first class
>> targets, alongside their close (or not so close) real mcu counterparts.
>> This allows non-mcu dependant elements of the codebase to be subject to
>> automated testing. It also means that hardware is not required to try
>> out amforth32 or to participate in the project.
>>
>> There is also a Forth debugger, a dynamic transpiler, a flash framework
>> and ports to obtainable development board targets [3]. More details on
>> the documentation website [a] and repo [b]
>>
>> [a] amforth32.github.io/amforth32
>> [b] github.com/amforth32/amforth32
>>
>> Most of all, it has been a lot of fun getting this far. Of course, there
>> are still things missing, and things which can be improved. We very much
>> welcome participation, and contributions should be a little easier to
>> make.
>>
>> A little early for May 4th be with you, but happy Forthing nevertheless.
>>
>> Best wishes,
>> Tristan / Martin
>>
>> [1] https://sourceforge.net/p/amforth/mailman/message/36375091/
>> [2] https://sourceforge.net/p/amforth/mailman/message/36511255/
>> [3] and some less obtainable ones too
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] amforth32 release 1.0

[John S. <jsa...@gm...>]

Definitely good news.

John S

On Thu, Apr 16, 2026 at 1:34 PM <ho...@tj...> wrote:

> Fellow AmForthers,
>
> Martin Kobetic and I are pleased to announce the initial release of
> amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM
> and RISC-V variants of AmForth. As many will know, a RISC-V target was
> introduced in AmForth release 6.7 in 2018 [1], joined by two ARM targets
> in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth
> running on the ARM based Arduino(R) UNO R4, there was a great
> opportunity to restart the development of the 32 bit variants of AmForth
> in a conserted way, resulting in amforth32. Below is a link to the
> precompiled binaries with instructions on their use.
>
> https://github.com/amforth32/amforth32/releases/tag/v1.0
>
> Intrinsically, amforth32 is AmForth at heart; an ITC Forth with
> recognisers. However, the codebase, build system and ecosystem have
> changed quite a bit since the 6.8 release.
>
> One key change is the adoption of QEMU virtual machines as first class
> targets, alongside their close (or not so close) real mcu counterparts.
> This allows non-mcu dependant elements of the codebase to be subject to
> automated testing. It also means that hardware is not required to try
> out amforth32 or to participate in the project.
>
> There is also a Forth debugger, a dynamic transpiler, a flash framework
> and ports to obtainable development board targets [3]. More details on
> the documentation website [a] and repo [b]
>
> [a] amforth32.github.io/amforth32
> [b] github.com/amforth32/amforth32
>
> Most of all, it has been a lot of fun getting this far. Of course, there
> are still things missing, and things which can be improved. We very much
> welcome participation, and contributions should be a little easier to
> make.
>
> A little early for May 4th be with you, but happy Forthing nevertheless.
>
> Best wishes,
> Tristan / Martin
>
> [1] https://sourceforge.net/p/amforth/mailman/message/36375091/
> [2] https://sourceforge.net/p/amforth/mailman/message/36511255/
> [3] and some less obtainable ones too
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] amforth32 release 1.0

[<ho...@tj...>]

Fellow AmForthers,

Martin Kobetic and I are pleased to announce the initial release of 
amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM 
and RISC-V variants of AmForth. As many will know, a RISC-V target was 
introduced in AmForth release 6.7 in 2018 [1], joined by two ARM targets 
in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth 
running on the ARM based Arduino(R) UNO R4, there was a great 
opportunity to restart the development of the 32 bit variants of AmForth 
in a conserted way, resulting in amforth32. Below is a link to the 
precompiled binaries with instructions on their use.

https://github.com/amforth32/amforth32/releases/tag/v1.0

Intrinsically, amforth32 is AmForth at heart; an ITC Forth with 
recognisers. However, the codebase, build system and ecosystem have 
changed quite a bit since the 6.8 release.

One key change is the adoption of QEMU virtual machines as first class 
targets, alongside their close (or not so close) real mcu counterparts. 
This allows non-mcu dependant elements of the codebase to be subject to 
automated testing. It also means that hardware is not required to try 
out amforth32 or to participate in the project.

There is also a Forth debugger, a dynamic transpiler, a flash framework 
and ports to obtainable development board targets [3]. More details on 
the documentation website [a] and repo [b]

[a] amforth32.github.io/amforth32
[b] github.com/amforth32/amforth32

Most of all, it has been a lot of fun getting this far. Of course, there 
are still things missing, and things which can be improved. We very much 
welcome participation, and contributions should be a little easier to 
make.

A little early for May 4th be with you, but happy Forthing nevertheless.

Best wishes,
Tristan / Martin

[1] https://sourceforge.net/p/amforth/mailman/message/36375091/
[2] https://sourceforge.net/p/amforth/mailman/message/36511255/
[3] and some less obtainable ones too

Re: [Amforth] AmForth & AI (Expert Systems)

[John S. <jsa...@gm...>]

Hi Everyone,
Forgot to mention that an assembler abstraction layer is still being used
to make easier porting to
other chips (this part still works reliably). The difference being the use
of assembler macros instead of C macros for this layer.
>From what I am seeing is the riscv toolchain isn't reliable enough through
the chain. The riscv assembler on its own has better
reliability (at least for now).



On Mon, Mar 30, 2026 at 11:06 AM John Sarabacha <jsa...@gm...>
wrote:

> Hi Everyone,
> For those still following this thread, to improve the reliability of this
> work some changes were made to glanForth(derived from AmForth).
> A hybrid of C generated and  assembler code using asm(...) and C data
> structures is no longer being used, pure assembler generated code is being
> used instead, due to problems relating to the riscv toolchain used by
> MounRiver Studio (even the most up to date toolchain had these issues -
> still experimental???). The best results were obtained by using the pure
> riscv assembly code for amForth. Also to get consistent amforth dictionary
> alignment on 32 bit boundaries the NEXT macro wasn't being used with the
> primary words, instead a macro was used for each primary word along with a
> branch instruction to the next code in the ITC interpreter.
> These results were verified not by simulation but by actual hardware (chip
> level) observations.
> The latest build for a functioning riscv amforth (almost the complete code
> base) was 10,043 bytes for the CH32X033 and can function interactively or
> can co-exist with other C or assembler routines.
> An experimental version of the Expert System CLIPS V7 will be used to
> generate and verify forth code sequences with this build.
> Very little of the available SRAM has been used in this build, which can
> be used to store significant amounts of user forth programs.
>
> Best Regards,
> John S
>
> On Wed, Mar 4, 2026 at 9:56 AM John Sarabacha <jsa...@gm...>
> wrote:
>
>> Hi Everyone,
>> For those interested in this topic and are using AmForth, an experimental
>> version of the Expert System CLIPS V7 has been successfully built and will
>> be used with glanForth(derived from AmForth) to generate forth code
>> sequences (based on defined knowledge rules and 2012 standard forth syntax)
>> across a large network of glannForth (non-derived runtime embedded forth)
>> nodes.
>> Currently glanForth(derived from AmForth) is a hybrid of assembler code
>> and C data structures.
>>
>> Regards to all,
>> John S
>>
>>

Re: [Amforth] AmForth & AI (Expert Systems)

[John S. <jsa...@gm...>]

Hi Everyone,
For those still following this thread, to improve the reliability of this
work some changes were made to glanForth(derived from AmForth).
A hybrid of C generated and  assembler code using asm(...) and C data
structures is no longer being used, pure assembler generated code is being
used instead, due to problems relating to the riscv toolchain used by
MounRiver Studio (even the most up to date toolchain had these issues -
still experimental???). The best results were obtained by using the pure
riscv assembly code for amForth. Also to get consistent amforth dictionary
alignment on 32 bit boundaries the NEXT macro wasn't being used with the
primary words, instead a macro was used for each primary word along with a
branch instruction to the next code in the ITC interpreter.
These results were verified not by simulation but by actual hardware (chip
level) observations.
The latest build for a functioning riscv amforth (almost the complete code
base) was 10,043 bytes for the CH32X033 and can function interactively or
can co-exist with other C or assembler routines.
An experimental version of the Expert System CLIPS V7 will be used to
generate and verify forth code sequences with this build.
Very little of the available SRAM has been used in this build, which can be
used to store significant amounts of user forth programs.

Best Regards,
John S

On Wed, Mar 4, 2026 at 9:56 AM John Sarabacha <jsa...@gm...> wrote:

> Hi Everyone,
> For those interested in this topic and are using AmForth, an experimental
> version of the Expert System CLIPS V7 has been successfully built and will
> be used with glanForth(derived from AmForth) to generate forth code
> sequences (based on defined knowledge rules and 2012 standard forth syntax)
> across a large network of glannForth (non-derived runtime embedded forth)
> nodes.
> Currently glanForth(derived from AmForth) is a hybrid of assembler code
> and C data structures.
>
> Regards to all,
> John S
>
>

[Amforth] AmForth & AI (Expert Systems)

[John S. <jsa...@gm...>]

Hi Everyone,
For those interested in this topic and are using AmForth, an experimental
version of the Expert System CLIPS V7 has been successfully built and will
be used with glanForth(derived from AmForth) to generate forth code
sequences (based on defined knowledge rules and 2012 standard forth syntax)
across a large network of glannForth (non-derived runtime embedded forth)
nodes.
Currently glanForth(derived from AmForth) is a hybrid of assembler code
and C data structures.

Regards to all,
John S

Re: [Amforth] AmForth riscv extensions

[John S. <jsa...@gm...>]

Hi George H,
Thanks for that clarification, I also have a copy of that forth (eforth).
Thanks again,
John S

On Wed, Feb 18, 2026 at 9:10 AM George H <jac...@gm...> wrote:

> I need to correct my statement.
>
> It was not 20 assembler primatives. Dr. C. H. Ting created eForth with 31
> assembler primatives and extended the dictionary to about 200 words by
> using Forth.
>
> Much of his later work was done in C.
>
>
>
> On Wed, Feb 11, 2026, 01:25 John Sarabacha <jsa...@gm...> wrote:
>
> > Hi Everyone,
> > These are now available again (in download) including the abstraction
> > layer.
> > Please observe the licensing on riscv-pal.h
> > Anything relating to the use of AmForth will be found here.
> > Note: These (download files) are no longer used on CH32X033 with my
> > application software but will be used on other platforms (ESP32-C3/C6)
> > separate from my application (on different processors).
> > CH32X033 with my application software is now using FiveForths (MIT
> > licensing) as a starting point with 19 primary words which can build the
> > rest of the needed dictionary.
> >
> > Thanks goes to George H for planting this seed (I think he said less than
> > 20
> > assembler words to build the entire forth system - he was right )
> >
> > Regards to all,
> > John S
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] AmForth riscv extensions

[George H <jac...@gm...>]

I need to correct my statement.

It was not 20 assembler primatives. Dr. C. H. Ting created eForth with 31
assembler primatives and extended the dictionary to about 200 words by
using Forth.

Much of his later work was done in C.



On Wed, Feb 11, 2026, 01:25 John Sarabacha <jsa...@gm...> wrote:

> Hi Everyone,
> These are now available again (in download) including the abstraction
> layer.
> Please observe the licensing on riscv-pal.h
> Anything relating to the use of AmForth will be found here.
> Note: These (download files) are no longer used on CH32X033 with my
> application software but will be used on other platforms (ESP32-C3/C6)
> separate from my application (on different processors).
> CH32X033 with my application software is now using FiveForths (MIT
> licensing) as a starting point with 19 primary words which can build the
> rest of the needed dictionary.
>
> Thanks goes to George H for planting this seed (I think he said less than
> 20
> assembler words to build the entire forth system - he was right )
>
> Regards to all,
> John S
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Derived AmForth & new non-derived forth

[John S. <jsa...@gm...>]

Correction riscv (not risc) - also ESP32-C5 (2.4 & 5G)

On Tue, Feb 17, 2026 at 10:48 AM John Sarabacha <jsa...@gm...>
wrote:

> Hi Everyone,
> For those interested in risc I will be targeting the entire line of CH32
> and ESP32-C3/H2/C6
> and will share significant learnings.
>
> Regards,
> John S
>
> On Mon, Feb 16, 2026 at 9:37 AM John Sarabacha <jsa...@gm...>
> wrote:
>
>> Hi Everyone,
>> In my world (of communications software research) there are now 2 new
>> versions of forth targeting riscv (initially), a derived version of AmForth
>> now called glanForth and a non-derived version called glannForth. The
>> glanForth version source will be
>> available once testing is completed. The glannForth version is the more
>> security sensitive version and will not be available outside company NDA
>> and licensing.
>> The previous download has changed significantly from the current state.
>>
>> Regards,
>> John S
>>
>

Re: [Amforth] Derived AmForth & new non-derived forth

[John S. <jsa...@gm...>]

Hi Everyone,
For those interested in risc I will be targeting the entire line of CH32
and ESP32-C3/H2/C6
and will share significant learnings.

Regards,
John S

On Mon, Feb 16, 2026 at 9:37 AM John Sarabacha <jsa...@gm...> wrote:

> Hi Everyone,
> In my world (of communications software research) there are now 2 new
> versions of forth targeting riscv (initially), a derived version of AmForth
> now called glanForth and a non-derived version called glannForth. The
> glanForth version source will be
> available once testing is completed. The glannForth version is the more
> security sensitive version and will not be available outside company NDA
> and licensing.
> The previous download has changed significantly from the current state.
>
> Regards,
> John S
>

[Amforth] Derived AmForth & new non-derived forth

[John S. <jsa...@gm...>]

Hi Everyone,
In my world (of communications software research) there are now 2 new
versions of forth targeting riscv (initially), a derived version of AmForth
now called glanForth and a non-derived version called glannForth. The
glanForth version source will be
available once testing is completed. The glannForth version is the more
security sensitive version and will not be available outside company NDA
and licensing.
The previous download has changed significantly from the current state.

Regards,
John S

Re: [Amforth] AVR8: The SREG:I-flag is an Unreliable Indicator of Interrupt Status

[Martin N. <amf...@mg...>]

On Fri, 13 Feb 2026 10:23:03 +0000
ho...@tj... wrote:

> On 2026-02-08 15:38, Martin Nicholas via Amforth-devel wrote:
> > SNIPPED  
> 
> Hi Martin,
> 
> Thank you. Added to the list.
> 
> A preliminary check of the archives shows that the way interrupts
> were handled by the VM changed between releases 6.4 and 6.5
> 
> In 6.4 there is
> brts DO_INTERRUPT
> 
> In 6.5 there is
> cp isrflag, zerol
> brne DO_INTERRUPT
> 
> The release notes for 6.5 [1] state that there was a bug in the 
> interrupt handling on the avr8. Erich discovered and fixed the bug,
> and so may be able to help. Current avr8 documentation references the
> T flag but does not reference isrflag, so this is something that will
> need to be updated.
> 
> The file avr8//drivers/generic-isr.asm shows considerable related 
> changes between the releases but I need more time to study it.
> 
> Best wishes,
> Tristan
> 
> [1] https://sourceforge.net/p/amforth/mailman/message/35814877/
> 

I think the change 6.4 -> 6.5 abandoned the T-flag as the pending
indicator, using the value in isrflag instead.
Is this Erich's fix? I don't know.
IMHO the best (fastest) solution is to use them both.

Certainly 6.9 has bugs in: /avr8/words/int-[on|off].asm and others, so
there are still problems lurking.

Should I explain the problem more? Here's the code for RP! from 6.9:
PFA_RP_STORE:
in temp2, SREG	; (A)
; (B)
cli		: (C)
out SPL, tosl
out SPH, tosh
out SREG, temp2	; (D)
; (E)
loadtos
jmp_ DO_NEXT

The I-flag is preserved at (A). Interrupts are disabled at (C),
restored again at (D).

If interrupts are disabled throughout, all is fine - no need to worry.
If interrupts are enabled and no interrupts occur throughout - again no
problem.

What if, however, interrupts are enabled and an interrupt occurs at
point (B)? At point (D), interrupts are re-enabled, using the state
from (A). This is a problem. A second interrupt at (E) or later will
overwrite the interrupt request, set at (B) with another - a pending
interrupt will be missed.

Similar problems arise wherever the I-flag is read/written/preserved.
In particular, -INT cannot be guaranteed actually to disable interrupts.
These things may also be problematic in other architectures where
"Interrupts the Forth way" is used - I've not looked.

Tristan - I'll email you some code, since attachments are not allowed
here.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2026).

Re: [Amforth] AVR8: The SREG:I-flag is an Unreliable Indicator of Interrupt Status

[<ho...@tj...>]

On 2026-02-08 15:38, Martin Nicholas via Amforth-devel wrote:
> Firstly, here's the docs:
> http://amforth.sourceforge.net/TG/AVR8.html#interrupts
> http://amforth.sourceforge.net/TG/recipes/Interrupt-Critical-Section.html
> 
> Source files:
> amforth-6.9/avr8/lib/hardware/int-q.frt
> etc.
> 
> Because of the way AmForth handles interrupts, the I-flag can be
> cleared (disabling the interrupts globally) at any time during the
> execution of a Forth primative. It can change to zero between any two
> M/C code instructions.
> 
> So "int?" has to check both the I-flag and the value of "isrflag"
> (T-flag) to come to a valid conclusion. "-int" cannot just perform a
> CLI instruction as the next NEXT may process a pending (pending before
> the CLI was executed) interrupt and re-enable them. Etc.
> 
> Reliable fetch of interrupt status.
> Checks for pending interrupts.
> 	I	T***	int?	Remarks
> 	=	=	====	=======
> 	0	0	 0	Interrupts disabled by the program.
> 	0	1	-1	Interrupt pending*
> 	1	0	-1	Normal operation.
> 	1	1	-1	Shouldn't ever be**
> 
>   *	This will be serviced by the next NEXT and SREG:I will be
> 	set once more.
>  **	The interrupt will still get serviced, provided it isn't
> 	overwritten.
> ***	The T-flag seems to be reserved as a holder for the ISR
> 	status, but currently it isn't used. Location "isrflag" is used
> 	instead and is a much slower.
> 
> Special care has to be taken to save and restore the I-flag. I have
> written macro "no_ints". It uses MCUCR:IVCE to
> disable interrupts without affecting the I-flag - see the docs.
> 
> Correctly preserve the interrupt status in @0:
> 
> .macro no_ints
> 	in	@0, MCUCR
> 	ori	@0, (1<<IVCE)
> 	out	MCUCR, @0
> 	in	@0, SREG
> 	cli
> .endmacro
> 
> Later Atmel cores automatically disable interrupts for a time if you
> fiddle with the SP register, so "no_ints" is not required here. Maybe
> there are other operations that do this too.

Hi Martin,

Thank you. Added to the list.

A preliminary check of the archives shows that the way interrupts were 
handled by the VM changed between releases 6.4 and 6.5

In 6.4 there is
brts DO_INTERRUPT

In 6.5 there is
cp isrflag, zerol
brne DO_INTERRUPT

The release notes for 6.5 [1] state that there was a bug in the 
interrupt handling on the avr8. Erich discovered and fixed the bug, and 
so may be able to help. Current avr8 documentation references the T flag 
but does not reference isrflag, so this is something that will need to 
be updated.

The file avr8//drivers/generic-isr.asm shows considerable related 
changes between the releases but I need more time to study it.

Best wishes,
Tristan

[1] https://sourceforge.net/p/amforth/mailman/message/35814877/

Re: [Amforth] GPLv3

[John S. <jsa...@gm...>]

Hi Carsten,
Thank you for this information. It helps to clear up a lot of things.
I will tone down on licensing for this mailing list.

Regards,
John S

On Wed, Feb 11, 2026 at 3:36 PM Carsten Strotmann via Amforth-devel <
amf...@li...> wrote:

> Hi John,
>
> On 11 Feb 2026, at 17:06, John Sarabacha wrote:
>
> > Hi Carsten,
> > So if I wrote a Windows11 application and gave it a GPLv3 licensing and
> > included
> > the header file "windows.h",  it and all it's nested includes would now
> be
> > GPLv3 and
> > Microsoft is forced to release it's source code with any distribution.
>
> Not Microsoft is forced, you (the developer) is forced.
>
> The licensing failure would be on your side in this case. Including
> "windows.h" in your code would make it part of a GPLv3 licensed work, but
> you are not allowed to do that in case the license of "windows.h" is not
> compatible with the GPLv3 (I have no idea what the licensing of "windows.h"
> is, it might be compatible with GPLv3, it might be redistributable. But
> quick research indicates it is not).
>
> Once you release that Windows11 application containing GPLv3 code, you
> would need to also publish "windows.h", as it is part of the full source
> code. But the redistribution license of "windows.h" might not allow that,
> so you are not allowed to use "windows.h" in an GPLv3 application in the
> first place.
>
> Using the original Microsoft header files with GPL licensed code is in a
> grey area. Even Microsoft does not know the implications (see
> https://github.com/microsoft/win32metadata/issues/766 ).
>
> That is why GPL licensed compiler for Windows come with their own language
> bindings and header (such as MinGW) that are GPL or permissive licensed and
> not rely on the Microsoft versions of these header files.
>
>
> This discussion is now very much offtopic for this mailing list, as it is
> about software licensing, and not amForth specific. I recommend to bring
> this discussion to a list that has been set up for these kind of
> discussions, such as lists.sfconservancy.org Mailing Lists. (
> https://lists.sfconservancy.org/mailman/listinfo/). There it is more
> likely to find good answers on your questions.
>
> Greetings
>
> Carsten
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] GPLv3

[Carsten S. <ca...@st...>]

Hi John,

On 11 Feb 2026, at 17:06, John Sarabacha wrote:

> Hi Carsten,
> So if I wrote a Windows11 application and gave it a GPLv3 licensing and
> included
> the header file "windows.h",  it and all it's nested includes would now be
> GPLv3 and
> Microsoft is forced to release it's source code with any distribution.

Not Microsoft is forced, you (the developer) is forced.

The licensing failure would be on your side in this case. Including "windows.h" in your code would make it part of a GPLv3 licensed work, but you are not allowed to do that in case the license of "windows.h" is not compatible with the GPLv3 (I have no idea what the licensing of "windows.h" is, it might be compatible with GPLv3, it might be redistributable. But quick research indicates it is not).

Once you release that Windows11 application containing GPLv3 code, you would need to also publish "windows.h", as it is part of the full source code. But the redistribution license of "windows.h" might not allow that, so you are not allowed to use "windows.h" in an GPLv3 application in the first place.

Using the original Microsoft header files with GPL licensed code is in a grey area. Even Microsoft does not know the implications (see https://github.com/microsoft/win32metadata/issues/766 ).

That is why GPL licensed compiler for Windows come with their own language bindings and header (such as MinGW) that are GPL or permissive licensed and not rely on the Microsoft versions of these header files.


This discussion is now very much offtopic for this mailing list, as it is about software licensing, and not amForth specific. I recommend to bring this discussion to a list that has been set up for these kind of discussions, such as lists.sfconservancy.org Mailing Lists. (https://lists.sfconservancy.org/mailman/listinfo/). There it is more likely to find good answers on your questions.

Greetings

Carsten

Re: [Amforth] GPLv3

[John S. <jsa...@gm...>]

Hi Everyone,
In fact if you want, you can use "riscv_pal.h" however you like with
AmForth GPLv3.
I have no issue with this (even in distributions). As I mentioned in my
previous emails my interest
is in forth itself and how to best utilize it my research work and
licensing is an important consideration
that needs to be considered.

Thank you for your contributions,
Regards,
John S




On Wed, Feb 11, 2026 at 1:28 PM John Sarabacha <jsa...@gm...> wrote:

> Hi Erich,
> I agree with you totally regarding "derived works",
> the dividing line is "derived works" versus "original works".
> They cannot be treated equally,
> Macros.h, dict_prims.c, dict_secs.c are in fact "derived works" and there
> is
> no issue they are GPLv3 just as AmForth is.
> This issue is with "riscv_pal.h" which is in fact an "original work" with
> its own licensing,
>  it  has no connection with AmForth other being included in AmForth
> "derived works"
> much like Microsoft does with "Windows.h" ("original works").
> "Original works" cannot be included in GPLv3 works (AmForth "derived
> works")
> for distribution without respecting the licensing of the "original works".
>
> Again this meant to be a friendly discussion,
> Regards,
> John S
>
>
>
>
> On Wed, Feb 11, 2026 at 12:29 PM Erich Wälde <ew....@na...> wrote:
>
>> Hello,
>>
>> if I create some code under GPLv3, then this license extents to
>> "derived works". If someone wants to include my code into their
>> works, it could be a problem.
>>
>> However, if I include some code under MIT, I can still publish
>> my code under GPLv3. That does NOT lead to the included file
>> change its license. I must not claim, the included code is mine.
>> If I made changes, I need to clearly document them, and the
>> original license still applies to said code including my
>> changes.
>>
>> There is LGPL, such that you can link to my code without its
>> license extent to your code. But this "linking" does not apply
>> to Forth, because there is no linking.
>>
>> There is AGPL, such that you cannot hide my GPL code as a
>> service behind a web interface.
>>
>>
>> You can still build your application using GPL components in the
>> form of say
>> - underlying OS (think linux or *BSD)
>> - supporting separate software components (think postgresql)
>> - loaded or linked to libraries and their header files (think glibc)
>> provided you distribute all this to your customer in the
>> preferred from of modifikation, i.e. source code. It does not
>> extend to your application code.
>>
>> In my understanding, you cannot use GPL code, mix it into your
>> application source code, i.e. produce a derived work, and then
>> sell the result to a customer in compiled form without giving
>> away the complete code. That does not work, because in this case
>> you are producing a derived work. THIS is the exact purpose of
>> copy-left licenses. You shall not produce a "derived work" and
>> hide it's source code.
>>
>>
>> I'm still not a lawyer. But actually reading the license text
>> may help.
>>
>>
>> I will not agree to AmForth changing its license.
>> We had this discussion before, there is nothing new so far.
>>
>>
>>
>> Cheers,
>> Erich
>>
>>
>>
>> John Sarabacha <jsa...@gm...> writes:
>>
>> > Hi Carsten,
>> > So if I wrote a Windows11 application and gave it a GPLv3 licensing and
>> > included
>> > the header file "windows.h",  it and all it's nested includes would now
>> be
>> > GPLv3 and
>> > Microsoft is forced to release it's source code with any distribution.
>> > How long do you think it would take before Microsoft police would show
>> up
>> > at my door?
>> > I am sure Linus (Linux creator) knew this as well.
>> >
>> > Again intended as a friendly exchange,
>> > Regards,
>> > John S
>> >
>> > On Wed, Feb 11, 2026 at 3:51 AM Carsten Strotmann via Amforth-devel <
>> > amf...@li...> wrote:
>> >
>> >> Hi,
>> >>
>> >> On 11 Feb 2026, at 9:32, John Sarabacha wrote:
>> >>
>> >> > dedicatedcomputer.ca/test
>> >> > Please examine the license terms on riscv_pal.h
>> >>
>> >> I'm not a lawyer, but in my experience with these kinds of questions,
>> >> "riscv_pal.h" is clearly part of the final product, included into
>> >> "dict_prims.c", which is "Licensing Compatible with AmForth (GPL3)",
>> which
>> >> equals GPLv3, so "riscv_pal.h" must also be licensed under GPLv3.
>> >>
>> >> > If I supply this file it doesn't mean I give up my rights under this
>> >> > license.
>> >>
>> >> Well, from the nature of the license and the nature of the code, you've
>> >> placed the code in "riscv_pal.h" under GPLv3.
>> >>
>> >> > Sometimes this freeness is not always on equal terms. Some will take
>> >> > advantage.
>> >>
>> >> Yes, and that is why people choose GPLv3 to prevent that people take
>> >> advantage.
>> >>
>> >> Greetings
>> >>
>> >> Carsten
>> >>
>> >>
>> >> _______________________________________________
>> >> Amforth-devel mailing list for http://amforth.sf.net/
>> >> Amf...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>> --
>> May the Forth be with you ...
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] GPLv3

[John S. <jsa...@gm...>]

Hi Erich,
I agree with you totally regarding "derived works",
the dividing line is "derived works" versus "original works".
They cannot be treated equally,
Macros.h, dict_prims.c, dict_secs.c are in fact "derived works" and there is
no issue they are GPLv3 just as AmForth is.
This issue is with "riscv_pal.h" which is in fact an "original work" with
its own licensing,
 it  has no connection with AmForth other being included in AmForth
"derived works"
much like Microsoft does with "Windows.h" ("original works").
"Original works" cannot be included in GPLv3 works (AmForth "derived works")
for distribution without respecting the licensing of the "original works".

Again this meant to be a friendly discussion,
Regards,
John S




On Wed, Feb 11, 2026 at 12:29 PM Erich Wälde <ew....@na...> wrote:

> Hello,
>
> if I create some code under GPLv3, then this license extents to
> "derived works". If someone wants to include my code into their
> works, it could be a problem.
>
> However, if I include some code under MIT, I can still publish
> my code under GPLv3. That does NOT lead to the included file
> change its license. I must not claim, the included code is mine.
> If I made changes, I need to clearly document them, and the
> original license still applies to said code including my
> changes.
>
> There is LGPL, such that you can link to my code without its
> license extent to your code. But this "linking" does not apply
> to Forth, because there is no linking.
>
> There is AGPL, such that you cannot hide my GPL code as a
> service behind a web interface.
>
>
> You can still build your application using GPL components in the
> form of say
> - underlying OS (think linux or *BSD)
> - supporting separate software components (think postgresql)
> - loaded or linked to libraries and their header files (think glibc)
> provided you distribute all this to your customer in the
> preferred from of modifikation, i.e. source code. It does not
> extend to your application code.
>
> In my understanding, you cannot use GPL code, mix it into your
> application source code, i.e. produce a derived work, and then
> sell the result to a customer in compiled form without giving
> away the complete code. That does not work, because in this case
> you are producing a derived work. THIS is the exact purpose of
> copy-left licenses. You shall not produce a "derived work" and
> hide it's source code.
>
>
> I'm still not a lawyer. But actually reading the license text
> may help.
>
>
> I will not agree to AmForth changing its license.
> We had this discussion before, there is nothing new so far.
>
>
>
> Cheers,
> Erich
>
>
>
> John Sarabacha <jsa...@gm...> writes:
>
> > Hi Carsten,
> > So if I wrote a Windows11 application and gave it a GPLv3 licensing and
> > included
> > the header file "windows.h",  it and all it's nested includes would now
> be
> > GPLv3 and
> > Microsoft is forced to release it's source code with any distribution.
> > How long do you think it would take before Microsoft police would show up
> > at my door?
> > I am sure Linus (Linux creator) knew this as well.
> >
> > Again intended as a friendly exchange,
> > Regards,
> > John S
> >
> > On Wed, Feb 11, 2026 at 3:51 AM Carsten Strotmann via Amforth-devel <
> > amf...@li...> wrote:
> >
> >> Hi,
> >>
> >> On 11 Feb 2026, at 9:32, John Sarabacha wrote:
> >>
> >> > dedicatedcomputer.ca/test
> >> > Please examine the license terms on riscv_pal.h
> >>
> >> I'm not a lawyer, but in my experience with these kinds of questions,
> >> "riscv_pal.h" is clearly part of the final product, included into
> >> "dict_prims.c", which is "Licensing Compatible with AmForth (GPL3)",
> which
> >> equals GPLv3, so "riscv_pal.h" must also be licensed under GPLv3.
> >>
> >> > If I supply this file it doesn't mean I give up my rights under this
> >> > license.
> >>
> >> Well, from the nature of the license and the nature of the code, you've
> >> placed the code in "riscv_pal.h" under GPLv3.
> >>
> >> > Sometimes this freeness is not always on equal terms. Some will take
> >> > advantage.
> >>
> >> Yes, and that is why people choose GPLv3 to prevent that people take
> >> advantage.
> >>
> >> Greetings
> >>
> >> Carsten
> >>
> >>
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
> --
> May the Forth be with you ...
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] GPLv3

[Erich W. <ew....@na...>]

Hello,

if I create some code under GPLv3, then this license extents to
"derived works". If someone wants to include my code into their
works, it could be a problem.

However, if I include some code under MIT, I can still publish
my code under GPLv3. That does NOT lead to the included file
change its license. I must not claim, the included code is mine.
If I made changes, I need to clearly document them, and the
original license still applies to said code including my
changes.

There is LGPL, such that you can link to my code without its
license extent to your code. But this "linking" does not apply
to Forth, because there is no linking.

There is AGPL, such that you cannot hide my GPL code as a
service behind a web interface.


You can still build your application using GPL components in the
form of say
- underlying OS (think linux or *BSD)
- supporting separate software components (think postgresql)
- loaded or linked to libraries and their header files (think glibc)
provided you distribute all this to your customer in the
preferred from of modifikation, i.e. source code. It does not
extend to your application code.

In my understanding, you cannot use GPL code, mix it into your
application source code, i.e. produce a derived work, and then
sell the result to a customer in compiled form without giving
away the complete code. That does not work, because in this case
you are producing a derived work. THIS is the exact purpose of
copy-left licenses. You shall not produce a "derived work" and
hide it's source code.


I'm still not a lawyer. But actually reading the license text
may help.


I will not agree to AmForth changing its license.
We had this discussion before, there is nothing new so far.



Cheers,
Erich



John Sarabacha <jsa...@gm...> writes:

> Hi Carsten,
> So if I wrote a Windows11 application and gave it a GPLv3 licensing and
> included
> the header file "windows.h",  it and all it's nested includes would now be
> GPLv3 and
> Microsoft is forced to release it's source code with any distribution.
> How long do you think it would take before Microsoft police would show up
> at my door?
> I am sure Linus (Linux creator) knew this as well.
>
> Again intended as a friendly exchange,
> Regards,
> John S
>
> On Wed, Feb 11, 2026 at 3:51 AM Carsten Strotmann via Amforth-devel <
> amf...@li...> wrote:
>
>> Hi,
>>
>> On 11 Feb 2026, at 9:32, John Sarabacha wrote:
>>
>> > dedicatedcomputer.ca/test
>> > Please examine the license terms on riscv_pal.h
>>
>> I'm not a lawyer, but in my experience with these kinds of questions,
>> "riscv_pal.h" is clearly part of the final product, included into
>> "dict_prims.c", which is "Licensing Compatible with AmForth (GPL3)", which
>> equals GPLv3, so "riscv_pal.h" must also be licensed under GPLv3.
>>
>> > If I supply this file it doesn't mean I give up my rights under this
>> > license.
>>
>> Well, from the nature of the license and the nature of the code, you've
>> placed the code in "riscv_pal.h" under GPLv3.
>>
>> > Sometimes this freeness is not always on equal terms. Some will take
>> > advantage.
>>
>> Yes, and that is why people choose GPLv3 to prevent that people take
>> advantage.
>>
>> Greetings
>>
>> Carsten
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

-- 
May the Forth be with you ...

Re: [Amforth] GPLv3

[John S. <jsa...@gm...>]

According to the rules a file with a different licensing would not
be allowed to be included as GPLv3 for distribution. A user could
include it for personal use but could not distribute it as GPLv3.

Again this is meant as a friendly exchange of opinions
and is part of my research in software development.

Regards,
John S


On Wed, Feb 11, 2026 at 11:06 AM John Sarabacha <jsa...@gm...>
wrote:

> Hi Carsten,
> So if I wrote a Windows11 application and gave it a GPLv3 licensing and
> included
> the header file "windows.h",  it and all it's nested includes would now be
> GPLv3 and
> Microsoft is forced to release it's source code with any distribution.
> How long do you think it would take before Microsoft police would show up
> at my door?
> I am sure Linus (Linux creator) knew this as well.
>
> Again intended as a friendly exchange,
> Regards,
> John S
>
> On Wed, Feb 11, 2026 at 3:51 AM Carsten Strotmann via Amforth-devel <
> amf...@li...> wrote:
>
>> Hi,
>>
>> On 11 Feb 2026, at 9:32, John Sarabacha wrote:
>>
>> > dedicatedcomputer.ca/test
>> > Please examine the license terms on riscv_pal.h
>>
>> I'm not a lawyer, but in my experience with these kinds of questions,
>> "riscv_pal.h" is clearly part of the final product, included into
>> "dict_prims.c", which is "Licensing Compatible with AmForth (GPL3)", which
>> equals GPLv3, so "riscv_pal.h" must also be licensed under GPLv3.
>>
>> > If I supply this file it doesn't mean I give up my rights under this
>> > license.
>>
>> Well, from the nature of the license and the nature of the code, you've
>> placed the code in "riscv_pal.h" under GPLv3.
>>
>> > Sometimes this freeness is not always on equal terms. Some will take
>> > advantage.
>>
>> Yes, and that is why people choose GPLv3 to prevent that people take
>> advantage.
>>
>> Greetings
>>
>> Carsten
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] GPLv3

[John S. <jsa...@gm...>]

Hi Carsten,
So if I wrote a Windows11 application and gave it a GPLv3 licensing and
included
the header file "windows.h",  it and all it's nested includes would now be
GPLv3 and
Microsoft is forced to release it's source code with any distribution.
How long do you think it would take before Microsoft police would show up
at my door?
I am sure Linus (Linux creator) knew this as well.

Again intended as a friendly exchange,
Regards,
John S

On Wed, Feb 11, 2026 at 3:51 AM Carsten Strotmann via Amforth-devel <
amf...@li...> wrote:

> Hi,
>
> On 11 Feb 2026, at 9:32, John Sarabacha wrote:
>
> > dedicatedcomputer.ca/test
> > Please examine the license terms on riscv_pal.h
>
> I'm not a lawyer, but in my experience with these kinds of questions,
> "riscv_pal.h" is clearly part of the final product, included into
> "dict_prims.c", which is "Licensing Compatible with AmForth (GPL3)", which
> equals GPLv3, so "riscv_pal.h" must also be licensed under GPLv3.
>
> > If I supply this file it doesn't mean I give up my rights under this
> > license.
>
> Well, from the nature of the license and the nature of the code, you've
> placed the code in "riscv_pal.h" under GPLv3.
>
> > Sometimes this freeness is not always on equal terms. Some will take
> > advantage.
>
> Yes, and that is why people choose GPLv3 to prevent that people take
> advantage.
>
> Greetings
>
> Carsten
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] GPLv3

[Carsten S. <ca...@st...>]

Hi,

On 11 Feb 2026, at 9:32, John Sarabacha wrote:

> dedicatedcomputer.ca/test
> Please examine the license terms on riscv_pal.h

I'm not a lawyer, but in my experience with these kinds of questions, "riscv_pal.h" is clearly part of the final product, included into "dict_prims.c", which is "Licensing Compatible with AmForth (GPL3)", which equals GPLv3, so "riscv_pal.h" must also be licensed under GPLv3.

> If I supply this file it doesn't mean I give up my rights under this
> license.

Well, from the nature of the license and the nature of the code, you've placed the code in "riscv_pal.h" under GPLv3.

> Sometimes this freeness is not always on equal terms. Some will take
> advantage.

Yes, and that is why people choose GPLv3 to prevent that people take advantage.

Greetings

Carsten