An interesting read that I think supports Anton's observations on "undefined behaviour" in C and frustrations in using it to build GForth.

Maybe GForth should be written in GForth now. (?)

https://arxiv.org/abs/2201.07845

Brian Fox schrieb am Freitag, 21. Januar 2022 um 16:30:46 UTC+1:
> An interesting read that I think supports Anton's observations on "undefined behaviour" in C and frustrations in using it to build GForth.
>
> Maybe GForth should be written in GForth now. (?)
>
> https://arxiv.org/abs/2201.07845

Thanks for the link.

To build the fastest Forth you have to write it in assembly, but you
lose portability - an old adage. C as 'universal portable assembly language'
has always been a compromise. Whether the compromise is weak
(and frustrating) or not depends on the design targets.

C++, Ada, Rust etc. are often not there for a new target platform,
but very often gcc is already available with hardware-specific libraries.

Therefore in practice there is just no other way than to cope with UB.

On Saturday, January 22, 2022 at 1:30:46 AM UTC+10, Brian Fox wrote:
> An interesting read that I think supports Anton's observations on "undefined behaviour" in C and frustrations in using it to build GForth.
>
> Maybe GForth should be written in GForth now. (?)
>
> https://arxiv.org/abs/2201.07845

I can't get to read this all today. But the solution is to have an sub ISO suitable for OS, Embedded maybe, and high speed Cv (C down low). But, one desire I have is a more universal transportable experience based on JavaScript engine. In the creation of new operating systems, you often lack application code base, by supporting the JavaScript engine (a constructed Java) libraries, even if not JavaScript itself (though it is basically C like) you get the other side. With this, is machine code particles (segments of machine code, which android supports, and Google had a proposal in use for web pages, which really needed total sandboxing), depending on which processor exists is which version loaded. In C development, it was 80% of the speed of assembler, but this means that at times it could be far slower, and these bottlenecks can kill code all of a sudden.

So, apart from above, what we really need is a universal assembler like language product, using the following criteria (as a subset of the above Cv, so that existing C libraries can be used). Here we have logical organising instruction flow structures that the compiler can ideally compile, with the user able to code the machine code particles for each processor supported directly. These days, outside embedded, we are co.inf to only a few processor options, bit, you only need to use one version of the assembler, and it would model the behaviour of that processor's and code's behaviour in translating to another processor. This is where expert translation techniques can be used in the compiler, done for experts and the chip manufacturers, products Cing a more streamlined performance automatically, few have the skill to by hand (with the option to do your own, as a particle, or get the auto generated version, and cisto use it. In this, as long as you don't revert to normal C context, you retain pure machine code flow, going back to C enables a context swap, so that the machine code or C state is swapped to the other, with the C compiler minimising the swap by compiling to be more compatible with the machine code particle. The developer can remain in assembler as much as they want. The trick developers need to use, is to minimise the cpu resources used, to what is needed, allowing the compiler more flexibility and in translating to another processor. If they need more, they can program one, or more particles. But, the experience is assembler in a C like construct. A number of high level C constructs would be available, but limited to those that can efficiently translate to machine code without loose. Here a little abstraction can be used, to program in a more C like fashion that it translated to 100% efficient machine language constructs. You can only program in an assembler that the compiler supports, but the little abstraction model, lies you to avoid local assembler versions, and just use that, and the compiler will use it to generate code. The trick is to always minimise and use less, so the compiler can do a better job. But, this all gives many natural options for portability and for performance efficiency, the developer just chooses the level they will work at, with specialists optimising certain machine code particles. As is done now, particularly in high end games code, where key routines or sections maybe machine code, to maximise engine performance. In OS development, drivers, and middleware, ideally, it should always be used, which would be a smoother experience. These are my thought related to my own OS development proposals. C fur portability, next round the actual language I was to use based on the processor virtual machine (developing machine code for the processor based on it), then machine code particle versions, if not complete machine code, in the finale round of development. In this, it can quickly be pushed out to new processors, when you get income to pay for it, you implement the OS code in VM, and when you get more money, you further refine it to machine code. At first there will only be a C platform for new processors, before you learn how to implement the VM, then learn custom machine code to maximise performance. The OS, drivers and middleware, are where your easiest to address common losses are, that add up. That was my corporate strategy. Once you get everything right, people's scripts will work faster (where you can't do anything but advise them on best coding). Compared to what was done, it would be a major improvement, as I was designing the instruction set, VM, communications and object structures, flow, processing, API's, language for maximum performance, where next to no wastage on the VOS on native processor, and next to no lose on many descent processors, in most of the system. As far as I know, there is only one machine code based OS on the x386 code.

Wayne morellini schrieb am Samstag, 22. Januar 2022 um 07:28:32 UTC+1:
> On Saturday, January 22, 2022 at 1:30:46 AM UTC+10, Brian Fox wrote:
> > An interesting read that I think supports Anton's observations on "undefined behaviour" in C and frustrations in using it to build GForth.
> >
> > Maybe GForth should be written in GForth now. (?)
> >
> > https://arxiv.org/abs/2201.07845
> I can't get to read this all today. But the solution is to have an sub ISO suitable for OS, Embedded maybe, and high speed Cv (C down low). But, one desire I have is a more universal transportable experience based on JavaScript engine. In the creation of new operating systems, you often lack application code base, by supporting the JavaScript engine (a constructed Java) libraries, even if not JavaScript itself (though it is basically C like) you get the other side. With this, is machine code particles (segments of machine code, which android supports, and Google had a proposal in use for web pages, which really needed total sandboxing), depending on which processor exists is which version loaded. In C development, it was 80% of the speed of assembler, but this means that at times it could be far slower, and these bottlenecks can kill code all of a sudden.
<snip>

Containerization, sandboxing, JIT compilation etc. may be fine for user land.
But I doubt that these techniques are attractive for building performant OS
or Forth systems.

Brian Fox <brian.fox@brianfox.ca> writes:
>An interesting read that I think supports Anton's observations on "undefined behaviour" in C and frustrations in using it to build GForth.
>
>Maybe GForth should be written in GForth now. (?)

It is mostly written in Gforth. For the parts that use a GCC, we have
been thinking about how to eliminate them for some time:

@InProceedings{ertl14-c,
author = {M. Anton Ertl},
title = {How to get rid of {C}},
crossref = {euroforth14},
pages = {63--65},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/ertl-c.pdf},
video = {http://www.forth-ev.de/wiki/doku.php/events:euroforth-2014:ridofc},
OPTnote = {Presentation slides}
}

@Proceedings{euroforth14,
title = {30th EuroForth Conference},
booktitle = {30th EuroForth Conference},
year = {2014},
key = {EuroForth'14},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/proceedings.pdf}
}

But we have not taken action yet.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Saturday, January 22, 2022 at 8:27:08 PM UTC+10, minf...@arcor.de wrote:
> Wayne morellini schrieb am Samstag, 22. Januar 2022 um 07:28:32 UTC+1:
> > On Saturday, January 22, 2022 at 1:30:46 AM UTC+10, Brian Fox wrote:
> > > An interesting read that I think supports Anton's observations on "undefined behaviour" in C and frustrations in using it to build GForth.
> > >
> > > Maybe GForth should be written in GForth now. (?)
> > >
> > > https://arxiv.org/abs/2201.07845
> > I can't get to read this all today. But the solution is to have an sub ISO suitable for OS, Embedded maybe, and high speed Cv (C down low). But, one desire I have is a more universal transportable experience based on JavaScript engine. In the creation of new operating systems, you often lack application code base, by supporting the JavaScript engine (a constructed Java) libraries, even if not JavaScript itself (though it is basically C like) you get the other side. With this, is machine code particles (segments of machine code, which android supports, and Google had a proposal in use for web pages, which really needed total sandboxing), depending on which processor exists is which version loaded. In C development, it was 80% of the speed of assembler, but this means that at times it could be far slower, and these bottlenecks can kill code all of a sudden.
> <snip>
>
> Containerization, sandboxing, JIT compilation etc. may be fine for user land.
> But I doubt that these techniques are attractive for building performant OS
> or Forth systems.

Not really a fan of JIT. Above, the java script APIs can be used, and JavaScript generated if you want (I'm really for compiled JavaScript instead, or that demoted machine code technology Google supported, but in Sandbox containers).

Now, in my own design complete sand box virtual machine with virtually no overhead in a more efficient structure, whatever they call it nearly 30 years latter. As they have learnt today you definitely need virtualisation.

To isolate commercial systems from attacks yes, it's needed. Performance, need to do it right.

"minf...@arcor.de" <minforth@arcor.de> writes:
>To build the fastest Forth you have to write it in assembly,

No, you have to write a native-code compiler, and you can write that
in Forth. Look at cmForth for a simple example or FLK for a more
complex one.

If you are thinking about the fastest threaded-code Forth systems:
Bernd Beuster thought that he could do better than Gforth by using
instructions like LODS, but on the 486 (current at the time) LODS took
twice as long as the equivalent sequence of simple instructions. And
if you look at
<http://www.complang.tuwien.ac.at/forth/performance.html>, you find
that on the 486 Gforth 0.4.9 beats all interpreters written in
assembly language except Marcel Hendrix' eforth+opt.

>C++, Ada, Rust etc. are often not there for a new target platform,
>but very often gcc is already available with hardware-specific libraries.

With gcc you get C++ and Ada, not yet Rust.

>Therefore in practice there is just no other way than to cope with UB.

Whatever you mean by "cope". We regularly go over gcc options and set
those that look like they disable UB nonsense (and some other things
we don't want). Currently we use the following options (each
introduced with "-f"):

no-gcse caller-saves no-defer-pop no-inline wrapv char-unsigned
no-strict-aliasing no-cse-follow-jumps no-reorder-blocks
no-reorder-blocks-and-partition no-toplevel-reorder no-trigraphs
align-labels=1 align-loops=1 align-jumps=1
no-delete-null-pointer-checks cf-protection=none

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> With gcc you get C++ and Ada, not yet Rust.

Rust is in progress: https://rust-gcc.github.io/

Maybe WASM will become another candidate for intermediate code.

Paul Rubin schrieb am Samstag, 22. Januar 2022 um 21:47:31 UTC+1:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > With gcc you get C++ and Ada, not yet Rust.
> Rust is in progress: https://rust-gcc.github.io/
>
> Maybe WASM will become another candidate for intermediate code.

AFAIK wasm modules run sandboxed. This seems contrary to Forth
with its emphasis on direct CPU and hardware control.

"minf...@arcor.de" <minforth@arcor.de> writes:
> AFAIK wasm modules run sandboxed.

That's just in browsers. Maybe wasm will metastasize elsewhere. Idk
whether that would be good or bad.

Paul Rubin schrieb am Montag, 24. Januar 2022 um 22:22:51 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > AFAIK wasm modules run sandboxed.
> That's just in browsers. Maybe wasm will metastasize elsewhere. Idk
> whether that would be good or bad.

I have to explore this further. On my 'exploration' list is binaryen
https://github.com/WebAssembly/binaryen

But it seems to be a complex optimizing compiler in its own world
and might do as many uncontrollable things under the hood as gcc.

On Tuesday, January 25, 2022 at 7:22:51 AM UTC+10, Paul Rubin wrote:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > AFAIK wasm modules run sandboxed.
> That's just in browsers. Maybe wasm will metastasize elsewhere. Idk
> whether that would be good or bad.

Maybe I have listened to Rick Richards of Arius, or whatever, but why do people have to go crazy when something is mentioned. This is about C use on constructing operating systems, and alternative bits and pieces. My mention of Java script API's was on a higher level app code portability for kicking off new app bare operating systems, and establishing an independent app base that developers can program for sale across systems. This is about multi-level complete holistic solutions. Using not webassemble, but the old machine code sections to speed this up further. And hypervising/sandboxing need take virtually no performance hit. What bad designers and programmers do,; s irrelevant, those people are different and seperate from good design practice. C is the enemy itself. It was based of of wrong concepts. And demands the hardware support those wrong concepts to keep going. But, C, is where the base code base for operating systems, drivers and middleware are fur getting operating systems implemented quickly, and standard fur doing the other work.

On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:
> But it seems to be a complex optimizing compiler in its own world
> and might do as many uncontrollable things under the hood as gcc.
Well, Dennis has objected several times during the "standardization" process. What came out was certainly not what he intended it to be. IMHO he went wrong himself in several places, e.g. the operators. You cannot let the compiler decide what to do when you're stupid enough to add an integer to a float. You should simply bomb out. It's bad enough you can add an unsigned to signed. In that respect - although Forth is complete Wild West - it's behavior is much more consistent. You don't get to add a float to an integer without conversion - or you're in a world of pain.

This problem is even aggravated IMHO when you add other composed datatypes - without the proper precautions, like "longs". Again, Forth is far more transparent and consistent here. You do floats with F+ (both sides need to be float), double words with D+ and single words with +. I think C would have won in consistency is that had been a prerequisite to begin with.

Collating specific behavior with certain datatypes doesn't help either. Shifting right an unsigned gives you different behavior than signed. Nowadays, shifting a word by more bits than the wordsize is already "suspect". If I want a logical shift gimme a logical shift. If I want an arithmetic one I'll tell you.

That consistency of thought is what made me move to Forth (allow me to consider 4tH to be Forth). I simply like languages that do what they're told to do - and do not think for themselves. For that reason I wouldn't touch Python with a poke. So when the intended effect is not what I thought it would be - it's my fault only - and not what a programmer thought my intention was.

It's still possible to write portable code in C - but it certainly has to be an early design objective. And the current direction in which GCC is moving doesn't really help - I think we can quickly agree on that. Rust is not a "savior" IMHO, because it isn't a low level language. For Pete's sake - it is more like D or Go - and we already got those.

There once was a language called C--, but that one's dead AFAIK - and never really took off. Understandable, because they went into the same area of thought that C went. Still, I very much feel the need for a REAL low level language that is designed to make system level stuff. And doesn't try to sit in my chair. Recently I browsed a presentation of an American that converted (non-standard) Forth into intermediary code, that could be fed to (I believe) a GCC backend. I'd love a thing like that. However, AFAIK it's still in an experimental stage.

My two cents..

Hans Bezemer

the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:
> > But it seems to be a complex optimizing compiler in its own world
> > and might do as many uncontrollable things under the hood as gcc.
> Well, Dennis has objected several times during the "standardization" process. What came out was certainly not what he intended it to be. IMHO he went wrong himself in several places, e.g. the operators. You cannot let the compiler decide what to do when you're stupid enough to add an integer to a float. You should simply bomb out. It's bad enough you can add an unsigned to signed. In that respect - although Forth is complete Wild West - it's behavior is much more consistent. You don't get to add a float to an integer without conversion - or you're in a world of pain.
>
> This problem is even aggravated IMHO when you add other composed datatypes - without the proper precautions, like "longs". Again, Forth is far more transparent and consistent here. You do floats with F+ (both sides need to be float), double words with D+ and single words with +. I think C would have won in consistency is that had been a prerequisite to begin with.
>
> Collating specific behavior with certain datatypes doesn't help either. Shifting right an unsigned gives you different behavior than signed. Nowadays, shifting a word by more bits than the wordsize is already "suspect". If I want a logical shift gimme a logical shift. If I want an arithmetic one I'll tell you.
>
> That consistency of thought is what made me move to Forth (allow me to consider 4tH to be Forth). I simply like languages that do what they're told to do - and do not think for themselves. For that reason I wouldn't touch Python with a poke. So when the intended effect is not what I thought it would be - it's my fault only - and not what a programmer thought my intention was.
>
> It's still possible to write portable code in C - but it certainly has to be an early design objective. And the current direction in which GCC is moving doesn't really help - I think we can quickly agree on that. Rust is not a "savior" IMHO, because it isn't a low level language. For Pete's sake - it is more like D or Go - and we already got those.
>
> There once was a language called C--, but that one's dead AFAIK - and never really took off. Understandable, because they went into the same area of thought that C went. Still, I very much feel the need for a REAL low level language that is designed to make system level stuff. And doesn't try to sit in my chair. Recently I browsed a presentation of an American that converted (non-standard) Forth into intermediary code, that could be fed to (I believe) a GCC backend. I'd love a thing like that. However, AFAIK it's still in an experimental stage.
>
> My two cents..
>
> Hans Bezemer

Another cent:
The original topic was UB in C as systems programming language.
If C is disqualified, so is C++, then remains ugly Ada.

On Wednesday, January 26, 2022 at 5:25:03 AM UTC+10, minf...@arcor.de wrote:
> the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> > On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:
> > > But it seems to be a complex optimizing compiler in its own world
> > > and might do as many uncontrollable things under the hood as gcc.
> > Well, Dennis has objected several times during the "standardization" process. What came out was certainly not what he intended it to be. IMHO he went wrong himself in several places, e.g. the operators. You cannot let the compiler decide what to do when you're stupid enough to add an integer to a float. You should simply bomb out. It's bad enough you can add an unsigned to signed. In that respect - although Forth is complete Wild West - it's behavior is much more consistent. You don't get to add a float to an integer without conversion - or you're in a world of pain.
> >
> > This problem is even aggravated IMHO when you add other composed datatypes - without the proper precautions, like "longs". Again, Forth is far more transparent and consistent here. You do floats with F+ (both sides need to be float), double words with D+ and single words with +. I think C would have won in consistency is that had been a prerequisite to begin with.
> >
> > Collating specific behavior with certain datatypes doesn't help either. Shifting right an unsigned gives you different behavior than signed. Nowadays, shifting a word by more bits than the wordsize is already "suspect". If I want a logical shift gimme a logical shift. If I want an arithmetic one I'll tell you.
> >
> > That consistency of thought is what made me move to Forth (allow me to consider 4tH to be Forth). I simply like languages that do what they're told to do - and do not think for themselves. For that reason I wouldn't touch Python with a poke. So when the intended effect is not what I thought it would be - it's my fault only - and not what a programmer thought my intention was.
> >
> > It's still possible to write portable code in C - but it certainly has to be an early design objective. And the current direction in which GCC is moving doesn't really help - I think we can quickly agree on that. Rust is not a "savior" IMHO, because it isn't a low level language. For Pete's sake - it is more like D or Go - and we already got those.
> >
> > There once was a language called C--, but that one's dead AFAIK - and never really took off. Understandable, because they went into the same area of thought that C went. Still, I very much feel the need for a REAL low level language that is designed to make system level stuff. And doesn't try to sit in my chair. Recently I browsed a presentation of an American that converted (non-standard) Forth into intermediary code, that could be fed to (I believe) a GCC backend. I'd love a thing like that. However, AFAIK it's still in an experimental stage.
> >
> > My two cents..
> >
> > Hans Bezemer
> Another cent:
> The original topic was UB in C as systems programming language.
> If C is disqualified, so is C++, then remains ugly Ada.

You mean Undefined Behaviour in C. There is a bigger issue with C that needs to be fixed, as far as OS design, with portability. Compiled JavaScript helps. .the problem is II, but I'm going spell it out so people know what it means, incomplete infrastructure in C for new OS construction use. C needed it's own high level portable virtual machine format. They are complementary.

On Wednesday, January 26, 2022 at 5:25:03 AM UTC+10, minf...@arcor.de wrote:
> the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> > On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:
> > > But it seems to be a complex optimizing compiler in its own world
> > > and might do as many uncontrollable things under the hood as gcc.
> > Well, Dennis has objected several times during the "standardization" process. What came out was certainly not what he intended it to be. IMHO he went wrong himself in several places, e.g. the operators. You cannot let the compiler decide what to do when you're stupid enough to add an integer to a float. You should simply bomb out. It's bad enough you can add an unsigned to signed. In that respect - although Forth is complete Wild West - it's behavior is much more consistent. You don't get to add a float to an integer without conversion - or you're in a world of pain.
> >
> > This problem is even aggravated IMHO when you add other composed datatypes - without the proper precautions, like "longs". Again, Forth is far more transparent and consistent here. You do floats with F+ (both sides need to be float), double words with D+ and single words with +. I think C would have won in consistency is that had been a prerequisite to begin with.
> >
> > Collating specific behavior with certain datatypes doesn't help either. Shifting right an unsigned gives you different behavior than signed. Nowadays, shifting a word by more bits than the wordsize is already "suspect". If I want a logical shift gimme a logical shift. If I want an arithmetic one I'll tell you.
> >
> > That consistency of thought is what made me move to Forth (allow me to consider 4tH to be Forth). I simply like languages that do what they're told to do - and do not think for themselves. For that reason I wouldn't touch Python with a poke. So when the intended effect is not what I thought it would be - it's my fault only - and not what a programmer thought my intention was.
> >
> > It's still possible to write portable code in C - but it certainly has to be an early design objective. And the current direction in which GCC is moving doesn't really help - I think we can quickly agree on that. Rust is not a "savior" IMHO, because it isn't a low level language. For Pete's sake - it is more like D or Go - and we already got those.
> >
> > There once was a language called C--, but that one's dead AFAIK - and never really took off. Understandable, because they went into the same area of thought that C went. Still, I very much feel the need for a REAL low level language that is designed to make system level stuff. And doesn't try to sit in my chair. Recently I browsed a presentation of an American that converted (non-standard) Forth into intermediary code, that could be fed to (I believe) a GCC backend. I'd love a thing like that. However, AFAIK it's still in an experimental stage.
> >
> > My two cents..
> >
> > Hans Bezemer
> Another cent:
> The original topic was UB in C as systems programming language.
> If C is disqualified, so is C++, then remains ugly Ada.

Rock the world. What about a forth in C compiler, where forth is implemented as a library and switch in C, where the forth code is identified and compiled using updated versions of colorforth's machine code words. Using the JavaScript API as an externally compiled library, where API's are compiled in for defined code, or as an external call to a java engine (looks messy, but things are messy when you design for compatibility). Implemented in an open source C compiler. People can do pure forth coding in C, either through the library, or as a switch forth on off, and pass variables in and out.. However, compiler time defined behaviour etc might be a challenge. But, at tjerisk of sounding like a certain person baiting, why not promote it to the C standard body as an improvement. They really need a light weight virtual machine with a near 1 to 1 ratio to machine code. The problem with previous efforts and machine code on web going to windows api, is lack of security and and controllable behaviour. Using hypervisor/sandboxing it can be secure.

The issue that people don't realise about sandboxing etc, is that if you are compiling to an embedded system, the whole system can be considered a sandbox with direct access. A sandbox also doesn't mean you don't have defined direct access to hardware, it can be set up to just deny you direct access if you don't have permission, and follow set global priority given by the user, the program, and otherwise access balancing. It dues not need to be completely deterministic, though it can be here, but it needs to be deterministic in terms of the demanded limits. In my own os design work. I had cycle based deterministic behaviour, that's like two to three decades ago. I do understand what I'm talking about and why. It will still be the same. Incompetent competing bloat. In the reasonable realtime embeddedised standard system, we should be able to virtually guarantee a maximum time period of servicing, and setup and load up the system to do that.

Now, on undefined behaviour, campaign for a defined mode in the C standard per processor target. A coexisting sub girl with switch on or off, and auto change depending on what called subroutine is used (this subroutine based auto switching can be done simply by having subroutines for each grouped into a different part of memory, do that an auto associative circuit can perform all hardware switching depending on if machine code is being performed in one part of memory or another, making this sort of switching on the next cycle. People don't understand here, or complain, but the solution is to understand. It all required thinking work.

Wayne morellini schrieb am Mittwoch, 26. Januar 2022 um 04:16:52 UTC+1:
> On Wednesday, January 26, 2022 at 5:25:03 AM UTC+10, minf...@arcor.de wrote:
> > the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> > > On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:
> > > > But it seems to be a complex optimizing compiler in its own world
> > > > and might do as many uncontrollable things under the hood as gcc.
> > > Well, Dennis has objected several times during the "standardization" process. What came out was certainly not what he intended it to be. IMHO he went wrong himself in several places, e.g. the operators. You cannot let the compiler decide what to do when you're stupid enough to add an integer to a float. You should simply bomb out. It's bad enough you can add an unsigned to signed. In that respect - although Forth is complete Wild West - it's behavior is much more consistent. You don't get to add a float to an integer without conversion - or you're in a world of pain.
> > >
> > > This problem is even aggravated IMHO when you add other composed datatypes - without the proper precautions, like "longs". Again, Forth is far more transparent and consistent here. You do floats with F+ (both sides need to be float), double words with D+ and single words with +. I think C would have won in consistency is that had been a prerequisite to begin with.
> > >
> > > Collating specific behavior with certain datatypes doesn't help either. Shifting right an unsigned gives you different behavior than signed. Nowadays, shifting a word by more bits than the wordsize is already "suspect". If I want a logical shift gimme a logical shift. If I want an arithmetic one I'll tell you.
> > >
> > > That consistency of thought is what made me move to Forth (allow me to consider 4tH to be Forth). I simply like languages that do what they're told to do - and do not think for themselves. For that reason I wouldn't touch Python with a poke. So when the intended effect is not what I thought it would be - it's my fault only - and not what a programmer thought my intention was.
> > >
> > > It's still possible to write portable code in C - but it certainly has to be an early design objective. And the current direction in which GCC is moving doesn't really help - I think we can quickly agree on that. Rust is not a "savior" IMHO, because it isn't a low level language. For Pete's sake - it is more like D or Go - and we already got those.
> > >
> > > There once was a language called C--, but that one's dead AFAIK - and never really took off. Understandable, because they went into the same area of thought that C went. Still, I very much feel the need for a REAL low level language that is designed to make system level stuff. And doesn't try to sit in my chair. Recently I browsed a presentation of an American that converted (non-standard) Forth into intermediary code, that could be fed to (I believe) a GCC backend. I'd love a thing like that. However, AFAIK it's still in an experimental stage.
> > >
> > > My two cents..
> > >
> > > Hans Bezemer
> > Another cent:
> > The original topic was UB in C as systems programming language.
> > If C is disqualified, so is C++, then remains ugly Ada.
> Rock the world. What about a forth in C compiler, where forth is implemented as a library and switch in C, where the forth code is identified and compiled using updated versions of colorforth's machine code words. Using the JavaScript API as an externally compiled library, where API's are compiled in for defined code, or as an external call to a java engine (looks messy, but things are messy when you design for compatibility). Implemented in an open source C compiler. People can do pure forth coding in C, either through the library, or as a switch forth on off, and pass variables in and out. However, compiler time defined behaviour etc might be a challenge. But, at tjerisk of sounding like a certain person baiting, why not promote it to the C standard body as an improvement. They really need a light weight virtual machine with a near 1 to 1 ratio to machine code. The problem with previous efforts and machine code on web going to windows api, is lack of security and and controllable behaviour. Using hypervisor/sandboxing it can be secure.

For instance, there is a Forth lib somewhere that lets you run a Forth interpreter
within a compiled C program. Nothing new but it also didn't hold against say Lua.

Building a VM for C and a parallel VM for Forth seems rather Frankensteinish to me.
That software model is not viable.

On Wednesday, January 26, 2022 at 6:46:59 PM UTC+10, minf...@arcor.de wrote:
> Wayne morellini schrieb am Mittwoch, 26. Januar 2022 um 04:16:52 UTC+1:
> > On Wednesday, January 26, 2022 at 5:25:03 AM UTC+10, minf...@arcor.de wrote:
> > > the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> > > > On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:

> For instance, there is a Forth lib somewhere that lets you run a Forth interpreter
> within a compiled C program. Nothing new but it also didn't hold against say Lua.
>
> Building a VM for C and a parallel VM for Forth seems rather Frankensteinish to me.
> That software model is not viable.

I see where you are going, but we are talking about two different things, and legacy compatibility between different systems. Is Frankensteinish. There is no forth VM, just forth compiled to optimised machine code, with access to other C subroutines in the program, java and the C libraries. Of course, you would keep it forth or forth using JavaScript API, for transportability between systems. That's developer self constraining, but they don't need to. There is no C VM either, just using JavaScript API for VM services, or JavaScript itself, complied to machine code, or machine code. It's flexible, you can just choose which flavour you want and stick to using that.. The thing you do develop, is support for sandboxing and hypervisor, and communications between these environments, so you can select and send file or data through the OS to another program environment. The user copies and pastes, setup events or allows limited communications, to preserve security.

So,

- C upgrades with switch to and from deterministic mode for embedded and is developers.

- Sandbox and hypervisor support and communications support.

- machine code support as mentioned previously

- JavaScript VM (API) support service, to provide code portability service across new OS's. Allowing easy programming of one version of a program, compatible with all new and old systems. This also allows anybody to make a new OS without commercial custom program.library, to immediately run that library, while custom commercial programs are being developed.

- Forth code switch on and off, using any api and allowed access to the system hardware. Allows support of a simpler model of next generation hardware. Leading to misc on cisc, and eventually misc. Bit, bssuclu, gives a lot of forth programmers C like development tools.

- Potentially JavaScript, but compiled to machine code.

- Ability to develop all low performance applicatins using JavaScript API. Ability, to add sections of C, forth, and or machine code, of higher performance is needed, requiring only customisation of those sections to transport code to new machines.

Very simple. Structured.

The issues it solves are:

- C drift to non deterministic behaviour.

- C modern security issues.

- further determinatistic behaviour through choice of structured machine code, based on processor loaded into or compiled

- A reduced complexity embedded mode, mini-F. That presents another type of processimg architecture support that can be plementef in stand alone chips.

- JavaScript API services for cross compatibility of code between different OS's, also supporting new novel OS's.

- A way to break down code performance, to reduce the amount of code needing to be adjusted.

Wayne morellini schrieb am Freitag, 28. Januar 2022 um 15:07:41 UTC+1:
> On Wednesday, January 26, 2022 at 6:46:59 PM UTC+10, minf...@arcor.de wrote:
> > Wayne morellini schrieb am Mittwoch, 26. Januar 2022 um 04:16:52 UTC+1:
> > > On Wednesday, January 26, 2022 at 5:25:03 AM UTC+10, minf...@arcor.de wrote:
> > > > the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> > > > > On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor.de wrote:
>
> > For instance, there is a Forth lib somewhere that lets you run a Forth interpreter
> > within a compiled C program. Nothing new but it also didn't hold against say Lua.
> >
> > Building a VM for C and a parallel VM for Forth seems rather Frankensteinish to me.
> > That software model is not viable.
> I see where you are going, but we are talking about two different things, and legacy compatibility between different systems. Is Frankensteinish. There is no forth VM, just forth compiled to optimised machine code, with access to other C subroutines in the program, java and the C libraries. Of course, you would keep it forth or forth using JavaScript API, for transportability between systems. That's developer self constraining, but they don't need to. There is no C VM either, just using JavaScript API for VM services, or JavaScript itself, complied to machine code, or machine code. It's flexible, you can just choose which flavour you want and stick to using that. The thing you do develop, is support for sandboxing and hypervisor, and communications between these environments, so you can select and send file or data through the OS to another program environment. The user copies and pastes, setup events or allows limited communications, to preserve security.
>
> So,
>
> - C upgrades with switch to and from deterministic mode for embedded and is developers.
>
> - Sandbox and hypervisor support and communications support.
>
> - machine code support as mentioned previously
>
> - JavaScript VM (API) support service, to provide code portability service across new OS's. Allowing easy programming of one version of a program, compatible with all new and old systems. This also allows anybody to make a new OS without commercial custom program.library, to immediately run that library, while custom commercial programs are being developed.
>
> - Forth code switch on and off, using any api and allowed access to the system hardware. Allows support of a simpler model of next generation hardware. Leading to misc on cisc, and eventually misc. Bit, bssuclu, gives a lot of forth programmers C like development tools.
>
> - Potentially JavaScript, but compiled to machine code.
>
> - Ability to develop all low performance applicatins using JavaScript API.. Ability, to add sections of C, forth, and or machine code, of higher performance is needed, requiring only customisation of those sections to transport code to new machines.
>
> Very simple. Structured.
>
>
> The issues it solves are:
>
> - C drift to non deterministic behaviour.
>
> - C modern security issues.
>
> - further determinatistic behaviour through choice of structured machine code, based on processor loaded into or compiled
>
> - A reduced complexity embedded mode, mini-F. That presents another type of processimg architecture support that can be plementef in stand alone chips.
>
> - JavaScript API services for cross compatibility of code between different OS's, also supporting new novel OS's.
>
> - A way to break down code performance, to reduce the amount of code needing to be adjusted.

Then you might be interested in:
https://bellard.org/quickjs/

On Saturday, January 29, 2022 at 2:36:33 AM UTC+10, minf...@arcor.de wrote:
> Wayne morellini schrieb am Freitag, 28. Januar 2022 um 15:07:41 UTC+1:
> > On Wednesday, January 26, 2022 at 6:46:59 PM UTC+10, minf...@arcor.de wrote:
> > > Wayne morellini schrieb am Mittwoch, 26. Januar 2022 um 04:16:52 UTC+1:
> > > > On Wednesday, January 26, 2022 at 5:25:03 AM UTC+10, minf...@arcor.de wrote:
> > > > > the.bee...@gmail.com schrieb am Dienstag, 25. Januar 2022 um 15:27:12 UTC+1:
> > > > > > On Tuesday, January 25, 2022 at 9:51:22 AM UTC+1, minf...@arcor..de wrote:
> >
> > > For instance, there is a Forth lib somewhere that lets you run a Forth interpreter
> > > within a compiled C program. Nothing new but it also didn't hold against say Lua.
> > >
> > > Building a VM for C and a parallel VM for Forth seems rather Frankensteinish to me.
> > > That software model is not viable.
> > I see where you are going, but we are talking about two different things, and legacy compatibility between different systems. Is Frankensteinish. There is no forth VM, just forth compiled to optimised machine code, with access to other C subroutines in the program, java and the C libraries. Of course, you would keep it forth or forth using JavaScript API, for transportability between systems. That's developer self constraining, but they don't need to. There is no C VM either, just using JavaScript API for VM services, or JavaScript itself, complied to machine code, or machine code. It's flexible, you can just choose which flavour you want and stick to using that. The thing you do develop, is support for sandboxing and hypervisor, and communications between these environments, so you can select and send file or data through the OS to another program environment. The user copies and pastes, setup events or allows limited communications, to preserve security.
> >
> > So,
> >
> > - C upgrades with switch to and from deterministic mode for embedded and is developers.
> >
> > - Sandbox and hypervisor support and communications support.
> >
> > - machine code support as mentioned previously
> >
> > - JavaScript VM (API) support service, to provide code portability service across new OS's. Allowing easy programming of one version of a program, compatible with all new and old systems. This also allows anybody to make a new OS without commercial custom program.library, to immediately run that library, while custom commercial programs are being developed.
> >
> > - Forth code switch on and off, using any api and allowed access to the system hardware. Allows support of a simpler model of next generation hardware. Leading to misc on cisc, and eventually misc. Bit, bssuclu, gives a lot of forth programmers C like development tools.
> >
> > - Potentially JavaScript, but compiled to machine code.
> >
> > - Ability to develop all low performance applicatins using JavaScript API. Ability, to add sections of C, forth, and or machine code, of higher performance is needed, requiring only customisation of those sections to transport code to new machines.
> >
> > Very simple. Structured.
> >
> >
> > The issues it solves are:
> >
> > - C drift to non deterministic behaviour.
> >
> > - C modern security issues.
> >
> > - further determinatistic behaviour through choice of structured machine code, based on processor loaded into or compiled
> >
> > - A reduced complexity embedded mode, mini-F. That presents another type of processimg architecture support that can be plementef in stand alone chips.
> >
> > - JavaScript API services for cross compatibility of code between different OS's, also supporting new novel OS's.
> >
> > - A way to break down code performance, to reduce the amount of code needing to be adjusted.
> Then you might be interested in:
> https://bellard.org/quickjs/

Thanks.