Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using Gforth as Bare Metal: Feasibility and Cross-Compilation Possibilities
705 views
Skip to first unread message
SpainHackForth
Jun 15, 2023, 8:13:17 AM6/15/23
to
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,
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,
Brian Fox
Jun 15, 2023, 9:24:04 AM6/15/23
to
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.
Stephen Pelc
Jun 15, 2023, 9:34:52 AM6/15/23
to
On 15 Jun 2023 at 14:13:15 CEST, "SpainHackForth" <jem...@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
> 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.
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.
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"
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
> 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?
Forth Inc. and MPE.
Note that I have both UK and Spanish phone numbers. I live in Murcia.
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
Anton Ertl
Jun 15, 2023, 12:47:21 PM6/15/23
to
>I have been exploring the Forth programming language and specifically the G=
>forth implementation. I am pondering about its utilization in a "bare metal=
>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=
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/
>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 =
>
>By "bare metal," I am referring to two distinct yet related definitions:
>
>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/
SpainHackForth
Jun 15, 2023, 3:23:34 PM6/15/23
to
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
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
Anton Ertl
Jun 15, 2023, 5:00:38 PM6/15/23
to
SpainHackForth <jem...@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=
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 =
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.
>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.
SpainHackForth
Jun 15, 2023, 6:11:08 PM6/15/23
to
On Thursday, June 15, 2023 at 11:00:38 PM UTC+2, Anton Ertl wrote:
> SpainHackForth
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!
> 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,
> >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.
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!
none albert
Jun 17, 2023, 3:43:22 AM6/17/23
to
In article <29665766-6892-4d80...@googlegroups.com>,
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 -
"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 -
none albert
Jun 17, 2023, 4:02:52 AM6/17/23
to
In article <fe93dabd-6196-4bab...@googlegroups.com>,
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
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
Hugh Aguilar
Jun 21, 2023, 10:11:11 PM6/21/23
to
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!
> gForth is primarily a desktop application. Serious cross compilers come from
> Forth Inc. and MPE.
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???
Jurgen Pitaske
Jun 22, 2023, 4:51:09 AM6/22/23
to
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.
> 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 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.
MPE customers will push, if more is needed.
> Stephen Pelc is on the Forth-200x committee, implying that he is an expert
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.
Stephen Pelc
Jun 22, 2023, 5:19:34 AM6/22/23
to
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 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.
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.
Jurgen Pitaske
Jun 22, 2023, 5:27:37 AM6/22/23
to
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.
dxforth
Jun 22, 2023, 8:27:01 AM6/22/23
to
Nobody else has seen it.
Hugh Aguilar
Jun 22, 2023, 1:04:58 PM6/22/23
to
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!
> 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.
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.
Jurgen Pitaske
Jun 22, 2023, 1:14:27 PM6/22/23
to
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..
Hugh Aguilar
Jul 21, 2023, 10:08:53 PM7/21/23
to
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 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
---------------------------------------------------------------------------------------------------------
On Fri, Jul 21, 2023 at 5:37 AM Matthias Koch <m.c...@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.
dxforth
Jul 22, 2023, 12:06:34 AM7/22/23
to
On 22/07/2023 12:08 pm, Hugh Aguilar wrote:
> ...
> https://www.forth2020.org/beginners-to-forth/a-novice-package
> ...
https://www.forth2020.org/home/contact
> ...
> 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:
> this old copy of the novice package.
https://www.forth2020.org/home/contact
Hugh Aguilar
Jul 23, 2023, 3:29:48 PM7/23/23
to
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!
dxforth
Jul 23, 2023, 11:00:22 PM7/23/23
to
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
> 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.
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.
posted your material in good faith under the conditions of the licence
and in conformity with their general goal of promoting Forth.
Hugh Aguilar
Jul 23, 2023, 11:26:30 PM7/23/23
to
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.
> 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.
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.
none albert
Jul 24, 2023, 4:17:46 AM7/24/23
to
In article <7d943c24-0236-47ff...@googlegroups.com>,
you cannot "tell" people anything. You can politely ask to
not distribute, but that's all.
<SNIP>
contrary to you-know-who.
Hugh Aguilar <hughag...@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
>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.
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,
>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!
contrary to you-know-who.
Hugh Aguilar
Jul 24, 2023, 10:52:01 PM7/24/23
to
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
> >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.
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!
Jurgen Pitaske
Jul 25, 2023, 2:05:11 AM7/25/23
to
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.
dxforth
Jul 25, 2023, 4:28:31 AM7/25/23
to
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
>
> Most likely the anonymous African's string-stack was
> just a rework of Wil Baden's crap code that doesn't use COW.
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.
none albert
Jul 25, 2023, 4:50:13 AM7/25/23
to
In article <335f55a3-9192-4e03...@googlegroups.com>,
Hugh Aguilar <hughag...@gmail.com> 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.
I didn't know the task of a conference organizer is to debug string-stacks.
>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.
none albert
Jul 25, 2023, 5:17:18 AM7/25/23
to
$@ $! $+! $C+ and $^ $/ $\
Now I'm busy with Clojure mal. There is a lot of string handling
going on, but it probably would be a term project to adapt Aguilar
strings-stack. COW is worthless as future versions of Clojure needs
garbage collecting strings anyhow and Clojure shuns modification
of data structures. "Copy On Write but the Write never happens."
I seen dozen of "string stacks" by the way and no applications.
It is a favorite pass time of the likes of Aguilar to create these
package and then boast about them.
A tool can make into my library if it has been (!) used more
than 3 times, and occupies at most 3 screens.
$@ $! $+! $C+ fits in one screen and it doesn't burden the
memory. With $^ find-char-position $/ slash-from-the-front
and $\ slash-from-the back I happily analyse the comma separated
transaction lists from my bank for my taxes.
dxforth
Jul 25, 2023, 9:56:39 AM7/25/23
to
https://groups.google.com/g/comp.lang.forth/c/cISVDbPlR2E/m/7PSR0uv4KYoJ
minforth
Jul 25, 2023, 11:26:20 AM7/25/23
to
none albert schrieb am Dienstag, 25. Juli 2023 um 11:17:18 UTC+2:
> In article <u9o13b$12f5p$1...@dont-email.me>, dxforth <dxf...@gmail.com> wrote:
> >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.
> >
> I get by with statically organized storage and
> $@ $! $+! $C+ and $^ $/ $\
> Now I'm busy with Clojure mal. There is a lot of string handling
> going on, but it probably would be a term project to adapt Aguilar
> strings-stack. COW is worthless as future versions of Clojure needs
> garbage collecting strings anyhow and Clojure shuns modification
> of data structures. "Copy On Write but the Write never happens."
>
> I seen dozen of "string stacks" by the way and no applications.
> It is a favorite pass time of the likes of Aguilar to create these
> package and then boast about them.
> A tool can make into my library if it has been (!) used more
> than 3 times, and occupies at most 3 screens.
>
I regularly use array-stacks with COW for signal processing.
> In article <u9o13b$12f5p$1...@dont-email.me>, dxforth <dxf...@gmail.com> wrote:
> >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.
> >
> I get by with statically organized storage and
> $@ $! $+! $C+ and $^ $/ $\
> Now I'm busy with Clojure mal. There is a lot of string handling
> going on, but it probably would be a term project to adapt Aguilar
> strings-stack. COW is worthless as future versions of Clojure needs
> garbage collecting strings anyhow and Clojure shuns modification
> of data structures. "Copy On Write but the Write never happens."
>
> I seen dozen of "string stacks" by the way and no applications.
> It is a favorite pass time of the likes of Aguilar to create these
> package and then boast about them.
> A tool can make into my library if it has been (!) used more
> than 3 times, and occupies at most 3 screens.
>
Global arrays are available as natural extension of Forth VALUEs.
It would be trivial to use this for character arrays or strings. But I
never exhausted my small circular string buffer. Given that most strings
are anyhow small compared to available memory, a separate string stack
seems a rather superfluous tool.
Marcel Hendrix
Jul 25, 2023, 3:46:13 PM7/25/23
to
On Tuesday, July 25, 2023 at 11:17:18 AM UTC+2, none albert wrote:
[..]
other use it. Here's a small selection from iForth's miscutil.frt .
In the process of writing iSPICE I needed many other string/parsing
words, but these are still in purgatory.
:ABOUT
??CR ." -- low-precision timing --"
CR ." TIMER-RESET \ ( -- )"
CR ." TIMER-PRESET \ ( u -- ) offset for .elapsed"
CR ." ?MS \ ( -- u ) ms since machine turned on"
CR ." MS? \ ( -- u ) ms since TIMER-RESET"
CR ." .ELAPSED \ ( -- ) prints number of ms since last TIMER-RESET"
CR
CR ." -- high-precision timing --"
CR ." USE-TSC-TIMER \ ( flag -- ) when true use TSC for the TICKS-GET, otherwise the system clock"
CR ." .TICKER-INFO \ ( -- ) gives information about the current TICKS-GET mode"
CR ." PROCESSOR-CLOCK \ ( -- mhz )
CR ." TICKS-INITED? \ ( -- TRUE=inited )"
CR ." CALIBRATE \ ( -- ) compute processor-clock"
CR ." RECALIBRATE \ ( -- ) recompute processor-clock"
CR ." TICKS-RESET \ ( -- )"
CR ." TICKS-GET \ ( -- ud ) ticks since machine turned on"
CR ." TICKS? \ ( -- ud ) ticks since TICKS-RESET"
CR ." TICKS>US \ ( ud -- ud ) convert to microseconds"
CR ." TICKS>MS \ ( ud -- u ) convert to milliseconds"
CR ." US? \ ( -- ud ) microseconds since last TICKS-RESET"
CR ." DTICKS-RESET \ ( -- )"
CR ." [TICKS \ ( -- )"
CR ." TICKS] \ ( -- ) accumulates ticks since [TICKS"
CR ." D-US? \ ( -- ud ) us since last DTICKS-RESET"
CR .~ .TICKS" \ ( <text>" -- ) time in clock ticks"
\ CR ." PMC@ \ ( u -- ud ) read performance monitor u (0|1)"
CR
CR ." -- formatting --"
CR ." ((n,3)) \ ( ud -- caddr u )"
CR ." (n,3) \ ( ud -- )"
CR ." ((.KB)) \ ( ud -- caddr u )"
CR ." (.KB) \ ( ud -- )"
CR ." .KB \ ( u -- ) prints 12345678 as 12,345.678"
CR ." .MB \ ( u -- ) prints 12345678 as 12.345"
CR ." .MSECS \ ( ud -- )"
CR ." .BOOL \ ( bool -- ) Type 'yes' or 'no' "
CR
CR ." BETWEEN \ ( n low high -- bool ) like WITHIN but inclusive
CR ." ENUM \ definer; ( init -- ) ENUM name: then use name: red name: blue etc."
CR ." 2^x \ ( x -- 2^x )"
CR ." SQRT \ ( u1 -- u2 )"
CR ." SQR \ ( u1 -- u2 )"
CR ." DSQRT \ ( ud -- u )"
CR ." LOG2 \ ( u -- hi_bit# | -1 )"
CR ." #BITS \ ( u -- #bits )"
CR ." LOWEST-BIT \ ( u -- lo_bit# | -1 )"
CR ." POWER-OF-2? \ ( u -- bool )"
CR ." 16B->S \ ( 16b -- n ) sign-extend a character/word"
CR ." DXOR \ ( d1 d2 -- d1^d2 )"
CR ." DAND \ ( d1 d2 -- d1&d2 )"
CR ." DOR \ ( d1 d2 -- d1|d2 )"
CR ." DINVERT \ ( d -- ~d )"
CR ." RANDOMIZE \ ( -- ) (Re)initialize random number generator"
CR ." RANDOM \ ( -- u ) Fairly random number (integer)"
CR ." CHOOSE \ ( n -- u ) 0 <= u < n pick random number from range"
CR ." FRANDOM \ ( F: -- r ) Random floating-point number < 2^31"
CR ." FCHOOSE \ ( n -- ) ( F: -- ur ) 0 <= ur < r pick random number from range"
CR ." FPREM \ ( F: r1 r2 -- rem[r1/r2] ) take FP remainder"
CR ." FP/REM \ ( F: r1 r2 -- rem[r1/r2] ) ( -- div[r1/r2] ) take FP remainder and quotient"
CR ." NOW? \ ( cfa -- ) Compile if compiling, else execute"
CR ." DEFER \ (compile) DEFER #<vector># define a vectored word"
CR ." \ (execute) #<vector># -- <addr>
CR ." IS [IS] \ ' <exectoken> IS #<vector># setup vector"
CR ." IS? [IS?] \ ( -- xt ) usage: vector IS?"
CR ." 32B, 16B, \ ( n -- ) comma 32 and 16-bit numbers without aligning"
CR ." F#80 \ text is ignored if package is not extended precision"
CR ." F#64 \ text is ignored if package is not double precision"
CR ." F#32 \ text is ignored if package is not single precision"
CR ." +E.R \ ( fieldwidth> -- ) ( F: r -- ) print in field"
CR ." +E. \ ( -- ) ( F: r -- ) print in default field"
CR ." (F.N1) \ ( -- c-addr u ) ( F: r -- ) format in engineering notation"
CR ." F.N1 \ ( F: r -- ) print in engineering notation with trailing space"
CR ." (F.N2) \ ( -- c-addr u ) ( F: r -- ) format in engineering notation, no space"
CR ." F.N2 \ ( F: r -- ) print in engineering notation, no space"
CR ." FDUMP \ ( a-addr +n -- ) print +n floats from a-addr"
CR ." DFDUMP \ ( a-addr +n -- ) print +n dfloats from a-addr"
CR ." SFDUMP \ ( a-addr +n -- ) print +n sfloats from a-addr"
CR ." F>SR \ ( F: r -- ) ( -- r ) rounding version of F>S"
CR ." SOURCELINE# \ ( -- +n )"
CR ." SOURCEFILENAME \ ( -- c-addr u )"
CR ." EXEC: .. EXEC; \ ( index -- ? ) EXEC: in-line jump (call) table"
CR ." BIT? \ ( base bit# -- ? ) test a bit"
CR ." -BIT? \ ( base bit# -- bit# ? ) test a bit"
CR ." BIT-RESET \ ( base bit# -- ) reset a bit"
CR ." BIT-SET \ ( base bit# -- ) set a bit"
CR ." BIT-FLIP \ ( base bit# -- ) flip a bit"
CR ." NETWORK@ \ ( -- ) what's my ID, with how many are we?"
CR ." ?FILE \ ( error# -- ) Default error handler for file I/O"
CR ." PAD$ \ create: ( u -- ) use: ( -- addr )"
CR ." NPAD$ \ ( size -- ) "
CR ." RINGBUFFER \ ( number_8K_buffers -- ) ( -- addr )"
CR ." CELLPACK \ ( c-addr1 u1 addr2 -- addr2 )"
CR ." CELLPLACE+ \ ( c-addr1 u a2 -- )"
CR ." CELLCHAR+ \ ( char addr -- )"
CR
CR ." $TEMP \ ( c-addr1 u1 -- c-addr2 u2 )"
CR ." $FREE \ ( c-addr2 u2 -- )"
CR .~ OVERWRITES \ ( c-addr u "name" -- ) uses (overw) ( c-addr u c-addr2 u2 -- c-addr3 u3 )~
CR .~ $+TO \ ( c-addr u "name" -- ) uses (addto) ( c-addr u c-addr2 u2 -- c-addr3 u3 )~
CR
CR .~ MULTI-LINE \ ( quote "ccc<quote>" -- str len ) Limited to 4096 characters~
CR ." C!+ C+!+ D+!+ \ ( <type> addr1 -- addr2 )"
CR ." CHAR-APPEND \ ( c-addr u c -- c-addr2 u2 )"
CR ." CHAR-PREPEND \ ( c-addr u c -- c-addr2 u2 )"
CR ." CPLACE+ \ ( char addr -- )"
CR ." Split-At-WS \ ( addr1 n1 -- addr1 n2 addr1+n2 n1-n2 )"
CR ." Split-At-Char \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 )"
CR ." Split-At-Char-NC \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 ) not case-sensitive"
CR ." Split-At-LastChar \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 )"
CR ." Split-At-LastChar-NC \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 ) not case-sensitive"
CR ." Split-At-Word \ ( addr1 n1 addr2 n2 -- addr1 n3 addr1+n4 n1-n4 )"
CR ." Split-At-Word-NC \ ( addr1 n1 addr2 n2 -- addr1 n3 addr1+n4 n1-n4 ) not case-sensitive"
CR ." -LEADING \ ( c-addr u -- c-addr2 u2 )"
CR ." -LEADING-WS \ ( c-addr u -- c-addr2 u2 )"
CR ." -TRAILING-WS \ ( c-addr u -- c-addr2 u2 )"
CR
CR .~ MACRO% \ ( "param1" ... "paramn" -- ) Macro creation word allowing parameter insertion if "%" found.~
CR ." LOOP~ LOOP[ \ ( end start -- ) use % to insert compile-time loop index"
CR ." +LOOP~ +LOOP[ \ ( end start step -- ) use % to insert compile-time loop index"
CR
CR ." ?EXIT ?LEAVE"
CR
CR ." -- system --"
CR ." KILL-PROCESS \ ( c-addr u -- bool ) Kill program
CR ." QUERY-PROCESS \ ( c-addr u -- bool ) interrogate process
CR ." _PID" \ ( -- c-addr u ) return PID as string
CR ." SHAREDMEM \ ( c-addr u sz -- addr ) ask for a name shared memory segment of size = sz"
CR ." UNSHARED \ ( addr -- ) release shared memory"
CR ." HIDE-CONSOLE \ minimize window"
CR ." SHOW-CONSOLE \ raise window"
CR
CR ." -- debug --"
CR ." ]^^[ \ executing: show compiled line#, stacks (rstack if rstackdump? = TRUE), wait for not ^Q"
CR ." ^^ \ compilation: compile current line#, and call to (^^)."
CR .~ ?^^ \ compiles "IF ^^ ENDIF"~
CR ." #^^ \ ( n -- ) compiles n instead of line#"
CR
CR ." -- relative file paths --"
CR ." CD$ \ ( -- c-addr u ) Current working directory"
CR ." ONLY-PATH \ ( c-addr u1 -- c-addr u2 ) Only path"
CR ." ONLY-FILENAME \ ( c-addr u1 -- c-addr u2 ) Only filename"
CR ." ONLY-BASEFILENAME \ ( c-addr1 u1 -- c-addr2 u2 ) filename without extension ( .xxxxxx )"
CR ." FILE-HERE \ ( -- c-addr u ) The name (without path) of the file currently being interpreted"
CR ." PATH-HERE \ ( -- c-addr u ) The dirpath to the file currently being interpreted"
CR ." +INCLUDED \ ( c-addr u -- ) INCLUDE the file (c-addr u), in the same directory as the current file"
CR .~ +INCLUDE \ ( "name" -- ) Parsing version of +INCLUDED~
CR ." FILE-EXISTS? \ ( c-addr u -- TRUE=exists ) TRUE if the file exists (See: FILE-STATUS)."
CR ." FILE-TIME \ ( c-addr u -- ftime|0 ) 100ns increments since the last write to this file (0 is probably FILE NOT FOUND)."
CR ." FILE-BIRTH \ ( c-addr u -- u ) Alias for FILE-TIME"
CR ." UNTAB \ ( c-addr u -- addr2 u2 ) remove TABs from this string (note: in-place!)"
CR ." /SLASHING \ ( c-addr u -- addr2 u2 ) normalize to Linux slashes (note: in-place!)"
CR ." \SLASHING \ ( c-addr u -- addr2 u2 ) normalize to Windows slashes (note: in-place!)"
CR ." UNSLASH \ ( c-addr u -- addr2 u2 ) according to the OS, exchange '\' and '/' in this path-string (note: in-place!)"
CR ." UNQUOTE \ ( c-addr u -- addr2 u2 ) Remove a leading and trailing double quote character"
CR ." +QUOTES? \ ( c-addr u -- addr2 u2 ) Add a leading and trailing double quote character if there is none"
CR .~ UNEXE \ ( c-addr u -- addr2 u2 ) Remove a trailing ".exe" string~
CR .~ +SLASH? \ ( c-addr u -- addr2 u2 ) Add a trailing "\" or "/" when it is not there yet~
CR ." SLURP-FILE \ ( c-addr u -- addr2 u2 ) The location addr2 is transient"
CR ." SLURP-FILE(1) \ ( c-addr u -- addr2 u2 ) Skips space at HERE (2 slurps), also: SLURP-FILE(2) and (3)"
CR
CR .~ $" \ ( 'cccc' -- addr ) compile string, leave address~
CR .~ :INLINE \ ( "text ;" -- ) define hybrid text macro. Not WORDLIST safe~
CR ." PLACE+ \ ( c-addr u 'sum$ -- ) add string to sum"
CR ." $+ \ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 ) add str2 to str1. Result str3 is member of a bufferpool"
CR ." $>UPC \ ( c-addr u -- c-addr u ) convert (in place) to uppercase"
CR ." $>LWC \ ( c-addr u -- c-addr u ) convert (in place) to lowercase"
CR ." ZCOUNT \ ( zaddr -- addr u ) length of a C-string"
CR
CR ." LOCATE name find file and source line for `name'"
CR ." HEAD' name LOCATED alternative syntax"
CR .~ S" name" $LOCATE alternative syntax~
CR ." INSPECT after a successful LOCATE, jump to file at line"
CR ." /locate-context the number of lines actually printed"
CR
CR ." WHERE name ??? \ ( -- ) reads name from input and searches files for whitespace limited 'name'."
CR ." WHERE+ name ??? \ ( -- ) reads name from input and searches files for 'name'."
CR ." $WHERE ??? \ ( a l -- ) searches files for a text string given"
CR ." list files and matches, you can press ESC to exit, CASESENSITIVE is respected, ??? can be"
CR ." empty old style behaviour, search all files visited by LOCATE (excluding kernel source)"
CR ." * search the complete dfwforth directory tree."
CR ." directory any dfwforth subdirectory."
CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt par -- ), see DOC in miscutil" ;
-marcel
[..]
> A tool can make into my library if it has been (!) used more
> than 3 times, and occupies at most 3 screens.
>
> $@ $! $+! $C+ fits in one screen and it doesn't burden the
> memory. With $^ find-char-position $/ slash-from-the-front
> and $\ slash-from-the back I happily analyse the comma separated
> transaction lists from my bank for my taxes.
I've noticed that there are words one doesn't miss unless one sees
> than 3 times, and occupies at most 3 screens.
>
> $@ $! $+! $C+ fits in one screen and it doesn't burden the
> memory. With $^ find-char-position $/ slash-from-the-front
> and $\ slash-from-the back I happily analyse the comma separated
> transaction lists from my bank for my taxes.
other use it. Here's a small selection from iForth's miscutil.frt .
In the process of writing iSPICE I needed many other string/parsing
words, but these are still in purgatory.
:ABOUT
??CR ." -- low-precision timing --"
CR ." TIMER-RESET \ ( -- )"
CR ." TIMER-PRESET \ ( u -- ) offset for .elapsed"
CR ." ?MS \ ( -- u ) ms since machine turned on"
CR ." MS? \ ( -- u ) ms since TIMER-RESET"
CR ." .ELAPSED \ ( -- ) prints number of ms since last TIMER-RESET"
CR
CR ." -- high-precision timing --"
CR ." USE-TSC-TIMER \ ( flag -- ) when true use TSC for the TICKS-GET, otherwise the system clock"
CR ." .TICKER-INFO \ ( -- ) gives information about the current TICKS-GET mode"
CR ." PROCESSOR-CLOCK \ ( -- mhz )
CR ." TICKS-INITED? \ ( -- TRUE=inited )"
CR ." CALIBRATE \ ( -- ) compute processor-clock"
CR ." RECALIBRATE \ ( -- ) recompute processor-clock"
CR ." TICKS-RESET \ ( -- )"
CR ." TICKS-GET \ ( -- ud ) ticks since machine turned on"
CR ." TICKS? \ ( -- ud ) ticks since TICKS-RESET"
CR ." TICKS>US \ ( ud -- ud ) convert to microseconds"
CR ." TICKS>MS \ ( ud -- u ) convert to milliseconds"
CR ." US? \ ( -- ud ) microseconds since last TICKS-RESET"
CR ." DTICKS-RESET \ ( -- )"
CR ." [TICKS \ ( -- )"
CR ." TICKS] \ ( -- ) accumulates ticks since [TICKS"
CR ." D-US? \ ( -- ud ) us since last DTICKS-RESET"
CR .~ .TICKS" \ ( <text>" -- ) time in clock ticks"
\ CR ." PMC@ \ ( u -- ud ) read performance monitor u (0|1)"
CR
CR ." -- formatting --"
CR ." ((n,3)) \ ( ud -- caddr u )"
CR ." (n,3) \ ( ud -- )"
CR ." ((.KB)) \ ( ud -- caddr u )"
CR ." (.KB) \ ( ud -- )"
CR ." .KB \ ( u -- ) prints 12345678 as 12,345.678"
CR ." .MB \ ( u -- ) prints 12345678 as 12.345"
CR ." .MSECS \ ( ud -- )"
CR ." .BOOL \ ( bool -- ) Type 'yes' or 'no' "
CR
CR ." BETWEEN \ ( n low high -- bool ) like WITHIN but inclusive
CR ." ENUM \ definer; ( init -- ) ENUM name: then use name: red name: blue etc."
CR ." 2^x \ ( x -- 2^x )"
CR ." SQRT \ ( u1 -- u2 )"
CR ." SQR \ ( u1 -- u2 )"
CR ." DSQRT \ ( ud -- u )"
CR ." LOG2 \ ( u -- hi_bit# | -1 )"
CR ." #BITS \ ( u -- #bits )"
CR ." LOWEST-BIT \ ( u -- lo_bit# | -1 )"
CR ." POWER-OF-2? \ ( u -- bool )"
CR ." 16B->S \ ( 16b -- n ) sign-extend a character/word"
CR ." DXOR \ ( d1 d2 -- d1^d2 )"
CR ." DAND \ ( d1 d2 -- d1&d2 )"
CR ." DOR \ ( d1 d2 -- d1|d2 )"
CR ." DINVERT \ ( d -- ~d )"
CR ." RANDOMIZE \ ( -- ) (Re)initialize random number generator"
CR ." RANDOM \ ( -- u ) Fairly random number (integer)"
CR ." CHOOSE \ ( n -- u ) 0 <= u < n pick random number from range"
CR ." FRANDOM \ ( F: -- r ) Random floating-point number < 2^31"
CR ." FCHOOSE \ ( n -- ) ( F: -- ur ) 0 <= ur < r pick random number from range"
CR ." FPREM \ ( F: r1 r2 -- rem[r1/r2] ) take FP remainder"
CR ." FP/REM \ ( F: r1 r2 -- rem[r1/r2] ) ( -- div[r1/r2] ) take FP remainder and quotient"
CR ." NOW? \ ( cfa -- ) Compile if compiling, else execute"
CR ." DEFER \ (compile) DEFER #<vector># define a vectored word"
CR ." \ (execute) #<vector># -- <addr>
CR ." IS [IS] \ ' <exectoken> IS #<vector># setup vector"
CR ." IS? [IS?] \ ( -- xt ) usage: vector IS?"
CR ." 32B, 16B, \ ( n -- ) comma 32 and 16-bit numbers without aligning"
CR ." F#80 \ text is ignored if package is not extended precision"
CR ." F#64 \ text is ignored if package is not double precision"
CR ." F#32 \ text is ignored if package is not single precision"
CR ." +E.R \ ( fieldwidth> -- ) ( F: r -- ) print in field"
CR ." +E. \ ( -- ) ( F: r -- ) print in default field"
CR ." (F.N1) \ ( -- c-addr u ) ( F: r -- ) format in engineering notation"
CR ." F.N1 \ ( F: r -- ) print in engineering notation with trailing space"
CR ." (F.N2) \ ( -- c-addr u ) ( F: r -- ) format in engineering notation, no space"
CR ." F.N2 \ ( F: r -- ) print in engineering notation, no space"
CR ." FDUMP \ ( a-addr +n -- ) print +n floats from a-addr"
CR ." DFDUMP \ ( a-addr +n -- ) print +n dfloats from a-addr"
CR ." SFDUMP \ ( a-addr +n -- ) print +n sfloats from a-addr"
CR ." F>SR \ ( F: r -- ) ( -- r ) rounding version of F>S"
CR ." SOURCELINE# \ ( -- +n )"
CR ." SOURCEFILENAME \ ( -- c-addr u )"
CR ." EXEC: .. EXEC; \ ( index -- ? ) EXEC: in-line jump (call) table"
CR ." BIT? \ ( base bit# -- ? ) test a bit"
CR ." -BIT? \ ( base bit# -- bit# ? ) test a bit"
CR ." BIT-RESET \ ( base bit# -- ) reset a bit"
CR ." BIT-SET \ ( base bit# -- ) set a bit"
CR ." BIT-FLIP \ ( base bit# -- ) flip a bit"
CR ." NETWORK@ \ ( -- ) what's my ID, with how many are we?"
CR ." ?FILE \ ( error# -- ) Default error handler for file I/O"
CR ." PAD$ \ create: ( u -- ) use: ( -- addr )"
CR ." NPAD$ \ ( size -- ) "
CR ." RINGBUFFER \ ( number_8K_buffers -- ) ( -- addr )"
CR ." CELLPACK \ ( c-addr1 u1 addr2 -- addr2 )"
CR ." CELLPLACE+ \ ( c-addr1 u a2 -- )"
CR ." CELLCHAR+ \ ( char addr -- )"
CR
CR ." $TEMP \ ( c-addr1 u1 -- c-addr2 u2 )"
CR ." $FREE \ ( c-addr2 u2 -- )"
CR .~ OVERWRITES \ ( c-addr u "name" -- ) uses (overw) ( c-addr u c-addr2 u2 -- c-addr3 u3 )~
CR .~ $+TO \ ( c-addr u "name" -- ) uses (addto) ( c-addr u c-addr2 u2 -- c-addr3 u3 )~
CR
CR .~ MULTI-LINE \ ( quote "ccc<quote>" -- str len ) Limited to 4096 characters~
CR ." C!+ C+!+ D+!+ \ ( <type> addr1 -- addr2 )"
CR ." CHAR-APPEND \ ( c-addr u c -- c-addr2 u2 )"
CR ." CHAR-PREPEND \ ( c-addr u c -- c-addr2 u2 )"
CR ." CPLACE+ \ ( char addr -- )"
CR ." Split-At-WS \ ( addr1 n1 -- addr1 n2 addr1+n2 n1-n2 )"
CR ." Split-At-Char \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 )"
CR ." Split-At-Char-NC \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 ) not case-sensitive"
CR ." Split-At-LastChar \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 )"
CR ." Split-At-LastChar-NC \ ( addr1 n1 char -- addr1 n2 addr1+n2 n1-n2 ) not case-sensitive"
CR ." Split-At-Word \ ( addr1 n1 addr2 n2 -- addr1 n3 addr1+n4 n1-n4 )"
CR ." Split-At-Word-NC \ ( addr1 n1 addr2 n2 -- addr1 n3 addr1+n4 n1-n4 ) not case-sensitive"
CR ." -LEADING \ ( c-addr u -- c-addr2 u2 )"
CR ." -LEADING-WS \ ( c-addr u -- c-addr2 u2 )"
CR ." -TRAILING-WS \ ( c-addr u -- c-addr2 u2 )"
CR
CR .~ MACRO% \ ( "param1" ... "paramn" -- ) Macro creation word allowing parameter insertion if "%" found.~
CR ." LOOP~ LOOP[ \ ( end start -- ) use % to insert compile-time loop index"
CR ." +LOOP~ +LOOP[ \ ( end start step -- ) use % to insert compile-time loop index"
CR
CR ." ?EXIT ?LEAVE"
CR
CR ." -- system --"
CR ." KILL-PROCESS \ ( c-addr u -- bool ) Kill program
CR ." QUERY-PROCESS \ ( c-addr u -- bool ) interrogate process
CR ." _PID" \ ( -- c-addr u ) return PID as string
CR ." SHAREDMEM \ ( c-addr u sz -- addr ) ask for a name shared memory segment of size = sz"
CR ." UNSHARED \ ( addr -- ) release shared memory"
CR ." HIDE-CONSOLE \ minimize window"
CR ." SHOW-CONSOLE \ raise window"
CR
CR ." -- debug --"
CR ." ]^^[ \ executing: show compiled line#, stacks (rstack if rstackdump? = TRUE), wait for not ^Q"
CR ." ^^ \ compilation: compile current line#, and call to (^^)."
CR .~ ?^^ \ compiles "IF ^^ ENDIF"~
CR ." #^^ \ ( n -- ) compiles n instead of line#"
CR
CR ." -- relative file paths --"
CR ." CD$ \ ( -- c-addr u ) Current working directory"
CR ." ONLY-PATH \ ( c-addr u1 -- c-addr u2 ) Only path"
CR ." ONLY-FILENAME \ ( c-addr u1 -- c-addr u2 ) Only filename"
CR ." ONLY-BASEFILENAME \ ( c-addr1 u1 -- c-addr2 u2 ) filename without extension ( .xxxxxx )"
CR ." FILE-HERE \ ( -- c-addr u ) The name (without path) of the file currently being interpreted"
CR ." PATH-HERE \ ( -- c-addr u ) The dirpath to the file currently being interpreted"
CR ." +INCLUDED \ ( c-addr u -- ) INCLUDE the file (c-addr u), in the same directory as the current file"
CR .~ +INCLUDE \ ( "name" -- ) Parsing version of +INCLUDED~
CR ." FILE-EXISTS? \ ( c-addr u -- TRUE=exists ) TRUE if the file exists (See: FILE-STATUS)."
CR ." FILE-TIME \ ( c-addr u -- ftime|0 ) 100ns increments since the last write to this file (0 is probably FILE NOT FOUND)."
CR ." FILE-BIRTH \ ( c-addr u -- u ) Alias for FILE-TIME"
CR ." UNTAB \ ( c-addr u -- addr2 u2 ) remove TABs from this string (note: in-place!)"
CR ." /SLASHING \ ( c-addr u -- addr2 u2 ) normalize to Linux slashes (note: in-place!)"
CR ." \SLASHING \ ( c-addr u -- addr2 u2 ) normalize to Windows slashes (note: in-place!)"
CR ." UNSLASH \ ( c-addr u -- addr2 u2 ) according to the OS, exchange '\' and '/' in this path-string (note: in-place!)"
CR ." UNQUOTE \ ( c-addr u -- addr2 u2 ) Remove a leading and trailing double quote character"
CR ." +QUOTES? \ ( c-addr u -- addr2 u2 ) Add a leading and trailing double quote character if there is none"
CR .~ UNEXE \ ( c-addr u -- addr2 u2 ) Remove a trailing ".exe" string~
CR .~ +SLASH? \ ( c-addr u -- addr2 u2 ) Add a trailing "\" or "/" when it is not there yet~
CR ." SLURP-FILE \ ( c-addr u -- addr2 u2 ) The location addr2 is transient"
CR ." SLURP-FILE(1) \ ( c-addr u -- addr2 u2 ) Skips space at HERE (2 slurps), also: SLURP-FILE(2) and (3)"
CR
CR .~ $" \ ( 'cccc' -- addr ) compile string, leave address~
CR .~ :INLINE \ ( "text ;" -- ) define hybrid text macro. Not WORDLIST safe~
CR ." PLACE+ \ ( c-addr u 'sum$ -- ) add string to sum"
CR ." $+ \ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 ) add str2 to str1. Result str3 is member of a bufferpool"
CR ." $>UPC \ ( c-addr u -- c-addr u ) convert (in place) to uppercase"
CR ." $>LWC \ ( c-addr u -- c-addr u ) convert (in place) to lowercase"
CR ." ZCOUNT \ ( zaddr -- addr u ) length of a C-string"
CR
CR ." LOCATE name find file and source line for `name'"
CR ." HEAD' name LOCATED alternative syntax"
CR .~ S" name" $LOCATE alternative syntax~
CR ." INSPECT after a successful LOCATE, jump to file at line"
CR ." /locate-context the number of lines actually printed"
CR
CR ." WHERE name ??? \ ( -- ) reads name from input and searches files for whitespace limited 'name'."
CR ." WHERE+ name ??? \ ( -- ) reads name from input and searches files for 'name'."
CR ." $WHERE ??? \ ( a l -- ) searches files for a text string given"
CR ." list files and matches, you can press ESC to exit, CASESENSITIVE is respected, ??? can be"
CR ." empty old style behaviour, search all files visited by LOCATE (excluding kernel source)"
CR ." * search the complete dfwforth directory tree."
CR ." directory any dfwforth subdirectory."
CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt par -- ), see DOC in miscutil" ;
-marcel
S Jack
Jul 25, 2023, 3:55:58 PM7/25/23
to
On Tuesday, July 25, 2023 at 10:26:20 AM UTC-5, minforth wrote:
>
> It would be trivial to use this for character arrays or strings. But I
> never exhausted my small circular string buffer. Given that most strings
> are anyhow small compared to available memory, a separate string stack
> seems a rather superfluous tool.
(Beating the dead horse)
>
> It would be trivial to use this for character arrays or strings. But I
> never exhausted my small circular string buffer. Given that most strings
> are anyhow small compared to available memory, a separate string stack
> seems a rather superfluous tool.
I've been getting by well with string ring buffer.
Have a string stack since time of the flood but
have never needed it. Many years ago I was impressed
with string headers, most powerful but with
cost of three cells; consider them overkill for
run-of-mill jobs. Forced myself to use them some
awhile back just because they were there.
Strings in Forth generally are a no-brainer with
plethora ways of building and dealing with them.
Choosing a standard string is a can of worms that
I can elect to avoid.
--
me
none albert
Jul 26, 2023, 7:25:19 AM7/26/23
to
In article <3a10d701-d8b2-4fda...@googlegroups.com>,
>CR ." * search the complete dfwforth directory tree."
>CR ." directory any dfwforth subdirectory."
>CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt par
>-- ), see DOC in miscutil" ;
All useful words but at any given time 90% are not needed.
I prefer to tuck these stuff in a block file and then say
WANT TICKS
if I need the word TICKS.
(I have pontificated about additional advantages about WANT before.)
>
>-marcel
Marcel Hendrix <m...@iae.nl> wrote:
>On Tuesday, July 25, 2023 at 11:17:18 AM UTC+2, none albert wrote:
>[..]
>> A tool can make into my library if it has been (!) used more
>> than 3 times, and occupies at most 3 screens.
>>
>> $@ $! $+! $C+ fits in one screen and it doesn't burden the
>> memory. With $^ find-char-position $/ slash-from-the-front
>> and $\ slash-from-the back I happily analyse the comma separated
>> transaction lists from my bank for my taxes.
>
>I've noticed that there are words one doesn't miss unless one sees
>other use it. Here's a small selection from iForth's miscutil.frt .
>In the process of writing iSPICE I needed many other string/parsing
>words, but these are still in purgatory.
>
>:ABOUT
>??CR ." -- low-precision timing --"
>CR ." TIMER-RESET \ ( -- )"
>CR ." TIMER-PRESET \ ( u -- ) offset for .elapsed"
>CR ." ?MS \ ( -- u ) ms since machine turned on"
<SNIP>
>On Tuesday, July 25, 2023 at 11:17:18 AM UTC+2, none albert wrote:
>[..]
>> A tool can make into my library if it has been (!) used more
>> than 3 times, and occupies at most 3 screens.
>>
>> $@ $! $+! $C+ fits in one screen and it doesn't burden the
>> memory. With $^ find-char-position $/ slash-from-the-front
>> and $\ slash-from-the back I happily analyse the comma separated
>> transaction lists from my bank for my taxes.
>
>I've noticed that there are words one doesn't miss unless one sees
>other use it. Here's a small selection from iForth's miscutil.frt .
>In the process of writing iSPICE I needed many other string/parsing
>words, but these are still in purgatory.
>
>:ABOUT
>??CR ." -- low-precision timing --"
>CR ." TIMER-RESET \ ( -- )"
>CR ." TIMER-PRESET \ ( u -- ) offset for .elapsed"
>CR ." ?MS \ ( -- u ) ms since machine turned on"
>CR ." * search the complete dfwforth directory tree."
>CR ." directory any dfwforth subdirectory."
>CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt par
>-- ), see DOC in miscutil" ;
I prefer to tuck these stuff in a block file and then say
WANT TICKS
if I need the word TICKS.
(I have pontificated about additional advantages about WANT before.)
>
>-marcel
Marcel Hendrix
Jul 26, 2023, 12:52:05 PM7/26/23
to
On Wednesday, July 26, 2023 at 1:25:19 PM UTC+2, none albert wrote:
[..]
[..]
> >CR ." TREE-WALKER ( <baseaddr> <baselen> <maskaddr> <masklen> xt par
> >-- ), see DOC in miscutil" ;
> All useful words but at any given time 90% are not needed.
> I prefer to tuck these stuff in a block file and then say
> WANT TICKS
> if I need the word TICKS.
> (I have pontificated about additional advantages about WANT before.)
What I've also noted (and suffer from myself) is that even a tiny obstacle
> >-- ), see DOC in miscutil" ;
> All useful words but at any given time 90% are not needed.
> I prefer to tuck these stuff in a block file and then say
> WANT TICKS
> if I need the word TICKS.
> (I have pontificated about additional advantages about WANT before.)
(having to load a screen or typing 'WANT sumthin') causes some people
to choose a more lengthy and clumsy solution (e.g. most teenagers
nowadays access several levels of menus to 'Copy' and 'Paste' instead
of using control keys). Consequently, I preload everything that doesn't
need a manual, and all useful words display help texts when they load
last in the queue.
-marcel
Hugh Aguilar
Jul 26, 2023, 6:46:56 PM7/26/23
to
On Monday, July 24, 2023 at 1:17:46 AM UTC-7, none albert wrote:
> In article <7d943c24-0236-47ff...@googlegroups.com>,
> Hugh Aguilar <hughag...@gmail.com> wrote:
> >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.
I got an email from Peter Forth and he politely asked that he continue
> Hugh Aguilar <hughag...@gmail.com> wrote:
> >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.
to be allowed to distribute my novice package, and he insisted that
he is not associated with the Forth-200x committee in any way,
so I agreed that he can continue doing distributing it.
When Stephen Pelc insulted me, saying that anybody can write
a better string-stack than I can and some anonymous African
did write a far superior string-stack thirty years ago, I resolved
to never provide Stephen Pelc with my source-code. I forgot that
I had already allowed Peter Forth to post my source-code on
his website, so Stephen Pelc has most likely already got it.
It occurs to me that, having my novice package publicly
available helps to prevent Stephen Pelc from making any
part of it (such as the string-stack) proprietary to MPE.
Note that Peter Forth doesn't claim that he can
"rip my NOVICE package to the last byte" against my will.
It is only soulless maintenance programmers who strive to rip off
software written by real programmers --- Hell is full of such --- c.l.f. too.
On Sunday, February 26, 2023 at 7:37:35 AM UTC-7, Hans Bezemer wrote:
> On Sunday, February 26, 2023 at 12:26:27 AM UTC+1, Hugh Aguilar wrote:
> > I can't associate with soulless maintenance programmers such as DXforth,
> > Albert van der Horst, Hans Bezemer, etc.. This just gives Tom Hart the
> > opportunity to say: "Birds of a feather stick together." Guilt by association!
> Let me begin this by publicly stating that I don't want, need, require or ask
> for any association with you in any way, shape or form. So relax.
> ...
> But I'm not a maintenance programmer.
> ...
> But maybe now you understand why I don't care about you, Hugh. Or anything
> you say about me. Or make me stop what I'm doing. To me, you're just a nobody
> with a crazy opinion I don't care for.
>
> Hans Bezemer
>
> BTW, I can rip your NOVICE package till the last byte. You clearly released it under
> the BSD license - and you can't revoke that. You can change the license on the next
> version, but not the previous one.
dxforth
Jul 26, 2023, 7:30:06 PM7/26/23
to
On 27/07/2023 8:46 am, Hugh Aguilar wrote:
> ...
dissuade use or result in attempts to fix it by third parties.
> ...
> I got an email from Peter Forth and he politely asked that he continue
> to be allowed to distribute my novice package, and he insisted that
> he is not associated with the Forth-200x committee in any way,
> so I agreed that he can continue doing distributing it.
What of updates? An out of date and/or buggy 'novice pack' will either
> to be allowed to distribute my novice package, and he insisted that
> he is not associated with the Forth-200x committee in any way,
> so I agreed that he can continue doing distributing it.
dissuade use or result in attempts to fix it by third parties.
none albert
Jul 27, 2023, 11:06:28 AM7/27/23
to
In article <15e0cc0c-64af-49d6...@googlegroups.com>,
Therefore if you start lina normally (lina -e) you get the advise
"
TYPE "WANT AUTOLOAD" for automatic loading.
"
Future versions will have the -n (newbie) options that does
^E ( electives ) LOAD
WANTED AUTOLOAD
(Granted AUTOLOAD may fail sometimes.)
Your scheme fails under the circumstance that different configurations
are wanted.
For example the noforth folks need an absolute adherence to
non-written conventions, that ciforth may not adhere to.
That is available by
WANT -traditional-
without interference with other stuff that is available.
The granular structure of a block library make it possible
to have one library for 32/64 bit linux/mswindows/mac.
(Pontificating again ...)
"
TYPE "WANT AUTOLOAD" for automatic loading.
"
Future versions will have the -n (newbie) options that does
^E ( electives ) LOAD
WANTED AUTOLOAD
(Granted AUTOLOAD may fail sometimes.)
Your scheme fails under the circumstance that different configurations
are wanted.
For example the noforth folks need an absolute adherence to
non-written conventions, that ciforth may not adhere to.
That is available by
WANT -traditional-
without interference with other stuff that is available.
The granular structure of a block library make it possible
to have one library for 32/64 bit linux/mswindows/mac.
(Pontificating again ...)
Marcel Hendrix
Jul 28, 2023, 2:43:06 AM7/28/23
to
On Thursday, July 27, 2023 at 5:06:28 PM UTC+2, none albert wrote:
[..]
[..]
> The granular structure of a block library make it possible
> to have one library for 32/64 bit linux/mswindows/mac.
I like the concept, but the implementation is based on hardware
> to have one library for 32/64 bit linux/mswindows/mac.
details that are completely irrelevant by today's state of the art.
-marcel
none albert
Jul 28, 2023, 4:22:46 AM7/28/23
to
Marcel Hendrix
Jul 28, 2023, 1:49:16 PM7/28/23
to
On Friday, July 28, 2023 at 10:22:46 AM UTC+2, none albert wrote:
[..]
> >> The granular structure of a block library make it possible
> >> to have one library for 32/64 bit linux/mswindows/mac.
> >
> >I like the concept, but the implementation is based on hardware
> >details that are completely irrelevant by today's state of the art.
> Hardware??? It is a maintenance issue.
Oh, sorry, I thought you were using blocks with 16 lines of 64
[..]
> >> The granular structure of a block library make it possible
> >> to have one library for 32/64 bit linux/mswindows/mac.
> >
> >I like the concept, but the implementation is based on hardware
> >details that are completely irrelevant by today's state of the art.
> Hardware??? It is a maintenance issue.
characters.
-marcel
none albert
Jul 28, 2023, 2:46:00 PM7/28/23
to
In article <1f040381-6c14-40d4...@googlegroups.com>,
I do. That is a practical size. I bet that the size of the drawers
in your home is within 20% of the size of the drawers in mine.
My bicycles are about the same size than 1900's bicycles.
>
>-marcel
Groetjes Albert
in your home is within 20% of the size of the drawers in mine.
My bicycles are about the same size than 1900's bicycles.
>
>-marcel
Groetjes Albert
Andy Valencia
Aug 3, 2023, 12:22:24 PM8/3/23
to
albert@cherry.(none) (albert) writes:
the 1k size fits nicely on a pair of (floppy) sectors. CRT terminals
settled upon 80x24 (or 80x25) which is probably a better indicator of the
"ANSI standard drawer size" for displays. Thus ForthOS went with 80x25
with the shadow screen built in and 96 bytes at the end for filesystem
metadata (i.e., 4k blocks).
Wasteful? Sure. But not wasteful enough to matter on any platform
ForthOS could run upon. It's a 32-bit OS, so Apple ]['s were not an
issue.
Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html
> Marcel Hendrix <m...@iae.nl> wrote:
> >Oh, sorry, I thought you were using blocks with 16 lines of 64
> >characters.
> >Oh, sorry, I thought you were using blocks with 16 lines of 64
> >characters.
> I do. That is a practical size. I bet that the size of the drawers
> in your home is within 20% of the size of the drawers in mine.
> My bicycles are about the same size than 1900's bicycles.
16 lines of 64 chars always seemed a little cramped to me, even though
> in your home is within 20% of the size of the drawers in mine.
> My bicycles are about the same size than 1900's bicycles.
the 1k size fits nicely on a pair of (floppy) sectors. CRT terminals
settled upon 80x24 (or 80x25) which is probably a better indicator of the
"ANSI standard drawer size" for displays. Thus ForthOS went with 80x25
with the shadow screen built in and 96 bytes at the end for filesystem
metadata (i.e., 4k blocks).
Wasteful? Sure. But not wasteful enough to matter on any platform
ForthOS could run upon. It's a 32-bit OS, so Apple ]['s were not an
issue.
Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html
dxforth
Aug 4, 2023, 1:17:11 AM8/4/23
to
On 4/08/2023 2:17 am, Andy Valencia wrote:
> albert@cherry.(none) (albert) writes:
>> Marcel Hendrix <m...@iae.nl> wrote:
>>> Oh, sorry, I thought you were using blocks with 16 lines of 64
>>> characters.
>> I do. That is a practical size. I bet that the size of the drawers
>> in your home is within 20% of the size of the drawers in mine.
>> My bicycles are about the same size than 1900's bicycles.
>
> 16 lines of 64 chars always seemed a little cramped to me, even though
> the 1k size fits nicely on a pair of (floppy) sectors. CRT terminals
> settled upon 80x24 (or 80x25) which is probably a better indicator of the
> "ANSI standard drawer size" for displays. Thus ForthOS went with 80x25
> with the shadow screen built in and 96 bytes at the end for filesystem
> metadata (i.e., 4k blocks).
Even 80x25 has gone the way of the dodo. Back in the day apps came
> albert@cherry.(none) (albert) writes:
>> Marcel Hendrix <m...@iae.nl> wrote:
>>> Oh, sorry, I thought you were using blocks with 16 lines of 64
>>> characters.
>> I do. That is a practical size. I bet that the size of the drawers
>> in your home is within 20% of the size of the drawers in mine.
>> My bicycles are about the same size than 1900's bicycles.
>
> 16 lines of 64 chars always seemed a little cramped to me, even though
> the 1k size fits nicely on a pair of (floppy) sectors. CRT terminals
> settled upon 80x24 (or 80x25) which is probably a better indicator of the
> "ANSI standard drawer size" for displays. Thus ForthOS went with 80x25
> with the shadow screen built in and 96 bytes at the end for filesystem
> metadata (i.e., 4k blocks).
with configuration programs as terminals varied a lot (128 cols with
52 visible for the Osborne 1). Tying an app to 80 cols risked losing
sales. 64 isn't a bad fit for forth, being less reliant on indenting
than other languages.
0 new messages