Hello everyone,

I have been exploring the Forth programming language and specifically the Gforth implementation. I am pondering about its utilization in a "bare metal" context and I'd like to gather some insights from you all.

By "bare metal," I am referring to two distinct yet related definitions:

* Bare metal as running directly on the hardware, without the intervention of an operating system. In other words, Gforth would not operate as a guest application on top of an OS, but rather have direct access to the hardware resources.

* The ability to create an application (a set of words in Forth's context) and cross-compile this application to run natively on the target hardware. This could potentially bypass the need for an intermediary OS, or at least minimize its role, and ideally enhance performance. " Turn Key bare metal"

I am aware that Gforth is typically used as an interpreter running on an operating system, but I am curious if it's possible or practical to use it in a bare metal environment. Moreover, does Gforth offer any cross-compilation capabilities that could be used to create a standalone, native application for a specific hardware platform?

Any insights or experiences shared would be greatly appreciated. Thanks in advance for your time and knowledge.

Best,

On Thursday, June 15, 2023 at 8:13:17 AM UTC-4, SpainHackForth wrote:
> Hello everyone,
>
> I have been exploring the Forth programming language and specifically the Gforth implementation. I am pondering about its utilization in a "bare metal" context and I'd like to gather some insights from you all.
>
> By "bare metal," I am referring to two distinct yet related definitions:
>
> * Bare metal as running directly on the hardware, without the intervention of an operating system. In other words, Gforth would not operate as a guest application on top of an OS, but rather have direct access to the hardware resources.
>
> * The ability to create an application (a set of words in Forth's context) and cross-compile this application to run natively on the target hardware.. This could potentially bypass the need for an intermediary OS, or at least minimize its role, and ideally enhance performance. " Turn Key bare metal"
>
> I am aware that Gforth is typically used as an interpreter running on an operating system, but I am curious if it's possible or practical to use it in a bare metal environment. Moreover, does Gforth offer any cross-compilation capabilities that could be used to create a standalone, native application for a specific hardware platform?
>
> Any insights or experiences shared would be greatly appreciated. Thanks in advance for your time and knowledge.
>
> Best,

Any decent Forth system can be used to write a cross-compiler for a
target system. I made one for my own self-interest (I am a hobbyist)

This was my process:
-Write a Forth Cross-assembler for the target
-Write the Cross-compiler to handle the target memory space and dictionary
-Write the primitives for the target system with Cross-compiler and Assembler
-Write the high level words using the primitives
- Compile the whole thing with the Cross-compiler
-Save the target memory image in a format you can load into memory.

As Chuck Moore put it: (Paraphrased)
"I now had an interpreter than could write an Assembler, that could write
a compiler that could compile an interpreter"

:-)

However if you really want to get some work done in the near future,
I would advise using a commercial system with all that stuff and more, built in.
Forth Cross-compilers are kind of hard IMHO.

On 15 Jun 2023 at 14:13:15 CEST, "SpainHackForth" <jemo07@gmail.com> wrote:

> I have been exploring the Forth programming language and specifically the
> Gforth implementation. I am pondering about its utilization in a "bare metal"
> context and I'd like to gather some insights from you all.

What hardware are you thinking of? It matters. A 32 bit ARM/Cortex is likely
to be in your sights. What peripherals and protocols do you need.

> By "bare metal," I am referring to two distinct yet related definitions:

> * Bare metal as running directly on the hardware, without the intervention of
> an operating system. In other words, Gforth would not operate as a guest
> application on top of an OS, but rather have direct access to the hardware
> resources.

If you must use FOSS, ignore what I say - the commercial vendors have been
selling and using good cross-compilers for decades.

Use a cross-compiler - virtually all serious Forth kernels are cross-compiled
to begin with. Writing a USB driver in assembler is high-level masochism.

> * The ability to create an application (a set of words in Forth's context) and
> cross-compile this application to run natively on the target hardware. This
> could potentially bypass the need for an intermediary OS, or at least minimize
> its role, and ideally enhance performance. " Turn Key bare metal"

It is also possible (using a commercial Forth cross compiler from MPE) to use
the Forth with C libraries. This approach has been used very successfully by
one of the world's largest companies.
>
> I am aware that Gforth is typically used as an interpreter running on an
> operating system, but I am curious if it's possible or practical to use it in
> a bare metal environment. Moreover, does Gforth offer any cross-compilation
> capabilities that could be used to create a standalone, native application for
> a specific hardware platform?

gForth is primarily a desktop application. Serious cross compilers come from
Forth Inc. and MPE.

Note that I have both UK and Spanish phone numbers. I live in Murcia.

Stephen
--
Stephen Pelc, stephen@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

SpainHackForth <jemo07@gmail.com> writes:
>Hello everyone,
>
>I have been exploring the Forth programming language and specifically the G=
>forth implementation. I am pondering about its utilization in a "bare metal=
>" context and I'd like to gather some insights from you all.
>
>By "bare metal," I am referring to two distinct yet related definitions:
>
>* Bare metal as running directly on the hardware, without the intervention =
>of an operating system. In other words, Gforth would not operate as a guest=
> application on top of an OS, but rather have direct access to the hardware=
> resources.
>
>* The ability to create an application (a set of words in Forth's context) =
>and cross-compile this application to run natively on the target hardware. =
>This could potentially bypass the need for an intermediary OS, or at least =
>minimize its role, and ideally enhance performance. " Turn Key bare metal"=
>=20
>
>I am aware that Gforth is typically used as an interpreter running on an op=
>erating system, but I am curious if it's possible or practical to use it in=
> a bare metal environment.

There is Gforth EC for various architectures, usually for use on bare
metal; what it includes depends on the specific port; it's certainly
not full Gforth.

There are a number of more-maintained free and proprietary Forth
systems for small systems.

>Moreover, does Gforth offer any cross-compilatio=
>n capabilities that could be used to create a standalone, native applicatio=
>n for a specific hardware platform?

Gforth has a cross-compiler (cross.fs), which is used for building the
Gforth kernel and for building Gforth EC. You can also use it for
building applications, but cross-compilation in the cross.fs way (with
a hard compilation/run-time boundary) misses a number of very
important features of Forth; the thethered/umbilical systems from
commercial vendors try to provide some of these features.

The free systems like Mecrisp instead give you a proper Forth system
running on the small system, with the disadvantage that the Forth
system occupies more memory on the small system than a tethered
cross-compiler running on the PC, with a small executive on the small
system.

cross.fs and Gforth EC is also not well documented, they are more a
"Use the Source, Luke" thing.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022 proceedings: http://www.euroforth.org/ef22/papers/

I appreciate your responses and insights. I should have been more specific initially; the intended CPU for this project is based on the ArmV8 architecture, specifically in the range of 6 to 8 cores.

Recently, I created an assembler for this platform, last week. The corresponding code can be located at this link:

https://gist.github.com/jemo07/969f89c4dc20483074c4833200964821

My next task is to generate a set of test codes. Currently, the assembler I have developed is akin to Brad Rodriquez's Z80 code. Moreover, I have a work in progress (WIP) for an ARMv8 CPU emulator on Gforth, which I will share as soon as it has been adequately tested.

Anton, I stumbled upon FForth, but I was unable to compile it. I haven't yet dedicated much attention to the code, but I'm wondering if it's still an ongoing project or if it's been discontinued?

In the Forth Discord server, which has a fantastic user interface, I posed the following question: What really happens when you look inside a Forth binary, particularly one designed to be a turnkey application? My understanding is that it would involve a bootstrap to activate the CPU, followed by a pointer initiating the execution of the word that launches the application from the outer interpreter. Is that correct? Subsequently, it uses DTC, or whatever dictionary strategy the code employs, correct? My hypothesis is that if we have the template for most of that part of the binary, we could potentially develop a “transcompiler” that can create the application (just and addition to the Dictionary format). Is this plausible?

I guess I might be describing an umbilical whatchamagig…. but this is how it would work in my mind:

It’s a hand crafted binary template, it has the CPU / outer interpreter loop / and minimal dictionary structure… you write your code and the resulting words are cross compiled to you target machine code and added to the binary I just described… something like.

CPU Initialization: This would be the first part of your binary. It would contain the necessary instructions to set up the CPU and prepare it for executing your Forth program. This would typically involve setting up registers, stack pointers, and possibly loading necessary system services.
Forth Dictionary Structure: This would be the next part of your binary. It would contain your Forth words and their corresponding definitions. Each word would be a key into this dictionary, and the value would be the code associated with that word. This dictionary would be your "inner interpreter" which processes the input and executes the corresponding Forth words.
Cross-Compiler: The cross-compiler would take Forth source code and compile it into machine code for your target architecture. This would involve parsing the source code, generating the corresponding opcodes for your CPU architecture, and integrating these opcodes into the dictionary structure.
Forth Source Code: Lastly, you would have the actual Forth source code that you want to run on the target architecture. This would be compiled by your cross-compiler into the appropriate machine code and added to the dictionary.

Is there a functional FOSS umbilical Forth that I can look at and test?

Anyways, this approach would be much better than the other thingy I was looking at, feel free to give constructive criticism on the following; https://github.com/jemo07/TolerantFORTH

SpainHackForth <jemo07@gmail.com> writes:
>I appreciate your responses and insights. I should have been more specific =
>initially; the intended CPU for this project is based on the ArmV8 architec=
>ture, specifically in the range of 6 to 8 cores.

Unfortunately, "ARMv8" is ambiguous. There is ARMv8-A (with the A64
instruction set), ARMv8-M (with not A64, but A32 and T32), and ARMv8-R
(I think it has A64).

> https://gist.github.com/jemo07/969f89c4dc20483074c4833200964821

The mnemonics in the code look more like 6502 to me, not ARM A32/T32
or A64.

>Anton, I stumbled upon FForth, but I was unable to compile it. I haven't ye=
>t dedicated much attention to the code, but I'm wondering if it's still an =
>ongoing project or if it's been discontinued?

If you are thinking about <https://github.com/AntonErtl/fforth>, the
first sentence is: "Fforth in not yet in a usable state." It has been
that way for some time, and it stays there until I find the time to
finish it.

The plan is not to turn it into a maintained software, though. So you
take it, do your own changes, and don't have to worry about having to
reconcile your changes with the maintainer's changes. If you want a
maintained system, go for Gforth.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022 proceedings: http://www.euroforth.org/ef22/papers/

On Thursday, June 15, 2023 at 11:00:38 PM UTC+2, Anton Ertl wrote:
> SpainHackForth
> >I appreciate your responses and insights. I should have been more specific =
> >initially; the intended CPU for this project is based on the ArmV8 architec> >ture, specifically in the range of 6 to 8 cores.
> Unfortunately, "ARMv8" is ambiguous. There is ARMv8-A (with the A64
> instruction set), ARMv8-M (with not A64, but A32 and T32), and ARMv8-R
> (I think it has A64).
>
> > https://gist.github.com/jemo07/969f89c4dc20483074c4833200964821
>
> The mnemonics in the code look more like 6502 to me, not ARM A32/T32
> or A64.

Hello Anton,
Ah yes, wrong code base… that was the code for the 6502 simulator from Alexander, it’s what happen when you do things on an Ipad…

The armv8 is for the AArch64, so armv8-A. I’ll go find that assembler a repost the message. this might be part of it…

\ CPU Definitions
: CPU <BUILDS C, DOES> C@ C, MEM ;
00 CPU BRK, 18 CPU CLC, D8 CPU CLD, 58 CPU CLI,
B8 CPU CLV, CA CPU DEX, 88 CPU DEY, E8 CPU INX,
C8 CPU INY, EA CPU NOP, 48 CPU PHA, 08 CPU PHP,
68 CPU PLA, 28 CPU PLP, 40 CPU RTI, 60 CPU RTS,
38 CPU SEC, F8 CPU SED, 78 CPU SEI, AA CPU TAX,
A8 CPU TAY, BA CFU TSX, 8A CPU TXA, 9A CPU TXS,
98 CPU TYA ;

As for the FForth, great, I will look into it with a little more care and reuse as much as possible :D.!!

Cheers!

In article <29665766-6892-4d80-a60d-2fa728612c5an@googlegroups.com>,
SpainHackForth <jemo07@gmail.com> wrote:
>Hello everyone,
>
>I have been exploring the Forth programming language and specifically
>the Gforth implementation. I am pondering about its utilization in a
>"bare metal" context and I'd like to gather some insights from you all.
>
>By "bare metal," I am referring to two distinct yet related definitions:
>
>* Bare metal as running directly on the hardware, without the
>intervention of an operating system. In other words, Gforth would not
>operate as a guest application on top of an OS, but rather have direct
>access to the hardware resources.
>
>* The ability to create an application (a set of words in Forth's
>context) and cross-compile this application to run natively on the
>target hardware. This could potentially bypass the need for an
>intermediary OS, or at least minimize its role, and ideally enhance
>performance. " Turn Key bare metal"

>
>I am aware that Gforth is typically used as an interpreter running on an
>operating system, but I am curious if it's possible or practical to use
>it in a bare metal environment. Moreover, does Gforth offer any
>cross-compilation capabilities that could be used to create a
>standalone, native application for a specific hardware platform?

The ciforth implementations have these capabilities and are more
"bare bones" than a typical c-program. They don't require any
libraries installed on the system. Only if you want to debug,
it requires a single source Forth library file.
(lina i86 arm riscv on linux, wina on MS-Windows, all 32 and 64 bits)

>
>Any insights or experiences shared would be greatly appreciated. Thanks
>in advance for your time and knowledge.
>
>Best,
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <fe93dabd-6196-4bab-818d-6c56537f4581n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Thursday, June 15, 2023 at 8:13:17 AM UTC-4, SpainHackForth wrote:
>> Hello everyone,
>>
>> I have been exploring the Forth programming language and specifically
>the Gforth implementation. I am pondering about its utilization in a
>"bare metal" context and I'd like to gather some insights from you all.
>>
>> By "bare metal," I am referring to two distinct yet related definitions:
>>
>> * Bare metal as running directly on the hardware, without the
>intervention of an operating system. In other words, Gforth would not
>operate as a guest application on top of an OS, but rather have direct
>access to the hardware resources.
>>
>> * The ability to create an application (a set of words in Forth's
>context) and cross-compile this application to run natively on the
>target hardware. This could potentially bypass the need for an
>intermediary OS, or at least minimize its role, and ideally enhance
>performance. " Turn Key bare metal"
>>
>> I am aware that Gforth is typically used as an interpreter running on
>an operating system, but I am curious if it's possible or practical to
>use it in a bare metal environment. Moreover, does Gforth offer any
>cross-compilation capabilities that could be used to create a
>standalone, native application for a specific hardware platform?
>>
>> Any insights or experiences shared would be greatly appreciated.
>Thanks in advance for your time and knowledge.
>>
>> Best,
>
>Any decent Forth system can be used to write a cross-compiler for a
>target system. I made one for my own self-interest (I am a hobbyist)
>
>This was my process:
>-Write a Forth Cross-assembler for the target
>-Write the Cross-compiler to handle the target memory space and dictionary
>-Write the primitives for the target system with Cross-compiler and Assembler
>-Write the high level words using the primitives
>- Compile the whole thing with the Cross-compiler
>-Save the target memory image in a format you can load into memory.
>
>As Chuck Moore put it: (Paraphrased)
>"I now had an interpreter than could write an Assembler, that could write
>a compiler that could compile an interpreter"
>
> :-)
>
>However if you really want to get some work done in the near future,
>I would advise using a commercial system with all that stuff and more,
>built in.
>Forth Cross-compilers are kind of hard IMHO.

Are they hard? Maybe, but it must not be involved.
If you leave out all the crap (c and linking imposes on the executable)
you are down to two screens. (Empty lines not shown.)
You must be willing to write the ELF headers yourself, without going
to 5 layers of convolution.

0 ( SAVE-SYSTEM TURNKEY ) CF: ?LI ?64 HEX \ AvdH/CH B5jun24
1 \ The magic number marking the start of an ELF header
2 CREATE MAGIC 7F C, &E C, &L C, &F C,
3 \ Return the START of the ``ELF'' header.
4 : SM BM BEGIN DUP MAGIC 4 CORA WHILE 1- REPEAT ;
5 SM 20 + @ SM + 20 + CONSTANT D-SIZE \ Dictionary size.
6 D-SIZE 8 + CONSTANT G-SIZE
7 \ Return the VALUE of ``HERE'' when this forth started.
8 : HERE-AT-STARTUP 'DP >DFA @ +ORIGIN @ ;
9 \ Kill sections
10 : _prepare_header SM 28 + @ IF 0 SM 28 + ! 1 SM 38 + ! THEN ;
11

0 ( SAVE-SYSTEM TURNKEY ) CF: ?HS HEX \ AH B6dec21
2 \ ISO Save the system in a file with NAME .
3 : SAVE-SYSTEM _prepare_header
4 HERE BM - D-SIZE ! \ Fill in dict size (.text)
5 U0 @ 0 +ORIGIN 40 CELLS MOVE \ Save user variables)
6 \ Now write it. Consume NAME here.
7 SM HERE OVER - 2SWAP PUT-FILE ;
8
9 \ Save a system to do ACTION in a file with NAME .
10 : TURNKEY ROT >DFA @ 'ABORT >DFA ! SAVE-SYSTEM BYE ;

(There is some conditional compilation here, for windows 32bit
different screens are loaded.)

Example
~/PROJECT/ciforths/ciforth$ cat hellow.frt
: hw ." Hello world!" CR ;
~/PROJECT/ciforths/ciforth$ lina -c hellow.frt
~/PROJECT/ciforths/ciforth$ hellow
Hello world!

This example works portably on at least 8 operatings systems
mentionned.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Thursday, June 15, 2023 at 6:34:52 AM UTC-7, Stephen Pelc wrote:
> gForth is primarily a desktop application. Serious cross compilers come from
> Forth Inc. and MPE.

Stephen Pelc is a super salesman! Likely learned the art from Zig Ziglar!
Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
Stephen Pelc is on the Forth-200x committee, implying that he is an expert
in Forth standards, but yet VFX fails to compile valid ANS-Forth code.

I wrote MFX for the MiniForth processor. This was an assembler, simulator
and Forth cross-compiler. Was it a serious cross-compiler though???

On Thursday, 22 June 2023 at 03:11:11 UTC+1, Hugh Aguilar wrote:
> On Thursday, June 15, 2023 at 6:34:52 AM UTC-7, Stephen Pelc wrote:
> > gForth is primarily a desktop application. Serious cross compilers come from
> > Forth Inc. and MPE.

> Stephen Pelc is a super salesman! Likely learned the art from Zig Ziglar!

Can you please switch your brain on.
Stephen owns MPE and its products.
So obviously he has to design/modify the product.
So he has to sell the product to interested customers.
Is this a secret for you I have just revealed?

> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant..

VFX is probably as ANS compliant as necesary.
MPE customers will push, if more is needed.

> Stephen Pelc is on the Forth-200x committee, implying that he is an expert

Here you get agressive.

This is work done for free for the Forth Community.
How much of your time do you use to add to the Forth community?

And:
He must be more of an expert than you, as he is more successful.

> in Forth standards, but yet VFX fails to compile valid ANS-Forth code.

It is an MPE decision to be as compatible as needed.

>
> I wrote MFX for the MiniForth processor. This was an assembler, simulator
> and Forth cross-compiler. Was it a serious cross-compiler though???

On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpitaske@gmail.com> wrote:
>
>> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
>
> VFX is probably as ANS compliant as necesary.
> MPE customers will push, if more is needed.

Juergen, give it up. Hugh is clueless.

The bug he's talking about was fixed months and months ago. However, Hugh
still brags about bugs he found (and that were fixed) eight or ten years ago.
Hugh has published several versions of his novice package - there are three
on this box, all claiming 2009 copyright and a BSD licence.

768 lines
2379 lines
4679 lines (BUGGY)

He had a hissy fit a few weeks back, demanding that we stop looking at or
using it. I'll be happy to oblige him from now on.

Stephen
--
Stephen Pelc, stephen@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

On Thursday, 22 June 2023 at 10:19:34 UTC+1, Stephen Pelc wrote:
> On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
> >
> >> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
> >
> > VFX is probably as ANS compliant as necesary.
> > MPE customers will push, if more is needed.

> Juergen, give it up. Hugh is clueless.
>
> The bug he's talking about was fixed months and months ago. However, Hugh
> still brags about bugs he found (and that were fixed) eight or ten years ago.
> Hugh has published several versions of his novice package - there are three
> on this box, all claiming 2009 copyright and a BSD licence.
>
> 768 lines
> 2379 lines
> 4679 lines (BUGGY)
>
> He had a hissy fit a few weeks back, demanding that we stop looking at or
> using it. I'll be happy to oblige him from now on.
> 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

For the ones who are in the know - his comments do not matter anyway.

For the ones who are not in the know - it should be put into perspective.

So, can you please confirm, that the current VFX version is ANS compliant.
A confirmation from MPE to the rest of the world.
Or where there are limits / limitations.

On 22/06/2023 12:11 pm, Hugh Aguilar wrote:
> On Thursday, June 15, 2023 at 6:34:52 AM UTC-7, Stephen Pelc wrote:
>> gForth is primarily a desktop application. Serious cross compilers come from
>> Forth Inc. and MPE.
>
> Stephen Pelc is a super salesman! Likely learned the art from Zig Ziglar!
> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
> Stephen Pelc is on the Forth-200x committee, implying that he is an expert
> in Forth standards, but yet VFX fails to compile valid ANS-Forth code.
>
> I wrote MFX for the MiniForth processor. This was an assembler, simulator
> and Forth cross-compiler. Was it a serious cross-compiler though???

Only as serious as its author and Testra who commissioned it say it was.
Nobody else has seen it.

On Thursday, June 22, 2023 at 2:19:34 AM UTC-7, Stephen Pelc wrote:
> On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
> >
> >> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
> >
> > VFX is probably as ANS compliant as necesary.
> > MPE customers will push, if more is needed.
> Juergen, give it up. Hugh is clueless.

Stephen Pelc and Juergen Pintaske are inextricably linked forever!

I'm not "clueless" --- I am telling the truth that Stephen Pelc sabotaged VFX
to prevent my novice-package from working under VFX. He admitted this here:
https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/wMen0WkWAQAJ
Stephen Pelc is using a gross euphemism when he describes his sabotage
as a "bug" --- Stephen Pelc is a liar!

On Thursday, February 23, 2023 at 5:53:49 AM UTC-7, Stephen Pelc wrote:
> On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com>
> wrote:
>
> > The bug is that this ANS-Forth compliant code causes VFX to crash:
> > ------------------------------------------
> > : lit, ( val -- ) \ runtime: -- val
> > postpone literal ;
> > ------------------------------------------
>
> For the moment define LIT, as
>
> : lit, ( val -- ) \ runtime: -- val
> postpone literal ; doNotSin
>
> An upcoming version of VFX may/will use a different fix and will not require
> DONOTSIN.
>
> Stephen

Stephen Pelc's sabotage also hit my IF disambiguifier, and this sabotage is
also undone with the DONOTSIN word. I'm the primary person who uses
the IF disambiguifier, so Stephen Pelc was obviously aiming his sabotage
at me (Bernd Paysan also uses disambiguifiers in his MiniOOF package,
but most likely Stephen Pelc was unaware of this and didn't realize that
his sabotage would hit anybody other than me).

If Stephen Pelc is going to be a super-salesman for MPE on comp.lang.forth,
as he was doing in this thread, he should always explain to his potential
customers what the word "sin" means, so this potential customers can
determine whether or not they are sinners in the eyes of Stephen Pelc.
Nobody will buy MPE products without first being assured that they aren't
a sinner, and he won't considered them to be sinners in the future.
What a bummer it would be for a customer to pay big money for VFX and then
have Stephen Pelc sabotage VFX to prevent the customer's ANS-Forth code
from working because Stephen Pelc has determined the customer to be a sinner.

On Thursday, 22 June 2023 at 18:04:58 UTC+1, Hugh Aguilar wrote:
> On Thursday, June 22, 2023 at 2:19:34 AM UTC-7, Stephen Pelc wrote:
> > On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
> > >
> > >> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
> > >
> > > VFX is probably as ANS compliant as necesary.
> > > MPE customers will push, if more is needed.
> > Juergen, give it up. Hugh is clueless.
> Stephen Pelc and Juergen Pintaske are inextricably linked forever!
>
> I'm not "clueless" --- I am telling the truth that Stephen Pelc sabotaged VFX
> to prevent my novice-package from working under VFX. He admitted this here:
> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/wMen0WkWAQAJ
> Stephen Pelc is using a gross euphemism when he describes his sabotage
> as a "bug" --- Stephen Pelc is a liar!
>
> On Thursday, February 23, 2023 at 5:53:49 AM UTC-7, Stephen Pelc wrote:
> > On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com>
> > wrote:
> >
> > > The bug is that this ANS-Forth compliant code causes VFX to crash:
> > > ------------------------------------------
> > > : lit, ( val -- ) \ runtime: -- val
> > > postpone literal ;
> > > ------------------------------------------
> >
> > For the moment define LIT, as
> >
> > : lit, ( val -- ) \ runtime: -- val
> > postpone literal ; doNotSin
> >
> > An upcoming version of VFX may/will use a different fix and will not require
> > DONOTSIN.
> >
> > Stephen
>
> Stephen Pelc's sabotage also hit my IF disambiguifier, and this sabotage is
> also undone with the DONOTSIN word. I'm the primary person who uses
> the IF disambiguifier, so Stephen Pelc was obviously aiming his sabotage
> at me (Bernd Paysan also uses disambiguifiers in his MiniOOF package,
> but most likely Stephen Pelc was unaware of this and didn't realize that
> his sabotage would hit anybody other than me).
>
> If Stephen Pelc is going to be a super-salesman for MPE on comp.lang.forth,
> as he was doing in this thread, he should always explain to his potential
> customers what the word "sin" means, so this potential customers can
> determine whether or not they are sinners in the eyes of Stephen Pelc.
> Nobody will buy MPE products without first being assured that they aren't
> a sinner, and he won't considered them to be sinners in the future.
> What a bummer it would be for a customer to pay big money for VFX and then
> have Stephen Pelc sabotage VFX to prevent the customer's ANS-Forth code
> from working because Stephen Pelc has determined the customer to be a sinner.

PLEASE SWITCH ON YOUR BRAIN IF THIS IS STILL POSSIBLE.

I have nothing to do with MPE for many years - discussed here in the past.
And you had thrown shit then..
Well, your brain cannot keep the information anymore - how sad, but just how biology works.

BUT I CANNOT ACCEPT YOUR BULLSHIT without reacting;
there are more people who like Forth
and you got the name
FORTH KILLER in the past for good reasons..

On Thursday, June 22, 2023 at 2:19:34 AM UTC-7, Stephen Pelc wrote:
> On 22 Jun 2023 at 10:51:07 CEST, "Jurgen Pitaske" <jpit...@gmail.com> wrote:
> >
> >> Stephen Pelc is neglecting to mention that VFX is not ANS-Forth compliant.
> >
> > VFX is probably as ANS compliant as necesary.
> > MPE customers will push, if more is needed.
> Juergen, give it up. Hugh is clueless.
>
> The bug he's talking about was fixed months and months ago. However, Hugh
> still brags about bugs he found (and that were fixed) eight or ten years ago.
> Hugh has published several versions of his novice package - there are three
> on this box, all claiming 2009 copyright and a BSD licence.
>
> 768 lines
> 2379 lines
> 4679 lines (BUGGY)
>
> He had a hissy fit a few weeks back, demanding that we stop looking at or
> using it. I'll be happy to oblige him from now on.
> Stephen

Matthias Koch recently sent me an email in which he says:
---------------------------------------------------------------------------------------------------------
On Fri, Jul 21, 2023 at 5:37 AM Matthias Koch <m.cook@gmx.net> wrote:
> I'm not an altruist --- I will never provide open-source software for the good of society.

Oh. Is this you, or someone else with same name?
https://www.forth2020.org/beginners-to-forth/a-novice-package
---------------------------------------------------------------------------------------------------------
Matthias Koch is effectively accusing me of being one of the Forth-200x sycophants
who crawl on their knees and beg Stephen Pelc to accept their contributions..
On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
They are implying that I'm on my knees offering them my meager contribution..
I have actually said multiple times that I do not give the Forth-200x permission
to possess my novice package. I insist that the Forth-200x committee stop posting
this old copy of the novice package. I insisted that SVFIG also stop posting my code
and they eventually complied. The Forth-200x committee have an old copy that they
obtained from SVFIG, most likely dating back to 2010.

Stephen Pelc and all of the Forth-200x committee members are losers!
They are obsessed with trying to prove to the world that they are leaders of
the Forth community, and to do this they need to have followers.
This is why they continue to pretend that I'm their follower, although I'm not.
Stephen Pelc and all of the Forth-200x committee members disgust me.
I want them to leave me alone --- they are losers that I don't associate with.

On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
> ...
> https://www.forth2020.org/beginners-to-forth/a-novice-package
> ...
> On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
> ...
> I insist that the Forth-200x committee stop posting
> this old copy of the novice package.
Forth2020 has a contact page where you can make your request:

https://www.forth2020.org/home/contact

On Friday, July 21, 2023 at 9:06:34 PM UTC-7, dxforth wrote:
> On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
> > ...
> > https://www.forth2020.org/beginners-to-forth/a-novice-package
> > ...
> > On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
> > ...
> > I insist that the Forth-200x committee stop posting
> > this old copy of the novice package.
> Forth2020 has a contact page where you can make your request:
>
> https://www.forth2020.org/home/contact

Well, I sent a message to that contact page.
I have already told Stephen Pelc multiple times to stop distributing
my software against my will and he has not complied. I doubt that
there is anybody at Forth-200x who can overrule him.

On their page attacking me the say: "grateful to Hugh Aguilar and SVFIG."
They are liars!
I downloaded the zip file to find out what they have, and it is a new version.
I never gave them that software and I never gave them permission to
distribute it, so they are lying when they say that they are grateful to me
for giving it to them. Also, they are lying when they say that they got it
from SVFIG. I never gave SVFIG the new copy that contains STRING-STACK.
I told SVFIG to stop distributing my software a long time prior to 2020
and they did. I never distributed this new version containing STRING-STACK
publicly. I gave it to a handful of people that seemed trustworthy but told
them that it was not for public distribution. Apparently one of them handed
it over to the Forth-200x committee for public distribution. The most likely
suspect is John Hart. At Testra they have been brown-nosing Stephen Pelc
in an effort to convince him to buy their RACE processor --- this is why
Tom Hart attacked me on comp.lang.forth:
https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0/m/mvVy-GN7AwAJ
It seems likely that John Hart handed my software to Stephen Pelc against
my will in an effort to brown-nose Stephen Pelc. It seems likely that Tom Hart
or John Hart or both believe that if they brown-nose Stephen Pelc enough he
will make them members of the Forth-200x committee so they can pretend
to be great leaders of the Forth community --- the Forth-200x committee is
in the business of pretending to be great leaders of the Forth community.

All of the Forth-200x committee disgust me. They are so desperate to
appear to be leaders that they continue year after year to pretend that
I'm their loyal little follower. I'm not their follower! They disgust me!

On 24/07/2023 5:29 am, Hugh Aguilar wrote:
> On Friday, July 21, 2023 at 9:06:34 PM UTC-7, dxforth wrote:
>> On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
>>> ...
>>> https://www.forth2020.org/beginners-to-forth/a-novice-package
>>> ...
>>> On this Forth-200x page attacking me, they say: "grateful to Hugh Aguilar and SVFIG."
>>> ...
>>> I insist that the Forth-200x committee stop posting
>>> this old copy of the novice package.
>> Forth2020 has a contact page where you can make your request:
>>
>> https://www.forth2020.org/home/contact
>
> Well, I sent a message to that contact page.
> I have already told Stephen Pelc multiple times to stop distributing
> my software against my will and he has not complied. I doubt that
> there is anybody at Forth-200x who can overrule him.

Forth2020 is a Forth appreciation group run by Peter Forth. From what
you say you have now contacted the latter about removal of the Novice
pack from their webpage.

> I downloaded the zip file to find out what they have, and it is a new version.
> I never gave them that software and I never gave them permission to
> distribute it, so they are lying when they say that they are grateful to me
> for giving it to them. Also, they are lying when they say that they got it
> from SVFIG. I never gave SVFIG the new copy that contains STRING-STACK.

Distribution of BSD licensed material isn't illegal. AFAICS Forth2020
posted your material in good faith under the conditions of the licence
and in conformity with their general goal of promoting Forth.

On Sunday, July 23, 2023 at 8:00:22 PM UTC-7, dxforth wrote:
> Forth2020 is a Forth appreciation group run by Peter Forth. From what
> you say you have now contacted the latter about removal of the Novice
> pack from their webpage.

Oh, I didn't realize that was Peter Forth.
The name Forth2020 implied that this was the Forth-200x committee
who now call their "standard" Forth-2020.

The Forth-200x committee have a history of pretending that I'm
their follower. They listed me as a contributor to the Paysan-faked
quotations although I had always been opposed. I was opposed
to the Paysan-faked quotations from the beginning, prior to me
writing the rquotations that actually work.

Anyway, I need to get my code off the internet.
I don't want the Forth-200x committee to obtain my source-code.
They don't deserve to be taught Forth programming.
For example, my linked-list code is in there. I don't want them to
learn how to implement a linked-list --- they have Peter Knaggs
failed attempt at a linked-list:
https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ
When a person is this incompetent, he is not worth teaching.

In article <7d943c24-0236-47ff-83d4-7789d9fd9894n@googlegroups.com>,
Hugh Aguilar <hughaguilar96@gmail.com> wrote:
>On Friday, July 21, 2023 at 9:06:34 PM UTC-7, dxforth wrote:
>> On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
>> > ...
>> > https://www.forth2020.org/beginners-to-forth/a-novice-package
>> > ...
>> > On this Forth-200x page attacking me, they say: "grateful to Hugh
>Aguilar and SVFIG."
>> > ...
>> > I insist that the Forth-200x committee stop posting
>> > this old copy of the novice package.
>> Forth2020 has a contact page where you can make your request:
>>
>> https://www.forth2020.org/home/contact
>
>Well, I sent a message to that contact page.
>I have already told Stephen Pelc multiple times to stop distributing
>my software against my will and he has not complied. I doubt that
>there is anybody at Forth-200x who can overrule him.

Given that it was original distributed under a free license
you cannot "tell" people anything. You can politely ask to
not distribute, but that's all.

<SNIP>
>All of the Forth-200x committee disgust me. They are so desperate to
>appear to be leaders that they continue year after year to pretend that
>I'm their loyal little follower. I'm not their follower! They disgust me!

The Forth commitee and the conference organizer contribute greatly,
contrary to you-know-who.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Monday, July 24, 2023 at 1:17:46 AM UTC-7, none albert wrote:
> >All of the Forth-200x committee disgust me. They are so desperate to
> >appear to be leaders that they continue year after year to pretend that
> >I'm their loyal little follower. I'm not their follower! They disgust me!
> The Forth commitee and the conference organizer contribute greatly,
> contrary to you-know-who.

The Forth committee and the conference organizer have contributed
exactly nothing in regard to a string-stack. All of the self-proclaimed
Forth experts have failed miserably at implementing a string-stack
in the the entire history of the Forth language, which is about 50 years.

On Sunday, March 29, 2020 at 5:27:53 PM UTC-7, hughag...@gmail.com wrote:
> On Tuesday, June 25, 2019 at 3:35:43 PM UTC-7, Stephen Pelc wrote:
> > On Tue, 25 Jun 2019 06:39:51 -0700 (PDT), hughag...@gmail.com
> > wrote:
> >
> > >I don't know what they have in Africa, but I doubt that it is
> > >any better than America, Europe, Russia, etc..
> > >I stand by what I said.
> > >There is nothing comparable in quality on any continent.
> >
> > You are just demonstrating your ignorance and your failure to
> > accept that anyone else can do better than you.
> >
> > Stephen
>
> Stephen Pelc doesn't have any working code, and I don't think he is
> capable of implementing a string-stack because he doesn't know
> what COW (copy-on-write) is.
> He has done nothing himself, but he says that anyone can do better than me.

I wrote STRING-STACK.4TH in 2017. It was somewhat difficult, but I finished
the job in a couple of weeks working evenings and weekends.
When I started, I didn't know what COW (copy-on-write) was either. I figured this out
on my own. It seemed obvious. It was only later on that I learned the term COW
and learned that this technique was already well known --- I wasn't surprised that
I wasn't the first to invent this because it was obvious.

What is pathetic about the Forth-200x committee is that none of them
know about this obvious technique and none of them have succeeded
in writing a string-stack that used COW in half a century. Stephen Pelc doesn't
have any source-code, and there is no evidence to indicate that he knows what
COW is. All he has is a claim that an anonymous African implemented a
string-stack 30 years ago that is far superior to mine. This is just typical
Stephen Pelc bullshit. Most likely the anonymous African's string-stack was
just a rework of Wil Baden's crap code that doesn't use COW. The Forth-200x
committee are failures! They don't understand basic computer science ideas
that any high-school student would know about. They contribute nothing!

On Tuesday, 25 July 2023 at 03:52:01 UTC+1, Hugh Aguilar wrote:
> On Monday, July 24, 2023 at 1:17:46 AM UTC-7, none albert wrote:
> > >All of the Forth-200x committee disgust me. They are so desperate to
> > >appear to be leaders that they continue year after year to pretend that
> > >I'm their loyal little follower. I'm not their follower! They disgust me!
> > The Forth commitee and the conference organizer contribute greatly,
> > contrary to you-know-who.
> The Forth committee and the conference organizer have contributed
> exactly nothing in regard to a string-stack. All of the self-proclaimed
> Forth experts have failed miserably at implementing a string-stack
> in the the entire history of the Forth language, which is about 50 years.
>
> On Sunday, March 29, 2020 at 5:27:53 PM UTC-7, hughag...@gmail.com wrote:
> > On Tuesday, June 25, 2019 at 3:35:43 PM UTC-7, Stephen Pelc wrote:
> > > On Tue, 25 Jun 2019 06:39:51 -0700 (PDT), hughag...@gmail.com
> > > wrote:
> > >
> > > >I don't know what they have in Africa, but I doubt that it is
> > > >any better than America, Europe, Russia, etc..
> > > >I stand by what I said.
> > > >There is nothing comparable in quality on any continent.
> > >
> > > You are just demonstrating your ignorance and your failure to
> > > accept that anyone else can do better than you.
> > >
> > > Stephen
> >
> > Stephen Pelc doesn't have any working code, and I don't think he is
> > capable of implementing a string-stack because he doesn't know
> > what COW (copy-on-write) is.
> > He has done nothing himself, but he says that anyone can do better than me.
>
> I wrote STRING-STACK.4TH in 2017. It was somewhat difficult, but I finished
> the job in a couple of weeks working evenings and weekends.
> When I started, I didn't know what COW (copy-on-write) was either. I figured this out
> on my own. It seemed obvious. It was only later on that I learned the term COW
> and learned that this technique was already well known --- I wasn't surprised that
> I wasn't the first to invent this because it was obvious.
>
> What is pathetic about the Forth-200x committee is that none of them
> know about this obvious technique and none of them have succeeded
> in writing a string-stack that used COW in half a century. Stephen Pelc doesn't
> have any source-code, and there is no evidence to indicate that he knows what
> COW is. All he has is a claim that an anonymous African implemented a
> string-stack 30 years ago that is far superior to mine. This is just typical
> Stephen Pelc bullshit. Most likely the anonymous African's string-stack was
> just a rework of Wil Baden's crap code that doesn't use COW. The Forth-200x
> committee are failures! They don't understand basic computer science ideas
> that any high-school student would know about. They contribute nothing!

SHUT UP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
STOP THROWING YOUR SHIT! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Go back to your mental home and take your medication.

MPE has been one of the few Forth suppliers for many decades.
And this includes Stephen Pelc as the owner.
If their product is what you like or not - who cares???
The customers decide.

What you claim is what gives you satisfaction - nothing to do with reality or business.

You throw shit at the ones who keep Forth alive.
Only here you can dump your silly comments as you cannot get thrown out.

The only organisation you cannot escape fortunately
is the one of undertakers
who will clean up your act and will make the world a better place.

On 25/07/2023 12:51 pm, Hugh Aguilar wrote:
>
> Most likely the anonymous African's string-stack was
> just a rework of Wil Baden's crap code that doesn't use COW.

Which Wil Baden code was that? I'm not aware string stacks ever figured
highly in Forth if the literature is any indicator. Low use and lack of
development often go hand in hand. Even if someone advances the technology,
there's no guarantee it will be picked up due to lack of demand. What
definitely doesn't help is burying it.