Well, seems there are a lot of people with not much better things to do then bust into constructive threads and act
like children. So, I might as well give them something else to complain about. :)

Anyway, what processors is colorforth on?

Is there a common code repository for code in Colorforth?

What about common services and feature code which could work on all editions of Colorforth?

What about a standard based on Colorforth using a common code repository and common core and optimal features
and services framework in a common repository?

_____

A tentative discussion.

What does Etherforth and Machine Forth have to offer. I know I haven't concentrated
on Etherforth (are we actually up to one after that?), but Colorforth was written a
long time ago, and Chuck has made a few ways to improve things up, if memory serves
me right? So, should Colorforth be updated, or the latest me adapted as a new version?

Virtual workspaces (windows and screens) and actual workspaces.

Flexible GUI element placement? With text descriptor default.

Input output translator and remapper. Basically, for controls, define targets to aim
at for each control, direction and priority. The system implementation, or hardware
add-on, has it's own scheme to match up the controls. The system then auto maps, or
the developer then custom maps (such as in known embedded product for better
results). The system has an system implementation ID, so the developer knows what to
map, and hardware ID. Where no system ID is given, then the system auto maps,
and the user uses a configuration editor to change the map to customise to their
liking.

With storage mapping, convention is used to address file, file handlers, pointers, and
flat space, with declared lengths of each of these values. Simple (cross
compatible mode of subset of conventional usage) and complex mode, where system
ID and all values are exposed. Most of the time, only simple is needed.
Complex mode is simply sunk or swim, if nobody works it out eventually. Trying to
map all possible values to a virtual equivalent is a pain in the ... I had over 1000
possible directory entry fields, or something like that, just on my own design, trying
to accommodate all possibilities, but newer file systems have more than even
that. Simple, is more like fat32 field set, as most of the time app code is written for
one storage space, rather than a utility ranging across a segmented secure multi
program multi user system.


And Jeff's Aha! work?

______

The reason why colorforth is still important.

There was some paper written long ago comparing machine forth to forth on an
ARM, and I think native code. It was talking about people suggesting that machineforth
was superior, which I don't think people were. The actual reality, is the mapping of
colorforth to a subset of 386 code, offered a good opportunity for a virtual
machine, and a risc mode version of the 386 instruction set on a microscopic misc
CPU to run that mode, capable of going to GA x18 low power states with
performance. Much of the time, a x86 system and apps, could be programmed to stay
in this mode, only coming out when higher performance tasks are needed, crashing
battery consumption. Definitely desirable. As an array, these cpus can be
dynamically turned on as intended, with big 32 bit+ versions. This would achieve
a much higher performance density per watt and per transistor. That's where it
would be clearly superior, in that particular use case. Now, people aren't going to ditch
their x86 code and processor cores overnight for this, so the new architecture could
offer some benefits for low energy modes of operation, and specially written code.
But, for embedded and mobile use, most of it could be just this mode straight off
the bat, with maybe a basic 32 or 64 bit x86 core for some compatibility, or even such
code run through emulation in the parralel array. Wherever that is a performance
enhancement or not, is irrelevant, as eventually, it becomes all the new misc 86
code, and in the meantime less cost and energy consumption per transistor is
gained in the processor department, in an emulated system.


Thank you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Do you code anything at all using Forth?
And I don't mean ColorForth; even old, „obsolete” fig-Forth will do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, September 6, 2022 at 8:06:41 PM UTC+10, Zbig wrote:

"lorem ipsum".

More crap. Time to finish, you have been stalking me in enough threads.

What's this guy's name, so I can start using it, do others can figure out
what he is doing? He is just following around now, with virtually nothing constructive to offer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

So your answer is: „still not yet — but I'm going to, very soon”? :]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, September 6, 2022 at 11:49:59 AM UTC+2, Wayne morellini wrote:

Well, seems there are a lot of people with not much better things to do then bust into constructive threads and act
like children. So, I might as well give them something else to complain about. :)

Anyway, what processors is colorforth on?

Is there a common code repository for code in Colorforth?

What about common services and feature code which could work on all editions of Colorforth?

What about a standard based on Colorforth using a common code repository and common core and optimal features
and services framework in a common repository?

_____

A tentative discussion.

What does Etherforth and Machine Forth have to offer. I know I haven't concentrated
on Etherforth (are we actually up to one after that?), but Colorforth was written a
long time ago, and Chuck has made a few ways to improve things up, if memory serves
me right? So, should Colorforth be updated, or the latest me adapted as a new version?

Virtual workspaces (windows and screens) and actual workspaces.

Flexible GUI element placement? With text descriptor default.

Input output translator and remapper. Basically, for controls, define targets to aim
at for each control, direction and priority. The system implementation, or hardware
add-on, has it's own scheme to match up the controls. The system then auto maps, or
the developer then custom maps (such as in known embedded product for better results). The system has an system implementation ID, so the developer knows what to
map, and hardware ID. Where no system ID is given, then the system auto maps,
and the user uses a configuration editor to change the map to customise to their
liking.

With storage mapping, convention is used to address file, file handlers, pointers, and
flat space, with declared lengths of each of these values. Simple (cross compatible mode of subset of conventional usage) and complex mode, where system
ID and all values are exposed. Most of the time, only simple is needed. Complex mode is simply sunk or swim, if nobody works it out eventually. Trying to
map all possible values to a virtual equivalent is a pain in the ... I had over 1000
possible directory entry fields, or something like that, just on my own design, trying
to accommodate all possibilities, but newer file systems have more than even that. Simple, is more like fat32 field set, as most of the time app code is written for
one storage space, rather than a utility ranging across a segmented secure multi
program multi user system.

And Jeff's Aha! work?

______

The reason why colorforth is still important.

There was some paper written long ago comparing machine forth to forth on an ARM, and I think native code. It was talking about people suggesting that machineforth
was superior, which I don't think people were. The actual reality, is the mapping of
colorforth to a subset of 386 code, offered a good opportunity for a virtual machine, and a risc mode version of the 386 instruction set on a microscopic misc
CPU to run that mode, capable of going to GA x18 low power states with performance. Much of the time, a x86 system and apps, could be programmed to stay
in this mode, only coming out when higher performance tasks are needed, crashing
battery consumption. Definitely desirable. As an array, these cpus can be dynamically turned on as intended, with big 32 bit+ versions. This would achieve
a much higher performance density per watt and per transistor. That's where it
would be clearly superior, in that particular use case. Now, people aren't going to ditch
their x86 code and processor cores overnight for this, so the new architecture could
offer some benefits for low energy modes of operation, and specially written code.
But, for embedded and mobile use, most of it could be just this mode straight off
the bat, with maybe a basic 32 or 64 bit x86 core for some compatibility, or even such
code run through emulation in the parralel array. Wherever that is a performance
enhancement or not, is irrelevant, as eventually, it becomes all the new misc 86
code, and in the meantime less cost and energy consumption per transistor is gained in the processor department, in an emulated system.

Thank you.

Hi Wayne,

Anyway, what processors is colorforth on?

x86 32bit, i386 and higher or compatible - that is any modern Intel/AMD PC.

Is there a common code repository for code in Colorforth?

Yes - my distribution of cf2022 here : https://www.inventio.co.uk/cf2022/index.html.
The colorForth application code is pre-parsed, so can only be read by the colorForth program (or a specialised editor).
GreenArrays also provide arrayForth code in their distribution, but it is not compatible with cf2022.
Likewise Pablo Reda's R4 distirbution...

What about common services and feature code which could work on all editions of Colorforth?

colorForth cf2022 is work in progress, and I do not intend to make anything backwards compatible with earlier versions, or compatible with other distributions such as the excellent GreenArrays ArrayForth.

What about a standard based on Colorforth

You could use the current (latest) cf2022 as the current standard if you like, but it is likely to change. When I say "likely" I mean almost certainly.

The relationship between the F18 core (used in the GA144) and colorForth is complex. The F18 uses 5 bit opcodes that map to the F18 hardware, and these opcodes are compiled by the GreenArrays' ArrayForth, which is a version of colorForth running on a PC.
It would be possible to re-write colorForth to use only the F18 opcode instruction set as an extra layer between the hardware and higher level colorForth code. This would make is run faster on an F18 core, but less fast on a PC. There is no point in
doing this until there is some F18 (i.e. GA144) hardware available that has some sort of GUI available - I think that this would then deserve a new name - how about "machineForth:F18" ?
colorForth runs on a PC at the moment - that is at least one thing that all colorForths have in common, including Pablo Reda's R4 (https://github.com/phreda4/r4).

Cheers,
Howerd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 12, 2022 at 2:03:53 AM UTC+10, Howerd wrote:

On Tuesday, September 6, 2022 at 11:49:59 AM UTC+2, Wayne morellini wrote:

Thank you.

Hi Wayne,

Thanks for this Howerd.
..
So, there is no attempt to port it to other processor families.

What about common services and feature code which could work on all editions of Colorforth?

colorForth cf2022 is work in progress, and I do not intend to make anything backwards compatible with earlier versions, or compatible with other distributions such as the excellent GreenArrays ArrayForth.

Sorry, I meant going forwards across all new processor families, but there only seems to be
X86. I meant a common interfaces, storage and gui source code packages people could use to
run it stand alone, or under a. OS, so that all programs only need to be write once, unless you
want to customise. Sort of modem os concepts, as Linux does, and C only very remotely
attempted at its heart. That was the interest in Aha, as Jeff did significant work on what is
likely an optimised system.

What about a standard based on Colorforth

You could use the current (latest) cf2022 as the current standard if you like, but it is likely to change. When I say "likely" I mean almost certainly.

Updatable standard anyway. I meant like formal source code and implementation standard,
even through a standards body like Ansi. A personal Forth, that requires no compatibility with
existing Ansi Professional Forth.

The relationship between the F18 core (used in the GA144) and colorForth is complex. The F18 uses 5 bit opcodes that map to the F18 hardware, and these opcodes are compiled by the GreenArrays' ArrayForth, which is a version of colorForth running on a

PC. It would be possible to re-write colorForth to use only the F18 opcode instruction set as an extra layer between the hardware and higher level colorForth code. This would make is run faster on an F18 core, but less fast on a PC. There is no point in
doing this until there is some F18 (i.e. GA144) hardware available that has some sort of GUI available - I think that this would then deserve a new name - how about "machineForth:F18" ?

colorForth runs on a PC at the moment - that is at least one thing that all colorForths have in common, including Pablo Reda's R4 (https://github.com/phreda4/r4).

I would be talking about source code compatibility, like in Linux, which could be recompiled to
any new processor target using their instruction set.

I was mainly interested in how Chuck changed how forth instructions worked from colorforth to x18?

Cheers,
Howerd

Thanks again

Wayne.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 11, 2022 at 12:03:53 PM UTC-4, Howerd wrote:

On Tuesday, September 6, 2022 at 11:49:59 AM UTC+2, Wayne morellini wrote:

Well, seems there are a lot of people with not much better things to do then bust into constructive threads and act
like children. So, I might as well give them something else to complain about. :)

Anyway, what processors is colorforth on?

Is there a common code repository for code in Colorforth?

What about common services and feature code which could work on all editions of Colorforth?

What about a standard based on Colorforth using a common code repository and common core and optimal features
and services framework in a common repository?

_____

A tentative discussion.

What does Etherforth and Machine Forth have to offer. I know I haven't concentrated
on Etherforth (are we actually up to one after that?), but Colorforth was written a
long time ago, and Chuck has made a few ways to improve things up, if memory serves
me right? So, should Colorforth be updated, or the latest me adapted as a new version?

Virtual workspaces (windows and screens) and actual workspaces.

Flexible GUI element placement? With text descriptor default.

Input output translator and remapper. Basically, for controls, define targets to aim
at for each control, direction and priority. The system implementation, or hardware
add-on, has it's own scheme to match up the controls. The system then auto maps, or
the developer then custom maps (such as in known embedded product for better
results). The system has an system implementation ID, so the developer knows what to
map, and hardware ID. Where no system ID is given, then the system auto maps,
and the user uses a configuration editor to change the map to customise to their
liking.

With storage mapping, convention is used to address file, file handlers, pointers, and
flat space, with declared lengths of each of these values. Simple (cross compatible mode of subset of conventional usage) and complex mode, where system
ID and all values are exposed. Most of the time, only simple is needed. Complex mode is simply sunk or swim, if nobody works it out eventually. Trying to
map all possible values to a virtual equivalent is a pain in the ... I had over 1000
possible directory entry fields, or something like that, just on my own design, trying
to accommodate all possibilities, but newer file systems have more than even
that. Simple, is more like fat32 field set, as most of the time app code is written for
one storage space, rather than a utility ranging across a segmented secure multi
program multi user system.

And Jeff's Aha! work?

______

The reason why colorforth is still important.

There was some paper written long ago comparing machine forth to forth on an
ARM, and I think native code. It was talking about people suggesting that machineforth
was superior, which I don't think people were. The actual reality, is the mapping of
colorforth to a subset of 386 code, offered a good opportunity for a virtual
machine, and a risc mode version of the 386 instruction set on a microscopic misc
CPU to run that mode, capable of going to GA x18 low power states with performance. Much of the time, a x86 system and apps, could be programmed to stay
in this mode, only coming out when higher performance tasks are needed, crashing
battery consumption. Definitely desirable. As an array, these cpus can be dynamically turned on as intended, with big 32 bit+ versions. This would achieve
a much higher performance density per watt and per transistor. That's where it
would be clearly superior, in that particular use case. Now, people aren't going to ditch
their x86 code and processor cores overnight for this, so the new architecture could
offer some benefits for low energy modes of operation, and specially written code.
But, for embedded and mobile use, most of it could be just this mode straight off
the bat, with maybe a basic 32 or 64 bit x86 core for some compatibility, or even such
code run through emulation in the parralel array. Wherever that is a performance
enhancement or not, is irrelevant, as eventually, it becomes all the new misc 86
code, and in the meantime less cost and energy consumption per transistor is
gained in the processor department, in an emulated system.

Thank you.

Hi Wayne,

Anyway, what processors is colorforth on?

x86 32bit, i386 and higher or compatible - that is any modern Intel/AMD PC.

Is there a common code repository for code in Colorforth?

Yes - my distribution of cf2022 here : https://www.inventio.co.uk/cf2022/index.html.
The colorForth application code is pre-parsed, so can only be read by the colorForth program (or a specialised editor).
GreenArrays also provide arrayForth code in their distribution, but it is not compatible with cf2022.
Likewise Pablo Reda's R4 distirbution...

What about common services and feature code which could work on all editions of Colorforth?

colorForth cf2022 is work in progress, and I do not intend to make anything backwards compatible with earlier versions, or compatible with other distributions such as the excellent GreenArrays ArrayForth.

What about a standard based on Colorforth

You could use the current (latest) cf2022 as the current standard if you like, but it is likely to change. When I say "likely" I mean almost certainly.

The relationship between the F18 core (used in the GA144) and colorForth is complex. The F18 uses 5 bit opcodes that map to the F18 hardware, and these opcodes are compiled by the GreenArrays' ArrayForth, which is a version of colorForth running on a

PC. It would be possible to re-write colorForth to use only the F18 opcode instruction set as an extra layer between the hardware and higher level colorForth code. This would make is run faster on an F18 core, but less fast on a PC. There is no point in
doing this until there is some F18 (i.e. GA144) hardware available that has some sort of GUI available - I think that this would then deserve a new name - how about "machineForth:F18" ?

colorForth runs on a PC at the moment - that is at least one thing that all colorForths have in common, including Pablo Reda's R4 (https://github.com/phreda4/r4).

Perhaps you are not so familiar with the F18A. It is not remotely just another CPU that you can port random programs to, such as colorForth. The F18A only has access to 64 words of RAM (If I'm remembering the correct number) and 64 words of ROM which
contain code from GA. To compile a program for the F18A, even one as compact as colorForth probably is, will require partitioning code across multiple CPUs and adding code for communications. It sounds like you are expecting this to be done by the
tools compiling the colorForth code. Or maybe use an off chip memory and page code in and out of the 64 words of internal memory?

What was the Forth that was ported by humans to the GA144? That ended up using some plurality of F18As and an external memory.

Maybe the easy way to port colorForth to the F18A is to write an x86 emulator for the F18A and solve the problem for a very large class of programs.

Hmmm... I wonder if the F18A has a control bit to enable an x86 instruction mode?

--

Rick C.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 12, 2022 at 1:01:10 PM UTC+10, gnuarm.del...@gmail.com wrote:

On Sunday, September 11, 2022 at 12:03:53 PM UTC-4, Howerd wrote:

On Tuesday, September 6, 2022 at 11:49:59 AM UTC+2, Wayne morellini wrote:

..

Perhaps you are not so familiar with the F18A. It is not remotely just another CPU that you can port random programs to, such as colorForth. The F18A only has access to 64 words of RAM (If I'm remembering the correct number) and 64 words of ROM which

contain code from GA. To compile a program for the F18A, even one as compact as colorForth probably is, will require partitioning code across multiple CPUs and adding code for communications. It sounds like you are expecting this to be done by the tools
compiling the colorForth code. Or maybe use an off chip memory and page code in and out of the 64 words of internal memory?

What was the Forth that was ported by humans to the GA144? That ended up using some plurality of F18As and an external memory.

Maybe the easy way to port colorForth to the F18A is to write an x86 emulator for the F18A and solve the problem for a very large class of programs.

Hmmm... I wonder if the F18A has a control bit to enable an x86 instruction mo

Assuredly strange! Richard Collins, Arius.
Who are you talking to?

You know from past discussions, that the context is not the ga144 architecture implementation but normal versions with large memory addressing. Do you have a tank full of spare red herrings, by any chance? So, that source, or virtual code, can be
easily translated, into whatever processor machine code which is supported The sort of stuff they have been doing for around the last 35 years. Did you know this?

It's funny, you didn't burst in here before, probably as the post was too much to attack, but suddenly, after people start posting, you suddenly are here.

Your reply is irrelevant to the proposed standard discussion. It targets fat flat addressing spaces, and if anybody wants too, they can distribute codelet pieces among arrays. You might
Not be familiar with this, not having designed such systems. Not,, having good experience
designing good systems, often means people who just use systems, have trouble understanding new systems.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, September 6, 2022 at 2:13:32 PM UTC+2, Wayne morellini wrote:

More crap. Time to finish, you have been stalking me in enough threads.

Simply answer the question. Where's your source? It's not rocket science..

Hans Bezemer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 12, 2022 at 2:03:53 AM UTC+10, Howerd wrote:

On Tuesday, September 6, 2022 at 11:49:59 AM UTC+2, Wayne morellini wrote:

..

colorForth runs on a PC at the moment - that is at least one thing that all colorForths have in common, including Pablo Reda's R4 (https://github.com/phreda4/r4).

Cheers,
Howerd

Howerd, thanks for this. Pablo looks like the real deal. Not like people around here who
prevent things. He has a heap of stuff in projects. Jecel sort of was like that as well. He
has a number of aims and projects I also had. He also sort of has a similar look to what I did
at that age.

I had to figure out how to redesign most things in my operating system. Which is one reason I have wide design skills.

It's amazing we have people around telling how to suck eggs, when I long moved on to
delivering babies. Such a higher class individual. Even has his own forums! Obviously
a reason to be far from here.

Thanks. Your the sort of person we need more of around here. Forums always have a
handful of self satisfied individuals, who have to interfere with other's efforts, particularly if
they see ability outside of their own. But, even turning on each other at times. I should write a book on this one day. Maybe make up some of those rules talked about around here. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)