One More thing.... What if Forth could be...

[SpainHackForth]

Hi all, may be my over incitement for Forth at the moment as I feel like there is so much value for it, and I have been pondering several aspects of the language, ideas on how to best leverage it and furthermore, extend the adoption of Forth and the Forth way.

Question; why has Forth not been as prolific as other languages?

Views:
Why is there a lack of cross compiler on Forth?
- IMHO, this is an area where Forth could do the community a great deal of good. If for example, there where crosscompilers for the embedded environments, this would potentially drive the adoption of the Language. Another thing that could be really interesting, Forth is a VM, why not extend CPU simulation on Forth, where one would test those targeted systems and make it "simple" to see how the app behaves at the hardware level and how to optimize it. I know metaprograming just looks natural in Forth, yet I see lots of Python, JS, and Java as having a large number of instruction set sims ( ISS ) out there on these platforms, I have not found a single one on Forth ( maybe I have not looked hard enough )

Further more, one are of inspiration is having something like https://cpulator.01xz.net/?sys=arm-de1soc&d_audio=48000
Well, that is a dream, but if you thing about it, the front end could run on a browser, the back end could be a forth system... If that is too much to ask, consider Gerog Heinrichs neat little MikroForth, well and if that is too much to ask then consider the following.. .

Program offset instruction Dis-assembled register/ storage (after execution)
TEST001 000000 X'05C0' BALR R12,0 R12=002CE00A
000002 X'47F0C00E' BC 15,X'00C'(R12)
00000E X'98ECD00C' STM R14,R12,X'00C'(R13) X'002E0008' ==> X'00004CE,002CE008,..etc....'
000012 X'45E0C122' BAL R14,X'122'(R12) R14=002C0016
SUB1 000124 X'50E0C28A' ST R14,X'28A'(R12) X'002CE294' ==> X'002C0016'
etc...
Ok, even a GDB interface to the ISS would be enough, really! :)

Furthermore, on the basis of use cases, I see lot's of discussion and people building FPGA based stack CPU's. I apologize in advance form my ignorance on the matter, but isn't Fort a VM for a CPU sort of speak? What can you really get out of substantially over priced, under power, higher barrier to entry, where you are designing the hardware, with it's pitfalls in the development phase, then the Forth that sits o top ( Ok so forth is the machine code, cool science project, one I would like to test ) but for a commercial application, I find to make the economic connection and or benefits.
If Forth is a VM kernel , would it not make sense to spend the time to have a vm that has a native Programmable Interrupt Controller with built in interrupt priority levels and streamline the code executed on these systems? I look at all the bloat that goes into projects like OpenWRT, and I just wonder if they where not better off moving to bare metal ( FORTH ) to deliver better performance? I also see that with the excess of compute available in the Arch64 space, there is plenty of opportunities to improve the performance and even consider, can you run a vm on top of a Forth kernel? That could be a way to further extend the portability of the system.

One area I see that this could be interesting is in high end embedded systems, where the CPU is really a peripheral of a larger systems, like dedicated cards that do networking or caching on larger servers... those systems build extensive and expensive systems, that have all the linux bloat on them, when in the end all they run is a 10K lines of code with a very specif purpose. I thought Forth could be the kernel. for these systems.

Furthermore, Forth brings another interesting option, if you are running a forth vm on top of a forth vm that runs the app or part of the app ( think of containers speaking to each-other at CPU speed.), then near real time upgrades could be possible or even bitecode up-gradable ( just updating the dictionary to point to a new portion of the code could be possible, that is a strong business case if you are targeting edge devices... smart meters, ect...

Just so much could be done.

Thoughts? Rebuttals? Ideas?

[minf...@arcor.de]

Did you already solve your parsing exercise?

[Zbig]

czwartek, 24 listopada 2022 o 23:19:05 UTC+1 SpainHackForth napisał(a):
> Hi all, may be my over incitement for Forth at the moment as I feel like there is so much value for it, and I have been pondering several aspects of the language, ideas on how to best leverage it and furthermore, extend the adoption of Forth and the Forth way.
>
> Question; why has Forth not been as prolific as other languages?

Simple: it was not taught in universities. Contrary to C, for example.
Besides: business prefers languages like C, that allows easier replacement
of programmers, in case of need.

[dxforth]

On 25/11/2022 10:15 am, Zbig wrote:
> czwartek, 24 listopada 2022 o 23:19:05 UTC+1 SpainHackForth napisał(a):
>> Hi all, may be my over incitement for Forth at the moment as I feel like there is so much value for it, and I have been pondering several aspects of the language, ideas on how to best leverage it and furthermore, extend the adoption of Forth and the Forth way.
>>
>> Question; why has Forth not been as prolific as other languages?
>
> Simple: it was not taught in universities. Contrary to C, for example.

Universities are conservative. If Forth is being taught, you can bet
there's a Forth evangelist behind it :)

[Hans Bezemer]

On Friday, November 25, 2022 at 12:15:03 AM UTC+1, Zbig wrote:
> Besides: business prefers languages like C, that allows easier replacement
> of programmers, in case of need.

I know! I got a funny story on that one. I once worked for a joint that got spreadsheet
dumps from a multitude of branches every month. Sure, all of them sent slightly different
formats - and even the data (dates) inside were differently formatted. They had to be
merged, exceptions were to be logged, duplicate records had to be weeded out,
depending on their status, other data had to be spliced in and new identifiers needed
to be assigned on new items.

It took a guy a full day to merge them by hand - and the result was still abysmal. So I
told 'em I could write a program for all that in 5 workdays. They said it couldn't be done.
I bet them I could.

So I did. in 4tH. It did the entire job within 30 secs - without missing a beat. Full log and
a load of self-diagnostics to prove the integrity of the run. Made a nice Windows CLI
standalone executable for 'em - and wrote a nice user manual. Job done.

How did you do that, they asked. I used Forth, I answered. Why Fortran, they asked.
It's not Fortran - it's Forth, I responded. Let's see the source, they asked. So I gave 'em
the 64K source and all libs. That's gibberish, they said. No, it's Forth, I answered. But
we want C or C++, they said. That can be done, I answered.

4tH is capable of dumping the entire 4tH bytecode in C source format. Link it with the
lib and you can compile the whole darn thing with almost any C compiler. E.g. this is
"Hello world" (appended after this post).

So the local C guru took one look at it and said "What am I supposed to do with this"?
Write a functional design, they said. That'll take me a week, I said. So we'll see you
back in a week, they answered.

A week later I brought in my design - and they sent it of to some developer, asking for
an estimate. "About three months", he said.

Long story short - it ran until they rolled out a unified system and used it for one last
time to do the initial load. Never missed a beat. It was retired with full honors.

Hans Bezemer

/*
** This file was generated by 4tH
** Copyright 1997,2017 by J.L. Bezemer
*/

#ifdef USRLIB4TH
#include <4th.h>
#else
#include "4th.h"
#endif

#include <stdlib.h>


static dict CodeSegment [] = {
{'\x05', 0L}, {'\x02', 0L}
};

static char StringSegment [] = {
'\x48', '\x65', '\x6c', '\x6c', '\x6f', '\x20', '\x77', '\x6f', '\x72',
'\x6c', '\x64', '\x21', '\x00'
};

static Hcode Object = {
2, CodeSegment, 13U, StringSegment, NULL, NULL, NULL, 0, 0U, 0U, 0, 0, 0, TRUE
};


#ifndef ARCHAIC
int main (int argc, char **argv)
#else
int main (argc, argv) int argc; char **argv;
#endif

{
cell Result; /* holds the result of the program */

fflush (stderr); /* flush any messages */
/* now execute it */
Result = exec_4th (&Object, argc, argv, 0);

fflush (stdout);

if (Object.ErrNo) /* show exit messages */
fprintf (stderr, "Exiting; word %u: %s\n", Object.ErrLine,
errs_4th [Object.ErrNo]);
else
if (Result != CELL_MIN)
fprintf (stderr, "Exiting; result: %ld\n", Result);

return (Object.ErrNo ? EXIT_FAILURE : EXIT_SUCCESS);
}

[Stephen Pelc]

On 24 Nov 2022 at 23:19:03 CET, "SpainHackForth" <jem...@gmail.com> wrote:

> Hi all, may be my over incitement for Forth at the moment as I feel like there
> is so much value for it, and I have been pondering several aspects of the
> language, ideas on how to best leverage it and furthermore, extend the
> adoption of Forth and the Forth way.
>
> Question; why has Forth not been as prolific as other languages?

Mainly because Forth is difficult and dangerous you havr to be a good
programmer to use it well.

Secondly because people become hypnotised into writing their own Forth. Don't
do it, there are plenty available.

>
> Views:
> Why is there a lack of cross compiler on Forth?

There are plenty of cross compilers written in Forth for Forth. The reality is
that the vast majority are not very good. The good ones (with support and
documentation) are mostly by the commercial vendors - Forth Inc and MPE. See:
http://www.mpeforth.com
We support quite a range of CPUs. There are TCP/IP and USB stacks for 32 bit
CPUs.

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

[Lorem Ipsum]

Universities are conservative??? Really, since when?

Forth is not used, because they don't derive recognizable benefit from it.

--

Rick C.

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

[dxforth]

On 28/11/2022 8:01 am, Lorem Ipsum wrote:
> On Thursday, November 24, 2022 at 9:02:52 PM UTC-4, dxforth wrote:
>> On 25/11/2022 10:15 am, Zbig wrote:
>>> czwartek, 24 listopada 2022 o 23:19:05 UTC+1 SpainHackForth napisał(a):
>>>> Hi all, may be my over incitement for Forth at the moment as I feel like there is so much value for it, and I have been pondering several aspects of the language, ideas on how to best leverage it and furthermore, extend the adoption of Forth and the Forth way.
>>>>
>>>> Question; why has Forth not been as prolific as other languages?
>>>
>>> Simple: it was not taught in universities. Contrary to C, for example.
>> Universities are conservative. If Forth is being taught, you can bet
>> there's a Forth evangelist behind it :)
>
> Universities are conservative??? Really, since when?

Ever since those funding universities (parents, govt, industry) wanted
something in return.

> Forth is not used, because they don't derive recognizable benefit from it.

Exactly. Forth is the radical fringe, populated by Timothy Leary types.

[Lorem Ipsum]

I won't argue that, but that's not the reason Forth isn't used. It's just not useful to them, much like the vast majority of programmers.

--

Rick C.

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

[Paul Rubin]

Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> I won't argue that, but that's not the reason Forth isn't used. It's
> just not useful to them, much like the vast majority of programmers.

A university teaching programming by using Forth would be like a pilot
school teaching navigation by wetting your thumb and sticking it out
into the wind.

[Marcel Hendrix]

More like an electronics class where they hand you a kit of parts to first build
the measurement equipment yourself.

-marcel

[Zbig]

> > > I won't argue that, but that's not the reason Forth isn't used. It's
> > > just not useful to them, much like the vast majority of programmers.
> > A university teaching programming by using Forth would be like a pilot
> > school teaching navigation by wetting your thumb and sticking it out
> > into the wind.
> More like an electronics class where they hand you a kit of parts to first build
> the measurement equipment yourself.

…which is perfectly possible. Yes, the students are able to build such equipment
out of given components, using a particular schematics — when still having just
a sligth idea „how it actually works”, and learning the details later.

[Lorem Ipsum]

Lol! I like the analogy. I am a safe boating advocate, most specifically, being aware of the hazards of cold water. In one conversation where a group of novices were going out rather early in the season when the water would have been dangerously cold, I asked him if he had measured the temperature of the water. His reply was that he had put his toe in the water and it seemed "OK".

That may not mean much to someone not familiar with cold water, but it's the equivalent of saying the transistor isn't all that hot, he spit on it and it didn't instantly vaporize.

--

Rick C.

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

[Marcel Hendrix]

Which was my point.

-marcel

[dxforth]

Give them a schematic which has an error and see whether they find it :)

[Zbig]

> > Which was my point.
> Give them a schematic which has an error and see whether they find it :)

As a „BTW”: https://www.youtube.com/watch?v=CLnolhyT5SI

[NN]

Universities have to be practical. They have limited time teaching, and
they need students to be up and running by the end of the course.

C is widely used and even if you want to get away from it you cant
ignore it exists.

[NN]

On Friday, 25 November 2022 at 15:07:26 UTC, Stephen Pelc wrote:
> On 24 Nov 2022 at 23:19:03 CET, "SpainHackForth" <jem...@gmail.com> wrote:
>
> > Hi all, may be my over incitement for Forth at the moment as I feel like there
> > is so much value for it, and I have been pondering several aspects of the
> > language, ideas on how to best leverage it and furthermore, extend the
> > adoption of Forth and the Forth way.
> >
> > Question; why has Forth not been as prolific as other languages?
> Mainly because Forth is difficult and dangerous you havr to be a good
> programmer to use it well.

I have said in the past that forth is difficult but its no more or less difficult
than say haskell.

everyone starts off a beginner. you cant become a good programmer without
practise. you cant practise if you dont have good examples. you cant have
good examples if code isnt being shared. its catch 22.

we need to break this cycle.

>
> Secondly because people become hypnotised into writing their own Forth. Don't
> do it, there are plenty available.
> >

its free , easily available and widely discussed. eg jonesforth. I wouldnt say hypnotised
but why wouldnt wanna be forthers want to see if you can do it too or better?

[minf...@arcor.de]

NN schrieb am Montag, 28. November 2022 um 15:43:30 UTC+1:
> On Friday, 25 November 2022 at 15:07:26 UTC, Stephen Pelc wrote:
> > Secondly because people become hypnotised into writing their own Forth. Don't
> > do it, there are plenty available.
> > >
> its free , easily available and widely discussed. eg jonesforth. I wouldnt say hypnotised
> but why wouldnt wanna be forthers want to see if you can do it too or better?

There is this saying "fly like an eagle, don't scratch like a chicken". Build your own Forth
(one among thousands) can be like eternal ground scratching and become a waste of time.
(to remain fair: it can also be a fun hobby where time wasted does not count).

There was one famous guy in the Forth world: Tom Zimmer. The author of ZForth, TCOM
and F-PC and one of the "fathers" of Win32Forth. IIRC he left Forth altogether because
he could never become as productive as with C++.

[NN]

On Monday, 28 November 2022 at 15:57:05 UTC, minf...@arcor.de wrote:
> NN schrieb am Montag, 28. November 2022 um 15:43:30 UTC+1:
> > On Friday, 25 November 2022 at 15:07:26 UTC, Stephen Pelc wrote:
> > > Secondly because people become hypnotised into writing their own Forth. Don't
> > > do it, there are plenty available.
> > > >
> > its free , easily available and widely discussed. eg jonesforth. I wouldnt say hypnotised
> > but why wouldnt wanna be forthers want to see if you can do it too or better?
> There is this saying "fly like an eagle, don't scratch like a chicken". Build your own Forth
> (one among thousands) can be like eternal ground scratching and become a waste of time.
> (to remain fair: it can also be a fun hobby where time wasted does not count).
>

You are not speaking from the perspective of someone who's just starting to learn forth.
Additionally learning about how it all works cant be a waste of time until you have done it
once.

> There was one famous guy in the Forth world: Tom Zimmer. The author of ZForth, TCOM
> and F-PC and one of the "fathers" of Win32Forth. IIRC he left Forth altogether because
> he could never become as productive as with C++.

I dont know much about what Tom's done since he left forth scene. He's very good but whats
stopping him from writing a database or spreadsheet? Has he been productive with c++ ?
Maybe he just wanted a change. We all do sometimes.

[SpainHackForth]

I could not agree more with your comments...

Speaking from my own experience, Forth has been frustrating in what I'm simplifying as lack of repeatability.
You do some research, you feel like you understand something, then you get some interactive reinforcement with the Repl and you get to the next state, you try something and it fails, and it fails and it fails until you see that the code is just a snippet of something larger, and that is even a snippet of something else... and so forth, you learn to identify these things, but it's that low percentage of success for newcomers that makes it difficult IMO.

Like most things in innovation, there has to be something in it for the newcomers, and this is where IMO, there is a major gap, TODAY, to get the new generation interested you need a REPL, you need to prove major technological differentiation else it's and end game. https://www.researchgate.net/profile/Martin-Jakob-2/publication/259526734/figure/fig2/AS:669372850909208@1536602332979/Definition-of-technology-diffusion-paths-and-energy-saving-potentials.png

Key values the will need to proven:
Ease of use, improved efficiency, technical differentiation, ect . This can all be validated through many different things, one of them been the tools you deliver to the programmer or an exemplary amount of apps to reference. So not tools, not killer app, and no perceived efficiency, no jobs for the skills... that is a function (product) that will prove the same results time and time again.

Now, while that all sounds discouraging, it shouldn't, the talent & quality of the people behind the many Forth is amazing. Get one or two of those right, and you might be on to something... personal, I still look to Gforth as the baseline of where it can all start. Some cross compilers, and why not a vm inside forth? you could potently run a Forth app, that is a VM that has a Forth build on top of it.... the UXN vm seems like a great target for this, then all that needs to be done is cross compile it's VM to each of the target MCU's

For those concerned about commercial applications, plenty of room, but the market and users dictate what works, you can only influence the function, not the market...

Saludos desde Madrid!

[none albert]

In article <4fdfc7a2-4314-4951...@googlegroups.com>,

NN <novembe...@gmail.com> wrote:
>its free , easily available and widely discussed. eg jonesforth. I
>wouldnt say hypnotised
>but why wouldnt wanna be forthers want to see if you can do it too or better?

See yourforth, it is jonesforth with gratitious deviation from the
standard.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[none albert]

In article <8a90c051-25ec-4570...@googlegroups.com>,

It depends what your goal is. Forth is not always the right tool for
the job. I'm controlling three musical instruments playing simultaneously
with Forth. On the other hand I've written a sorting program where the
records are defined by regular expression in C++. Tricky programs that
ask for a database of objects (euler problems) I've written in Python.

[minf...@arcor.de]

NN schrieb am Montag, 28. November 2022 um 19:19:45 UTC+1:
> On Monday, 28 November 2022 at 15:57:05 UTC, minf...@arcor.de wrote:
> > NN schrieb am Montag, 28. November 2022 um 15:43:30 UTC+1:
> > > On Friday, 25 November 2022 at 15:07:26 UTC, Stephen Pelc wrote:
> > > > Secondly because people become hypnotised into writing their own Forth. Don't
> > > > do it, there are plenty available.
> > > > >
> > > its free , easily available and widely discussed. eg jonesforth. I wouldnt say hypnotised
> > > but why wouldnt wanna be forthers want to see if you can do it too or better?
> > There is this saying "fly like an eagle, don't scratch like a chicken". Build your own Forth
> > (one among thousands) can be like eternal ground scratching and become a waste of time.
> > (to remain fair: it can also be a fun hobby where time wasted does not count).
> >
> You are not speaking from the perspective of someone who's just starting to learn forth.
> Additionally learning about how it all works cant be a waste of time until you have done it
> once.

"It depends.." is always correct, as is "using a tool requires different skills than making a tool".
If you want to learn how to drive a car, it is better to practice driving.

[Paul Rubin]

NN <novembe...@gmail.com> writes:
> C is widely used and even if you want to get away from it you cant
> ignore it exists.

I don't think C is taught much in universities either. If you want to
teach low level programming, use assembly language. For high-level
programming, Python has become popular.

[Paul Rubin]

NN <novembe...@gmail.com> writes:
> I have said in the past that forth is difficult but its no more or
> less difficult than say haskell.

Forth is much easier than Haskell if you're a beginner trying to pick up
the basics. If you want to get really good, both are a lot of work, but
if you get good at Haskell, you will probably feel like you have
improved your mind. Forth to me feels more like mastering a complicated
video game. Ok, now what?

[SpainHackForth]

I just checked, C is def in the top Engineering curriculum for the major universities. Python was listed in the curriculum for Computer Science though.
You can do a lot in C that just would take ages in Assembly. Sure, you can inline code, but you would most likely embed ASM into a C function.

Here is the beauty of C, this is 133 lines with comments for an 8 bit virtual cpu... you can see the how long that would take in ASM...
https://godbolt.org/z/qMeKoevEa

I wonder how that would look in Forth... :)

[Paul Rubin]

SpainHackForth <jem...@gmail.com> writes:
> You can do a lot in C that just would take ages in Assembly. Sure, you
> can inline code, but you would most likely embed ASM into a C
> function.

Writing big programs in asm is not done much any more. The idea of
studying asm is to understand how low level programming works, not to
actually do a lot of it.

> Here is the beauty of C, this is 133 lines with comments for an 8 bit
> virtual cpu... you can see the how long that would take in ASM...
> https://godbolt.org/z/qMeKoevEa
> I wonder how that would look in Forth... :)

With a macro assembler, the asm version wouldn't be much worse than the
C version. The Forth version would be fairly similar.

[dxforth]

The parallels to what happened in hobby electronics is happening in computing.
Why DIY when someone has already done it, they ask. IMO it comes down to whether
one wants to experience the world for oneself - or be a player in someone else's
dream.

[Lorem Ipsum]

That's a joke, right? I see a smiley, but you delivered it very dryly.

--

Rick C.

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

[dxforth]

"Today I program mostly in Visual C++. Originally I hated 'C', but after five
years, it is bearable."

https://tomzimmer.files.wordpress.com/2016/06/an-interview-with-tom-zimmer.pdf

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 29/11/2022 5:19 am, NN wrote:
>> On Monday, 28 November 2022 at 15:57:05 UTC, minf...@arcor.de wrote:
>>
>>> There was one famous guy in the Forth world: Tom Zimmer. The author of ZForth, TCOM
>>> and F-PC and one of the "fathers" of Win32Forth. IIRC he left Forth altogether because
>>> he could never become as productive as with C++.

...

>"Today I program mostly in Visual C++. Originally I hated 'C', but after five
> years, it is bearable."
>
>https://tomzimmer.files.wordpress.com/2016/06/an-interview-with-tom-zimmer.pdf

It seems to me that you did not remember correctly. Thanks for the
correction.

- 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: https://euro.theforth.net

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> https://tomzimmer.files.wordpress.com/2016/06/an-interview-with-tom-zimmer.pdf

From page 5:

"Forth's most important feature has little to do with the fact that
it is a stack language, it has instead to do with the way it
interacts as a whole with the user. Forths extensibility, structure,
modularity and very simple syntax are key attributes that give the
programmer freedom to structure solutions for problems in ways that
programmers of other languages cannot understand or attempt."

Nice. I wonder what Chuck Moore would say about that.

[Lorem Ipsum]

I find this an odd statement. The fact that there is an implied stack instead of a parameter list is one of the main features that makes the language easily extensible and modular with a simple syntax. Take away the implied stack(s) and you have another interpreted language. It's not like Forth is the only one. Heck, I remember using a debugger that would allow you to type in individual lines of C code for immediate execution.

--

Rick C.

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

[none albert]

In article <871qpmz...@nightsong.com>,

I went to a course: Safer C. Apparently bugs per line of code is
constant across the board. The course leader doesn't understand
what the advantage is of small modules in programming.

The macro assembler illustrates the point. A 500 line assembler
program shrinks to 100 lines, if a couple of strategic macro's
are introduced, and the bugs list shrinks proportionally.
This is IMHO one of the reasons Forth is reliable, its reliance
on small components that are thoroughly tested.

[minf...@arcor.de]

none albert schrieb am Dienstag, 29. November 2022 um 11:21:27 UTC+1:
> In article <871qpmz...@nightsong.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
> >SpainHackForth <jem...@gmail.com> writes:
> >> You can do a lot in C that just would take ages in Assembly. Sure, you
> >> can inline code, but you would most likely embed ASM into a C
> >> function.
> >
> >Writing big programs in asm is not done much any more. The idea of
> >studying asm is to understand how low level programming works, not to
> >actually do a lot of it.
> >
> >> Here is the beauty of C, this is 133 lines with comments for an 8 bit
> >> virtual cpu... you can see the how long that would take in ASM...
> >> https://godbolt.org/z/qMeKoevEa
> >> I wonder how that would look in Forth... :)
> >
> >With a macro assembler, the asm version wouldn't be much worse than the
> >C version. The Forth version would be fairly similar.
> I went to a course: Safer C. Apparently bugs per line of code is
> constant across the board. The course leader doesn't understand
> what the advantage is of small modules in programming.
>
> The macro assembler illustrates the point. A 500 line assembler
> program shrinks to 100 lines, if a couple of strategic macro's
> are introduced, and the bugs list shrinks proportionally.
> This is IMHO one of the reasons Forth is reliable, its reliance
> on small components that are thoroughly tested.

"Thoroughly tested" in Forth means individual programmer's discipline
not a special language property.
Write short C functions plus asserts and you are in the same ballpark.

[SpainHackForth]

Ok, just to clarify, I’m more concern in finding ways to expand the outreach of Forth as a valuable tool for embedded systems programing, not the contrary. I was giving an example for the possible, and how different the C community is in building and sharing, where learning and diffusion/sharing of knowledge happens at a broad scale.

Also, without tung in cheek, I was referring to a neat little VM that could probably be extended with a direct Forth bootstrap to the HW to run Forth on top. Also, I really like the notion of mcu simulator/vm siting on top of a Forth systems to emulate the target hw. You can then have a hosted Forth on the VM to test and develop your code and cross compile it if need to create a distributable app for the target MCU. It would allow for the creation of tools to visualize interaction with external peripherals.

I still like the idea of cross-compilers in forth to extend portability of apps without the need to install a repl or runtime to make it usable.

thoughts?

[Lorem Ipsum]

But very few do, while this is common in Forth. Why? Because Forth quickly becomes hard to understand otherwise.

--

Rick C.

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

[Zbig]

> > Write short C functions plus asserts and you are in the same ballpark.
> But very few do, while this is common in Forth. Why? Because Forth quickly becomes hard to understand otherwise.

…because Forth is a toolkit allowing you to design your own „application-specific language”.

[Paul Rubin]

Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> The fact that there is an implied stack instead of a parameter list is
> one of the main features that makes the language easily extensible and
> modular with a simple syntax.

Surely Lisp is all of those things too, and it doesn't have an implied
stack in the same way.

[dxforth]

Surely not just in forth. If by discipline we mean methodical testing,
documenting etc then I don't - mainly because I work alone and my hobby
programming doesn't require it. Should I notice something amiss, of
course I'll fix it.

In CP/M we had access to extensive machine-code libraries but it never
interested me enough to use them. I get the impression few ever did
and not for lack of quality. I suspect the investment was too much,
at least for me.

[dxforth]

On 30/11/2022 6:47 am, Lorem Ipsum wrote:
>
> But very few do, while this is common in Forth. Why? Because Forth quickly becomes hard to understand otherwise.

Completely agree. I know it's bad form to suggest Forth does stuff out of
necessity rather than choice but there it is. That said, I can no longer
look at page-length C functions without squirming (or nested functions).

[dxforth]

The stack is a means to an end - not an end in itself?

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> The stack is a means to an end - not an end in itself?

Precisely. Now how to reconcile that with "don't use locals"? ;-)

[dxforth]

Where does Zimmer say locals are a viable alternative? :)

[Jan Coombs]

On Mon, 28 Nov 2022 13:20:13 -0800 (PST)
SpainHackForth <jem...@gmail.com> wrote:

> Here is the beauty of C, this is 133 lines with comments for an 8 bit virtual cpu... you can see the how long that would take in ASM...
> https://godbolt.org/z/qMeKoevEa

Wondered about writing a hardware description, to check the text size,
but could not find any documentation :----(

Jan Coombs
--

[SpainHackForth]

> Wondered about writing a hardware description, to check the text size,
> but could not find any documentation :----(
>
> Jan Coombs
> --

More here... https://git.sr.ht/~rabbits/uxn11/

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> Where does Zimmer say locals are a viable alternative? :)

The objection to locals is basically that they don't strictly follow the
doctrine of the stack VM. Zimmer says the stack VM is not that
important. That to me makes the objection go away. If the stack VM is
not important, the following the doctrine is not that important either.

[juan tecla]

El jueves, 24 de noviembre de 2022 a la(s) 19:19:05 UTC-3, SpainHackForth escribió:
> Hi all, may be my over incitement for Forth at the moment as I feel like there is so much value for it, and I have been pondering several aspects of the language, ideas on how to best leverage it and furthermore, extend the adoption of Forth and the Forth way.
>
> Question; why has Forth not been as prolific as other languages?
>
> Views:
> Why is there a lack of cross compiler on Forth?
> - IMHO, this is an area where Forth could do the community a great deal of good. If for example, there where crosscompilers for the embedded environments, this would potentially drive the adoption of the Language. Another thing that could be really interesting, Forth is a VM, why not extend CPU simulation on Forth, where one would test those targeted systems and make it "simple" to see how the app behaves at the hardware level and how to optimize it. I know metaprograming just looks natural in Forth, yet I see lots of Python, JS, and Java as having a large number of instruction set sims ( ISS ) out there on these platforms, I have not found a single one on Forth ( maybe I have not looked hard enough )
>
> Further more, one are of inspiration is having something like https://cpulator.01xz.net/?sys=arm-de1soc&d_audio=48000
> Well, that is a dream, but if you thing about it, the front end could run on a browser, the back end could be a forth system... If that is too much to ask, consider Gerog Heinrichs neat little MikroForth, well and if that is too much to ask then consider the following.. .
>
> Program offset instruction Dis-assembled register/ storage (after execution)
> TEST001 000000 X'05C0' BALR R12,0 R12=002CE00A
> 000002 X'47F0C00E' BC 15,X'00C'(R12)
> 00000E X'98ECD00C' STM R14,R12,X'00C'(R13) X'002E0008' ==> X'00004CE,002CE008,..etc....'
> 000012 X'45E0C122' BAL R14,X'122'(R12) R14=002C0016
> SUB1 000124 X'50E0C28A' ST R14,X'28A'(R12) X'002CE294' ==> X'002C0016'
> etc...
> Ok, even a GDB interface to the ISS would be enough, really! :)
>
> Furthermore, on the basis of use cases, I see lot's of discussion and people building FPGA based stack CPU's. I apologize in advance form my ignorance on the matter, but isn't Fort a VM for a CPU sort of speak? What can you really get out of substantially over priced, under power, higher barrier to entry, where you are designing the hardware, with it's pitfalls in the development phase, then the Forth that sits o top ( Ok so forth is the machine code, cool science project, one I would like to test ) but for a commercial application, I find to make the economic connection and or benefits.
> If Forth is a VM kernel , would it not make sense to spend the time to have a vm that has a native Programmable Interrupt Controller with built in interrupt priority levels and streamline the code executed on these systems? I look at all the bloat that goes into projects like OpenWRT, and I just wonder if they where not better off moving to bare metal ( FORTH ) to deliver better performance? I also see that with the excess of compute available in the Arch64 space, there is plenty of opportunities to improve the performance and even consider, can you run a vm on top of a Forth kernel? That could be a way to further extend the portability of the system.
>
> One area I see that this could be interesting is in high end embedded systems, where the CPU is really a peripheral of a larger systems, like dedicated cards that do networking or caching on larger servers... those systems build extensive and expensive systems, that have all the linux bloat on them, when in the end all they run is a 10K lines of code with a very specif purpose. I thought Forth could be the kernel. for these systems.
>
> Furthermore, Forth brings another interesting option, if you are running a forth vm on top of a forth vm that runs the app or part of the app ( think of containers speaking to each-other at CPU speed.), then near real time upgrades could be possible or even bitecode up-gradable ( just updating the dictionary to point to a new portion of the code could be possible, that is a strong business case if you are targeting edge devices... smart meters, ect...
>
> Just so much could be done.
>
> Thoughts? Rebuttals? Ideas?

You can Join to forth2020 group
https://www.forth2020.org/

All forthers are welcome

[dxforth]

On 1/12/2022 8:37 am, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
>> Where does Zimmer say locals are a viable alternative? :)
>
> The objection to locals is basically that they don't strictly follow the
> doctrine of the stack VM. Zimmer says the stack VM is not that
> important.

That would be your interpretation of what he said. I didn't read it that way at all.

> That to me makes the objection go away.

You want it to go away because you're determined to use Forth as if it were C.

> If the stack VM is
> not important, the following the doctrine is not that important either.

Sorry but * / + - etc in Forth are defined to consume values from the stack and
leave their results there. One can optimize locals all one likes, it doesn't
change the VM which uses a data stack (not local variables) for communication.

[Lorem Ipsum]

Reconcile what exactly? The two seem unrelated to me.

--

Rick C.

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

[Zbig]

> > Where does Zimmer say locals are a viable alternative? :)

> Where does Zimmer say "never use locals"?
Where does Zimmer say anything at all about locals?

> Just now I looked at the W32F source and counted 388 definitions with locals.

Maybe Tom isn't the author of these. Or maybe he is the creator
of some of them indeed — but he created them with disgust. ;)

[minf...@arcor.de]

Masochism and delight are a true Forther's true passions.

[dxforth]

On 2/12/2022 1:08 am, Doug Hoffman wrote:

> On Wednesday, November 30, 2022 at 3:25:38 AM UTC-5, dxforth wrote:
>
>> Where does Zimmer say locals are a viable alternative? :)
>

> Where does Zimmer say "never use locals"?

Zimmer doesn't mention them at all. Paul brought locals into the conversation
by suggesting (with scant evidence) Zimmer didn't consider a stack-based VM
necessary. I can't fathom what a Forth without a data stack would look like.

> If he believed that
> then he apparently had little or no influence on his fellow W32F
> programmers. Just now I looked at the W32F source and

> counted 388 definitions with locals.

How many definitions in F-PC used locals? Zero? So what changed between
F-PC and Win32Forth - ANS-Forth? According to Moore, ANS-Forth was 'another
language having the same name'. Perhaps that answers the question Paul
raised as to what Moore would think.

> I am not very familiar with W32F so if anyone has better knowledge
> of this please correct me if needed.
>
> -Doug

[dxforth]

The better question is where they're used. If used out of laziness, that's
hardly 'good Forth'. If used because Windows API makes them hard to avoid,
then they're on a par with prostitution.

[dxforth]

Perhaps, as with life, Forth wasn't meant to be easy ...

https://quotepark.com/quotes/1887684-malcolm-fraser-life-wasnt-meant-to-be-easy/

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>Perhaps, as with life, Forth wasn't meant to be easy ...

How's that for a dxforth-style slogan: "Forth, the language that makes
even easy things hard."

I, OTOH, prefer to make things easy, not just for the system
implementor, but also for the system user.

- 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: https://euro.theforth.net

[dxforth]

On 2/12/2022 7:12 pm, Doug Hoffman wrote:

> On Thursday, December 1, 2022 at 6:51:05 PM UTC-5, dxforth wrote:
>
>>> On Wednesday, November 30, 2022 at 3:25:38 AM UTC-5, dxforth wrote:
>>>
>>>> Where does Zimmer say locals are a viable alternative? :)
>

>> Zimmer doesn't mention them at all.
>

> Then why did you ask where he said they are a viable alternative?

Because it was Paul who suggested it:

https://groups.google.com/g/comp.lang.forth/c/A9c5gYMK1rY/m/XVmPkSrDCAAJ

> On Thursday, December 1, 2022 at 11:08:26 PM UTC-5, dxforth wrote:
>
>> Perhaps, as with life, Forth wasn't meant to be easy ...
>

> Hardly a way to encourage potential new Forth programmers
> that are reading this thread.

This is what Moore said in 1980:

"Let me use a tool which I appreciate and if everyone can't use
this tool well, I am sorry, but that is not my goal."

Did it stop you from learning Forth and coming to grips with it? If not,
then why should it stop newcomers today? Are they less capable than your
generation? ISTM if anyone is telling newcomers Forth is too hard, it is
those looking at other languages and saying 'wouldn't it be nice if Forth
had that'.

[Zbig]

> This is what Moore said in 1980:
>
> "Let me use a tool which I appreciate and if everyone can't use
> this tool well, I am sorry, but that is not my goal."
>
> Did it stop you from learning Forth and coming to grips with it? If not,
> then why should it stop newcomers today? Are they less capable than your
> generation? ISTM if anyone is telling newcomers Forth is too hard, it is
> those looking at other languages and saying 'wouldn't it be nice if Forth
> had that'.

Moore continued immediately after that: „…In that sense Forth is an elitist
language. On the other hand, I think that Forth is a language that
a grade-school child can learn to use quite effectively if it's presented
in the proper bit-size pieces, with the proper motivation”.

So instead of insisting on locals / OOP / stuff like that the proper approach
is to learn how to use Forth's tools.

[none albert]

In article <1f6793f9-d51e-47fc...@googlegroups.com>,

I did an experiment once. A friend was a psychology student in the 80's
with no prior exposure to computers. He bought a Jupiter Ace and
the only tools is Forth. After a few lessons he surprised me.
He had written a pong game. It was primitive, but a game with
real time interaction is not an assignment you give to a newbie.
(It is fair to say that his intelligence surpassed that of the
average Trump voter. Elitist? )

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Doug Hoffman]

On Friday, December 2, 2022 at 7:18:36 AM UTC-5, none albert wrote:

> It is fair to say that his intelligence surpassed that of the
> average Trump voter.

What is the intelligence of the average Trump voter and how was that
determined? This is over 74 million people. Please provide a reference.

-Doug

[dxforth]

On 2/12/2022 7:46 pm, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> Perhaps, as with life, Forth wasn't meant to be easy ...
>
> How's that for a dxforth-style slogan: "Forth, the language that makes
> even easy things hard."

Not my slogan.

> I, OTOH, prefer to make things easy, not just for the system
> implementor, but also for the system user.

And to do that you need to say Forth is hard :)

[dxforth]

On 3/12/2022 3:37 am, Doug Hoffman wrote:

> On Friday, December 2, 2022 at 6:19:13 AM UTC-5, dxforth wrote:
>> On 2/12/2022 7:12 pm, Doug Hoffman wrote:
>>> On Thursday, December 1, 2022 at 6:51:05 PM UTC-5, dxforth wrote:
>>>
>>>>> On Wednesday, November 30, 2022 at 3:25:38 AM UTC-5, dxforth wrote:
>>>>>
>>>>>> Where does Zimmer say locals are a viable alternative? :)
>>>
>>>> Zimmer doesn't mention them at all.
>>>
>>> Then why did you ask where he said they are a viable alternative?
>> Because it was Paul who suggested it:
>>
>> https://groups.google.com/g/comp.lang.forth/c/A9c5gYMK1rY/m/XVmPkSrDCAAJ
>

> Wrong link? Nothing there from Paul suggesting Zimmer said locals are
> a viable alternative.

What I told him.

>>> On Thursday, December 1, 2022 at 11:08:26 PM UTC-5, dxforth wrote:
>>>
>>>> Perhaps, as with life, Forth wasn't meant to be easy ...
>>>
>>> Hardly a way to encourage potential new Forth programmers
>>> that are reading this thread.
>> This is what Moore said in 1980:
>>
>> "Let me use a tool which I appreciate and if everyone can't use
>> this tool well, I am sorry, but that is not my goal."
>>
>> Did it stop you from learning Forth and coming to grips with it? If not,
>> then why should it stop newcomers today?
>

> No. YOU said "Perhaps, as with life, Forth wasn't meant to be easy".

was in response to minforth's:

"Masochism and delight are a true Forther's true passions."

> Potential newbies to Forth will stop right there in this forum and not
> research Moore to try to extract what he meant by his many statements.

Compared to the alternative who run scare campaigns to get votes, Moore
is the better choice. Personally, I think one has to find one's own way.

[none albert]

In article <30eafa4d-4099-454f...@googlegroups.com>,

He was academic level intelligence. The 74 million people are bound to be
average, consisting of loosers (predominantly) and grifters (more intelligent,
but few). On the condition that they vote Trump the average intelligence
looses a few point on the US average as a whole, I guess.

Say that we miss that mark of a few points.
That is not to say the average surpass the 120/130 mark my friend has.
It is a cheap shot to substitute "Trump voter" for people in general.
It was trolling, and you fell for it.

>
>-Doug

[Doug Hoffman]

On Saturday, December 3, 2022 at 5:33:45 AM UTC-5, none albert wrote:

> It is a cheap shot to substitute "Trump voter" for people in general.
> It was trolling, and you fell for it.

It is political commentary that doesn't belong here, and I
called you out on it.

-Doug

[SpainHackForth]

Thanks for all the feedback.

One thing that I still fascinating is that Dr. Ting discussed the tened for a VM for Forth particularly looking at the JAVA VM a means to get native support of Forth and most important the portability of the code *app.

[SpainHackForth]

On Sunday, December 4, 2022 at 12:48:53 AM UTC+1, SpainHackForth wrote:
> Thanks for all the feedback.
>
> One thing that I still fascinating is that Dr. Ting discussed the tened for a VM for Forth particularly looking at the JAVA VM a means to get native support of Forth and most important the portability of the code *app.

Ok the Ipad is playing with me tonight…

I was mentioning the importance of having a ForthVM as a means to get portability across HW layers, reduces the efforts of the endless number of Forth’s…

It’s no different than JAVA itself, just that having the interpreter it gives you all the benefits of removing the dependencies for cross compilers… you can still have a *bytecode compiler to export to a native code if needed… but it would certainly have a nice use case…

As pose this as a question as I’m not the one that come up with the idea, but is there such a Forth that bootstraps the JVM or is there such a ForthVM that allows for this?

Not to rehash the 1996 conversation on the minimal words, would be nice to have a list of words to properly implement such a machine…

[dxforth]

Does it include Colburn's 'Sacred Cows' piece which could be construed
as political theatrics targetting forth conservatives?

[none albert]

In article <7f3d0afb-6e87-45e1...@googlegroups.com>,

SpainHackForth <jem...@gmail.com> wrote:
>On Sunday, December 4, 2022 at 12:48:53 AM UTC+1, SpainHackForth wrote:
>> Thanks for all the feedback.
>>
>> One thing that I still fascinating is that Dr. Ting discussed the
>tened for a VM for Forth particularly looking at the JAVA VM a means to
>get native support of Forth and most important the portability of the
>code *app.
>Ok the Ipad is playing with me tonight…
>
>I was mentioning the importance of having a ForthVM as a means to get
>portability across HW layers, reduces the efforts of the endless number
>of Forth’s…

It is funny that you apparently object to the endless number of
Forth's and not to the endless number of Java implementations that are
needed to support the ForthVM.

[SpainHackForth]

> It is funny that you apparently object to the endless number of
> Forth's and not to the endless number of Java implementations that are
> needed to support the ForthVM.
> Groetjes Albert

Not sure I follow you, I never object to anything, if that is how you are interpreting, then I suggest you re-read my comments.
Just to keep the conversation going, my statement is simple, if you have a standard ForthVM ( I've not seen one yet that remotely looks like a VM) then the issue of cross compilers is only left to the ForthVM cross deployment. This serves two purposes in my view:
1. Enable a consistent Forth language, where the Application Portability is the main benefit.
2. Limit the community effort to provide ForthVM targets rather than entire rewritten Forths

Not sure how that amuses you ( to each it's own, ) but that is my view on the subject.

[Zbig]

> > Where does Zimmer say locals are a viable alternative? :)

> The objection to locals is basically that they don't strictly follow the
> doctrine of the stack VM. Zimmer says the stack VM is not that

> important. That to me makes the objection go away. If the stack VM is

> not important, the following the doctrine is not that important either.

But actually we can help ourselves in the cases when the stack becomes
too cluttered still not resorting to locals — neither by polluting the vocabulary
with temporary variable's names; I mean the proposal explained in the article
„Anonymous Variables” (FD vol. 6 nr 1 page 33 — May/June 1984).

[none albert]

In article <bee6f122-dbe8-4eba...@googlegroups.com>,

I'm looking at my ciforth. There is a limited number of primitives, on top there
is a FORTH VM . Now look at the library. PRIME? CHS RAND and other calculating
stuff is reasonable portable.
As soon as you get at TIME&DATE GET-ENV TICKS PIPE serial communication etc.
those stuff are Operating System dependant.
Does Java solve any of this?
There is a new format of pictures. Do I write this in Forth or Java and then
suffer an extra layer?

[dxforth]

Having accepted the stack becomes cluttered, all that's left to decide is
what scheme to use and ANS-Forth has already done that.

[SpainHackForth]

On Sunday, December 4, 2022 at 7:16:40 PM UTC+1, none albert wrote:
> In article <bee6f122-dbe8-4eba...@googlegroups.com>,
> SpainHackForth <jem...@gmail.com> wrote:
> >
> >> It is funny that you apparently object to the endless number of
> >> Forth's and not to the endless number of Java implementations that are
> >> needed to support the ForthVM.
> >> Groetjes Albert
> >Not sure I follow you, I never object to anything, if that is how you are interpreting, then I suggest you re-read my comments.
> >Just to keep the conversation going, my statement is simple, if you have a standard ForthVM ( I've not seen one yet that remotely looks like a VM) then the
> >issue of cross compilers is only left to the ForthVM cross deployment. This serves two purposes in my view:
> >1. Enable a consistent Forth language, where the Application Portability is the main benefit.
> >2. Limit the community effort to provide ForthVM targets rather than entire rewritten Forths
> >
> >Not sure how that amuses you ( to each it's own, ) but that is my view on the subject.
> >
> I'm looking at my ciforth. There is a limited number of primitives, on top there
> is a FORTH VM . Now look at the library. PRIME? CHS RAND and other calculating
> stuff is reasonable portable.
> As soon as you get at TIME&DATE GET-ENV TICKS PIPE serial communication etc.
> those stuff are Operating System dependant.
> Does Java solve any of this?
> There is a new format of pictures. Do I write this in Forth or Java and then
> suffer an extra layer?

Albert, had a peek at your ciforth, nice work, looks like a well structured project!
I believe we are fundamentally diverging on what I’m considering a VM is, it’s nothing more than an abstraction layer to the foundation of the HW, I’m thinking mostly bare metal, but it would apply the physical HW or the hosted OS. Yes, the abstraction is there, and that is the whole purpose, it makes the inner interpreter common regardless of the plalform. The outer interpreter will always be the same also, so it makes it more compact to port from one system to the other.

Here is a real life example… this forth http://www.call-with-current-continuation.org/uf/uf.html compiled, I can run it on my Linux, or my OS X, or my Windows, or a ESP32 or a RPi or a RP2040…the same code… and all the applications written for it, they all run the same code… and I can compile it and run it native on the VM on any of those platform.

And the beauty of the VM, it’s a stack based system, in a way, it behaves as a forth with in a forth…

[Jan Coombs]

On Sat, 3 Dec 2022 15:48:52 -0800 (PST)
SpainHackForth <jem...@gmail.com> wrote:

> One thing that I still fascinating is that Dr. Ting discussed the tened
> for a VM for Forth particularly looking at the JAVA VM a means to get native
> support of Forth and most important the portability of the code *app.

... conversely, ...

There were a handful of processors that executed Jave byte code directly, or
translated it in hardware. Can only see a couple now, one of which is:

PSC1000 'ShBoom' from Chuck Moore, promoted for "Native execution of Java" ...
"The processor is based upon Patriot’s patented ShBoom dual stack architecture,
which enables the native execution of Java code." ... "The processor is
targeted for embedded applications that require high MPU performance and low
system cost. In addition, the processor’s ability to execute Java natively makes
it an ideal choice for Java-based devices."
https://en.wikipedia.org/wiki/Ignite_(microprocessor)

Jan Coombs
--