High level language for writing Forth

[Cecil Bayona]

I been working on a project using C to create a small Forth VM similar
to eForth, I have been making progress and soon it will be time to use
that Forth VM as the core of a complete Forth system. Since the core
it's written in C and the rest in Forth it should be easy to transport
to various CPUs.

As a side project I bought some books on Go a system programming
language and have it setup on my development PC, so I was thinking that
once the Forth VM in C is tested and working to rewrite the whole thing
in Go as a Go learning exercise.

I was going to write the whole thing in C++ and even bought a few books
on C++, about $150 worth but then I rediscovered why I disliked C++ in
the first place so many years ago so that proved a waste of money. That
is why I started looking at Go so I could have a more modern language to
use in writing system software, it has limited Object programming but
unlike C++ which I dislike.

Go is not available for embedded processors other that ARM but it don't
see that as a major problem, it is available for all the major OSes like
Windows. OS X, and a multitude of Linux and other similar OSes like BSD.

I want to learn Go for other uses so the possibility to use something
else besides Go to write this software such as Forth compilers is a
possibility. Other options are enhanced Forth like languages such as
8th, or oForth. Since Go is somewhat similar to C it's not a stretch to
rewrite working C code in it.

So, does anyone in the group have experience with Go in writing a Forth
compiler or other major software or know of links to someone else's work
on using Go in writing compilers?

Thanks in advance.

--
Cecil - k5nwa

[Rudy Velthuis]

Cecil Bayona wrote:

> So, does anyone in the group have experience with Go in writing a
> Forth compiler or other major software or know of links to someone
> else's work on using Go in writing compilers?
>
> Thanks in advance.

I assume that most Forths are either built with a core of assembler and
the rest in Forth itself, or with a core of C and the rest in Forth
itself. Those with an assembler core might even use Forth to assemble
that core.

But there is no reason that it could not be built in Golang, or Python
or Javascript (ECMAScript), or whatever.

--
Rudy Velthuis http://www.rvelthuis.de

Wilcox's Law: A pat on the back is only a few centimeters from a
kick in the pants.

[Elizabeth D. Rather]

On 4/19/17 2:24 PM, Rudy Velthuis wrote:
> Cecil Bayona wrote:
>
>> So, does anyone in the group have experience with Go in writing a
>> Forth compiler or other major software or know of links to someone
>> else's work on using Go in writing compilers?
>>
>> Thanks in advance.
>
> I assume that most Forths are either built with a core of assembler and
> the rest in Forth itself, or with a core of C and the rest in Forth
> itself. Those with an assembler core might even use Forth to assemble
> that core.

Since its founding in 1973, FORTH, Inc. has only had Forths written in
Forth (that is, with an assembler for the target processor written in
Forth and used to construct primitives). When writing the assembler for
a new target processor, we can optimize the use of registers and other
resources, a freedom you don't get using another high-level language, so
the result is a great deal more efficient.

> But there is no reason that it could not be built in Golang, or Python
> or Javascript (ECMAScript), or whatever.

Yes, but there are a lot of Forth features that are actually easier to
program in assembler than in other HLLs. We often see here people
posting tortuous C versions of things that take only two or three
instructions. And the results are always a lot slower.

Cheers,
Elizabeth

--
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

[Cecil Bayona]

On 4/19/2017 7:24 PM, Rudy Velthuis wrote:
> Cecil Bayona wrote:
>
>> So, does anyone in the group have experience with Go in writing a
>> Forth compiler or other major software or know of links to someone
>> else's work on using Go in writing compilers?
>>
>> Thanks in advance.
>
> I assume that most Forths are either built with a core of assembler and
> the rest in Forth itself, or with a core of C and the rest in Forth
> itself. Those with an assembler core might even use Forth to assemble
> that core.
>
> But there is no reason that it could not be built in Golang, or Python
> or Javascript (ECMAScript), or whatever.
>

Other than efficiency, Forth in Python would be very slow. Even for my
taste C is too inefficient but I been using C because it's available for
every CPU known to man for the most part.

Using Go I would take a different tack to the problem, I would make a
Window/Linux cross compiler that is tethered to the target so for every
CPU a very small C program could be loaded that talks to the
Windows/Linux CPU to load software.

I'm more worried about major flaws in the Language and it's current
implementation as it is a relatively new language.

--
Cecil - k5nwa

[Cecil Bayona]

There are a couple of reasons for this exercise, one would be to create
an easily portable Forth that could easily be moved to other CPUs, that
rules out Assembler.

Only the Forth VM is written is C or Go or something else, the bulk
would be written in Forth itself to also make it easy to move to another
CPU. A third reason is to end up with a system that is simple to
understand, I own copies of both SwiftForth and MPE professional
compilers and they are horribly complicated, a lot more so when compared
to software like eForth, I want to keep the whole thing simple like eForth.

The whole thing will not be as efficient as I would like but I like to
play a lot with FPGAs and with a CPU of my own creation there would be
basically no tools available so the software I use to deal with custom
CPUs would need to be basically simple to change. This is the driving
force behind this project.

Forth would be a choice way up on the list of possibilities as writing
an assembler is pretty easy in Forth and so would a lot of other
features. It would need to be a Forth that generates stand alone code,
but there are plenty of those.

The main reason to try Go would be to become more familiar with the
language, it also has a lot of features frowned up by the Forth
community so there are few decent libraries available like there would
be for Go.

--
Cecil - k5nwa

[Elizabeth D. Rather]

The think is, only a very small number of words need to be written in
Assembler. Most of the VM is high-level Forth. We are supporting SwiftX
for a dozen or so different target processors, and only a few files are
customized to the specific target. Others who have supported C-based
Forths have told me that their portability is hampered by the
differences between C compilers, so there's no magic bullet here.

Yes, I know SwiftForth is horrendously complicated, but that is
overwhelmingly due to the complexities of dealing with Windows.
polyFORTH had a lot of libraries and add-ons, but its VM was extremely
simple, and we ported it to a number of processors.

> The whole thing will not be as efficient as I would like but I like to
> play a lot with FPGAs and with a CPU of my own creation there would be
> basically no tools available so the software I use to deal with custom
> CPUs would need to be basically simple to change. This is the driving
> force behind this project.

Yes, I agree that keeping the CPU-dependent software to a minimum is the
way to go. We just achieve that by following a different path.

[Paul Rubin]

> That is why I started looking at Go so I could have a more modern
> language to use in writing system software,

Go is something like a cleaned up and safer version of C. I wouldn't
call it modern. It's fun to use if you like C, and the compiler is
amazingly fast, which is nice. But I'd still consider it a low level
language.

> Since Go is somewhat similar to C it's not a stretch to rewrite
> working C code in it.

Yes, it should be pretty straightforward if the C program doesn't do too
much pointer and casting madness.

> So, does anyone in the group have experience with Go in writing a
> Forth compiler or other major software or know of links to someone
> else's work on using Go in writing compilers?

I think the more recent Go compilers are themselves written in Go. It
would certainly be easier than writing one in C. It doesn't seem that
Forthy to use it to implement Forth though.

I don't remember if you've given Python a try. You might like it better
than Go.

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> Only the Forth VM is written is C or Go or something else, the bulk
> would be written in Forth itself to also make it easy to move to
> another CPU.

You might look at Retroforth: http://retroforth.org/docs/
It's written in about the way you describe.

[Cecil Bayona]

It allowed them to simplify their code after moving away from C, a big
enhancement of Go is handling multi-processes, cores, and CPUs which C
does not have a simple solution but Go has it built into the language.

>
> I don't remember if you've given Python a try. You might like it better
> than Go.
>

I'm familiar with Python enough to be dangerous and it is easy to learn,
has quite a few useful libraries so it's very useful for a lot of
applications, that being said it's also slow and to write a Forth VM in
it would make the Forth compiler way too slow.

Go does have pointers and casting but it's more secure for example you
cannot do pointer arithmetic in Go and casting must be explicit but it's
available. A handy thing of C but not available in Go is Unions. I will
need to read more on pointers as they will be used in the VM so I need
to see if that is a show stopper, if it is I will continue using C. In
any case I will still want to learn Go as I will use it in many other
projects, and I rather use it versus C++.

I bought a Hobby copy of 8th and was hoping to use it as a general
overall tool to write software for use with my PCs, it has a lot of nice
libraries, and data types but it doesn't have support for MySQL which
kind of important to me in writing tools to deal with my websites, I
originally thought it was to be included, but after the purchase I found
it didn't have the capability, instead it has support for SQLlite which
won't work for my web applications, I would need to spend an extra $250
to buy a Pro Version which I can't afford at this point. Otherwise it
would have been the choice general language for quickly generating
applications.

Go has full support for MySQL, Network Services, Windowing systems, and
other tools built into the system libraries so that is part of the
reason to consider it as my main language for use with Windows/Linux
applications.
--
Cecil - k5nwa

[Cecil Bayona]

I have looked at RetroForth in the past with it's NGaro Virtual machine
but it was kind of complex to setup the tools and work with it. I'm
trying to simplify the whole process and use tools that are simple to setup.

--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> It allowed them to simplify their code after moving away from C, a big
> enhancement of Go is handling multi-processes, cores, and CPUs which
> C does not have a simple solution but Go has it built into the
> language.

Goroutines are basically coroutines or lightweight threads: maybe I'm
mistaken but I don't think they get dispatched to other cores. There
are libraries for C that can do stuff like that, though Go makes it
easier.

> Python ... to write a Forth VM in it would make the Forth compiler
> way too slow.

I thought the idea was to write the VM (a simple program, look at the
manu implementations of the Retroforth Ngaro VM) in a low level language
like C, but you wanted to use something higher level to write the
compiler. Anyway, even in Python I bet the Forth VM would run much
faster on a modern PC than carefully tuned native Forth compilers did on
1980s computers.

> I will still want to learn Go as I will use it in many other projects,

Fair enough.

> I bought a Hobby copy of 8th... it doesn't have support for MySQL

Hmm, maybe you could connect it up to an external MySQL client or
library.

[Ron Aaron]

On 04/20/17 07:22, Cecil Bayona wrote:
> I bought a Hobby copy of 8th and was hoping to use it as a general
> overall tool to write software for use with my PCs, it has a lot of nice
> libraries, and data types but it doesn't have support for MySQL

The Hobbyist version doesn't natively support MySQL; the Professional
version does. You can still interface with MySQL in the Hobbyist
edition, either using the FFI or by execing the 'mysql' command-line
application.

[Melzzzzz]

On 2017-04-20, Paul Rubin <no.e...@nospam.invalid> wrote:
> Cecil Bayona <cba...@cbayona.com> writes:
>> It allowed them to simplify their code after moving away from C, a big
>> enhancement of Go is handling multi-processes, cores, and CPUs which
>> C does not have a simple solution but Go has it built into the
>> language.
>
> Goroutines are basically coroutines or lightweight threads: maybe I'm
> mistaken but I don't think they get dispatched to other cores.

They are dispatched alright. You control that with GOMAXPROCS function.

[Lars Brinkhoff]

Cecil Bayona wrote:
> So, does anyone in the group have experience with Go in writing a
> Forth compiler or other major software or know of links to someone
> else's work on using Go in writing compilers?

I don't have any experience with Go. But my own Forth uses an unholy
mix of Lisp, C, Forth, assembly language, and now has added some asm.js
JavaScript as well.

[Cecil Bayona]

On 4/19/2017 11:35 PM, Paul Rubin wrote:

> I thought the idea was to write the VM (a simple program, look at the
> manu implementations of the Retroforth Ngaro VM) in a low level language
> like C, but you wanted to use something higher level to write the
> compiler. Anyway, even in Python I bet the Forth VM would run much
> faster on a modern PC than carefully tuned native Forth compilers did on
> 1980s computers.
>
>> I will still want to learn Go as I will use it in many other projects,
>
> Fair enough.
>
>> I bought a Hobby copy of 8th... it doesn't have support for MySQL
>
> Hmm, maybe you could connect it up to an external MySQL client or
> library.
>

Do you have a MySQL implementation for 8th or for something else that
could be adapted?

The VM implements anywhere for 60 to 100 primitives, the code to run
words from the dictionary, do I/O, and handle the stacks, the rest is
implemented in Forth Word tokens that the VM can execute.

The instructions of the VM are one byte tokens that are executed by the
VM core. Several hundred words are added for the VM to execute that
create a compile/interpreter/assembler.

The system will vary depending on what language I use and it will
determine if the target system is a complete Forth on board or just a
tethered system that gets its running code from the PC host. It could be
done in several different ways. For some targets that are used often the
the target VM could be written in assembler for speed after a while.

What I'm currently using is a special version of eForth, it creates a
target image with a meta-compiler, and it works quite well, it allows
for eForth to be resident on the target CPU, there is really not much
wrong with it but I want to write my own from scratch as a learning
exercise.

Tomorrow evening I will do some research and some simple test programs
with Go and pointers, and arrays that will determine which way to
proceed from here.


--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> Do you have a MySQL implementation for 8th or for something else that
> could be adapted?

I don't, but as Ron says, you could use the FFI or connect to the mysql
command line tool.

> The VM implements anywhere for 60 to 100 primitives, the code to run
> words from the dictionary, do I/O, and handle the stacks, the rest is
> implemented in Forth Word tokens that the VM can execute.

That seems like a lot of instructions, but ok. I'd expect the VM to
just be a bytecode counterpart to a classic ITC address interpreter. It
shouldn't know anything about the dictionary layout. It does have to do
some i/o. Do you know about the C port of eForth?

http://chiselapp.com/user/tehologist/repository/compc/home

> determine if the target system is a complete Forth on board or just a
> tethered system that gets its running code from the PC host.

If you're thinking of MCU targets you better not write the VM in Go.
The Go runtime is intended for bigger machines, needs a megabyte or so
of ram, has a garbage collector, etc.

[Ilya Tarasov]

четверг, 20 апреля 2017 г., 2:32:45 UTC+3 пользователь Cecil - k5nwa написал:

> I been working on a project using C to create a small Forth VM similar
> to eForth, I have been making progress and soon it will be time to use
> that Forth VM as the core of a complete Forth system. Since the core
> it's written in C and the rest in Forth it should be easy to transport
> to various CPUs.

From our experience, Assembler, Forth, Delphi, C, C++, C# may be used with less or more efforts, depending on skill and goals. I know about Java and Python versions, but have no such translators in portfolio. C-based languages provide more easy way, and may contain assembler or dll calls for higher performance in critical parts. Stack manipulations are worse candidates to be rewritten, because total performance often depends on things like graphics or system calls.

[Rudy Velthuis]

Elizabeth D. Rather wrote:

> > I assume that most Forths are either built with a core of assembler
> > and the rest in Forth itself, or with a core of C and the rest in
> > Forth itself. Those with an assembler core might even use Forth to
> > assemble that core.
>
> Since its founding in 1973, FORTH, Inc. has only had Forths written
> in Forth (that is, with an assembler for the target processor written
> in Forth and used to construct primitives).

So an assembler core and the rest in Forth.

--
Rudy Velthuis http://www.rvelthuis.de

"There are people in the world so hungry, that God cannot appear
to them except in the form of bread."
-- Mahatma Gandhi (1869-1948)

[Albert van der Horst]

In article <87efwne...@nightsong.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>> That is why I started looking at Go so I could have a more modern
>> language to use in writing system software,
>
>Go is something like a cleaned up and safer version of C. I wouldn't
>call it modern. It's fun to use if you like C, and the compiler is
>amazingly fast, which is nice. But I'd still consider it a low level
>language.

Another view is that it is a slightly inferior incarnation of Algol68.

http://cowlark.com/2009-11-15-go/

This is a seminal article cited all over the place.
The article itself is extremely hard to find.
I knew it existed.
I hadn't any success until I searched for the exact author and the
exact title:
cowlark "Go and brand x"
(Does google want to hide it?)

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Elizabeth D. Rather]

On 4/20/17 7:02 AM, Rudy Velthuis wrote:
> Elizabeth D. Rather wrote:
>
>>> I assume that most Forths are either built with a core of assembler
>>> and the rest in Forth itself, or with a core of C and the rest in
>>> Forth itself. Those with an assembler core might even use Forth to
>>> assemble that core.
>>
>> Since its founding in 1973, FORTH, Inc. has only had Forths written
>> in Forth (that is, with an assembler for the target processor written
>> in Forth and used to construct primitives).
>
> So an assembler core and the rest in Forth.

It's not organized that way. There are a couple of files of assembler
primitives (using the Forth assembler) and a lot more files of
high-level Forth words using them. Most of the core is high level. It's
really all Forth, including some Forth words that assemble machine
instructions.

[Cecil Bayona]

On 4/20/2017 12:47 PM, Albert van der Horst wrote:
> In article <87efwne...@nightsong.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
>>> That is why I started looking at Go so I could have a more modern
>>> language to use in writing system software,
>>
>> Go is something like a cleaned up and safer version of C. I wouldn't
>> call it modern. It's fun to use if you like C, and the compiler is
>> amazingly fast, which is nice. But I'd still consider it a low level
>> language.
>
> Another view is that it is a slightly inferior incarnation of Algol68.
>
> http://cowlark.com/2009-11-15-go/
>
> This is a seminal article cited all over the place.
> The article itself is extremely hard to find.
> I knew it existed.
> I hadn't any success until I searched for the exact author and the
> exact title:
> cowlark "Go and brand x"
> (Does google want to hide it?)
>
> Groetjes Albert
>

Interesting article but a few things stand out, he compared Go right
after it came out so he was probably not familiar with the language. He
proved that to be so when he compared the language with sample routines,
the routines were not correct, even I as a rank beginner with a few
hours reading on go could see his sample were not correct. Most likely
then he was not very familiar with the language.

--
Cecil - k5nwa

[Rudy Velthuis]

Elizabeth D. Rather wrote:

> On 4/20/17 7:02 AM, Rudy Velthuis wrote:
> > Elizabeth D. Rather wrote:
> >
> > > > I assume that most Forths are either built with a core of
> > > > assembler and the rest in Forth itself, or with a core of C and
> > > > the rest in Forth itself. Those with an assembler core might
> > > > even use Forth to assemble that core.
> > >
> > > Since its founding in 1973, FORTH, Inc. has only had Forths
> > > written in Forth (that is, with an assembler for the target
> > > processor written in Forth and used to construct primitives).
> >
> > So an assembler core and the rest in Forth.
>
> It's not organized that way. There are a couple of files of assembler
> primitives (using the Forth assembler) and a lot more files of
> high-level Forth words using them. Most of the core is high level.

But it is still an assembler core with the rest in Forth. What you
consider "core" may be different. Fact is that there is "a core" of
assembler words on which the rest builds.

--
Rudy Velthuis http://www.rvelthuis.de

"I feel so miserable without you; it's almost like having
you here." -- Stephen Bishop

[Andrew Haley]

Rudy Velthuis <newsg...@rvelthuis.de> wrote:
> Elizabeth D. Rather wrote:
>
>> On 4/20/17 7:02 AM, Rudy Velthuis wrote:
>> >
>> > So an assembler core and the rest in Forth.
>>
>> It's not organized that way. There are a couple of files of assembler
>> primitives (using the Forth assembler) and a lot more files of
>> high-level Forth words using them. Most of the core is high level.
>
> But it is still an assembler core with the rest in Forth. What you
> consider "core" may be different. Fact is that there is "a core" of
> assembler words on which the rest builds.

It's never felt that way to me. Code written in Forth's assembler is
still Forth: it's low-level Forth, or something. Forth's assembly
language, with its integration with the high-level language and macros
etc isn't plain old assembly. So I think it's fair to say "It's all
Forth", just as a C compiler written in C bootstraps itself.

Andrew.

[Alex]

Especially when you can write code like this.

code dup3+
] dup [
add eax 3
next; ok
10 dup3+ .s [2] 10 13 ok[2]

--
Alex

[Andrew Haley]

Alex <al...@rivadpm.com> wrote:
> On 4/21/2017 15:07, Andrew Haley wrote:
>>
>> Code written in Forth's assembler is
>> still Forth: it's low-level Forth, or something. Forth's assembly
>> language, with its integration with the high-level language and macros
>> etc isn't plain old assembly. So I think it's fair to say "It's all
>> Forth", just as a C compiler written in C bootstraps itself.
>

> Especially when you can write code like this.
>
> code dup3+
> ] dup [
> add eax 3
> next; ok
> 10 dup3+ .s [2] 10 13 ok[2]

Yeah, exactly! It's even portable!

SwiftForth i386-Linux 3.6.4 21-Mar-2017
code dup3+ ok
] dup [ 3 # ebx add ret end-code ok
10 dup3+ .s
10 13 <-Top ok

What's not to like? ;-)

Andrew.

[Alex]

On 4/21/2017 17:17, Andrew Haley wrote:

>
> Yeah, exactly! It's even portable!
>

It's the principle that's portable. If you don't like them, I have
others. :)

--
Alex

[Rudy Velthuis]

Andrew Haley wrote:

> > But it is still an assembler core with the rest in Forth. What you
> > consider "core" may be different. Fact is that there is "a core" of
> > assembler words on which the rest builds.
>
> It's never felt that way to me. Code written in Forth's assembler is
> still Forth: it's low-level Forth

Assembler is assembler, no matter how you look at it, and it doesn't
matter if that assembler was written in Forth or any other way.

--
Rudy Velthuis http://www.rvelthuis.de

"You will kill ten of our men, and we will kill one of yours,
and in the end it will be you who tire of it."
-- Ho Chi Minh

[Rudy Velthuis]

So you can inline the assembly. That's fine. It is still (x-86, in this
case) assembly. <shrug>

--
Rudy Velthuis http://www.rvelthuis.de

Hind's Law of Computer Programming:

1. Any given program, when running, is obsolete.
2. If a program is useful, it will have to be changed.
3. If a program is useless, it will have to be documented.
4. Any given program will expand to fill all available memory.
5. The value of a program is proportional to the weight of its
output.
6. Program complexity grows until it exceeds the capability of
the programmer who must maintain it.
7. Make it possible for programmers to write programs in
English, and you will find that programmers cannot write in
English.

[Rudy Velthuis]

Andrew Haley wrote:

> Alex <al...@rivadpm.com> wrote:
> > On 4/21/2017 15:07, Andrew Haley wrote:
> >>
> >> Code written in Forth's assembler is
> >> still Forth: it's low-level Forth, or something. Forth's assembly
> >> language, with its integration with the high-level language and
> macros >> etc isn't plain old assembly. So I think it's fair to say
> "It's all >> Forth", just as a C compiler written in C bootstraps
> itself.
> >
> > Especially when you can write code like this.
> >
> > code dup3+
> > ] dup [
> > add eax 3
> > next; ok
> > 10 dup3+ .s [2] 10 13 ok[2]
>
> Yeah, exactly! It's even portable!

Not really. It is only portable to other 32 bit x-86 systems, and it
stops being portable as soon as you must use system calls (or APIs),
e.g. to manipulate files, directories, to do graphics, etc., which is
inevitable at some point in time.

--
Rudy Velthuis http://www.rvelthuis.de

"If a scholar aspires to the Way but is ashamed of bad clothes
and bad food, he isn't ready to join the discussion yet."
-- Confucius

[Andrew Haley]

Rudy Velthuis <newsg...@rvelthuis.de> wrote:
> Andrew Haley wrote:
>
>> Alex <al...@rivadpm.com> wrote:
>> > On 4/21/2017 15:07, Andrew Haley wrote:
>> >>
>> >> Code written in Forth's assembler is
>> >> still Forth: it's low-level Forth, or something. Forth's assembly
>> >> language, with its integration with the high-level language and
>> macros >> etc isn't plain old assembly. So I think it's fair to say
>> "It's all >> Forth", just as a C compiler written in C bootstraps
>> itself.
>> >
>> > Especially when you can write code like this.
>> >
>> > code dup3+
>> > ] dup [
>> > add eax 3
>> > next; ok
>> > 10 dup3+ .s [2] 10 13 ok[2]
>>
>> Yeah, exactly! It's even portable!
>
> Not really. It is only portable to other 32 bit x-86 systems, and it
> stops being portable as soon as you must use system calls (or APIs),
> e.g. to manipulate files, directories, to do graphics, etc., which is
> inevitable at some point in time.

You have had your sense of humour amputated.

Andrew.

[Rudy Velthuis]

I sometimes put it aside, e.g. when I am being serious.

This was humour, really? Oh, OK: Ha! Ha! Ha!

--
Rudy Velthuis http://www.rvelthuis.de

"To love oneself is the beginning of a lifelong romance"
-- Oscar Wilde (1854-1900)

[Alex]

It's the other way round. The assembler is inlining Forth.

Actually, it's all Forth. Or assembler. Or even Forth assembler with
Forth. Who knows?

also assembler
code adup3+ ] dup [ add eax 3 next;
: bdup3+ dup [ add eax 3 ] ;
: cdup3+ dup 3 + ;

code adup3+ ( ? -- ? )
\ adup3+ is defined in c:/w32f/v608/test1.fs at line 3
\ call compiled
\ code=$41BEDB len=9 type=129
( $0 ) mov dword { $-4 ebp } eax \ 8945FC
( $3 ) sub ebp $4 \ 83ED04
( $6 ) add eax $3 \ 83C003
( $9 ) ret \ C3 ( end )
: bdup3+ ( ? -- ? )
\ bdup3+ is defined in c:/w32f/v608/test1.fs at line 4
\ call compiled
\ code=$41BEEA len=9 type=130
( $0 ) mov dword { $-4 ebp } eax \ 8945FC
( $3 ) sub ebp $4 \ 83ED04
( $6 ) add eax $3 \ 83C003
( $9 ) ret \ C3 ( end )
: cdup3+ ( ? -- ? )
\ cdup3+ is defined in c:/w32f/v608/test1.fs at line 5
\ call compiled
\ code=$41BEF9 len=9 type=130
( $0 ) mov dword { $-4 ebp } eax \ 8945FC
( $3 ) sub ebp $4 \ 83ED04
( $6 ) add eax $3 \ 83C003
( $9 ) ret \ C3 ( end )

Identical.

--
Alex

[Alex]

On 4/21/2017 21:32, Rudy Velthuis wrote:

> Andrew Haley wrote:

>>
>> Yeah, exactly! It's even portable!
>
> Not really. It is only portable to other 32 bit x-86 systems, and it
> stops being portable as soon as you must use system calls (or APIs),
> e.g. to manipulate files, directories, to do graphics, etc., which is
> inevitable at some point in time.
>

Andrew majored in sarcasm.

--
Alex

[Elizabeth D. Rather]

On 4/21/17 10:28 AM, Rudy Velthuis wrote:
> Andrew Haley wrote:
>
>>> But it is still an assembler core with the rest in Forth. What you
>>> consider "core" may be different. Fact is that there is "a core" of
>>> assembler words on which the rest builds.
>>
>> It's never felt that way to me. Code written in Forth's assembler is
>> still Forth: it's low-level Forth
>
> Assembler is assembler, no matter how you look at it, and it doesn't
> matter if that assembler was written in Forth or any other way.
>

What we're really trying to get at is that in a "Forth written in Forth"
implementation there's no big ball of code generated by assembler and
another bigger ball of code compiled by high-level Forth. They're all
intermingled. In such a system, the word "kernel" denotes the code that
was pre-compiled and booted before more code starts being compiled from
source. That kernel was built by a cross- or metacompiler out of both
(and intermingled) assembler and high-level Forth definitions, as will
be the additional code that's compiled in the second stage of booting.
So, to say, "the kernel is written in assembler and the rest in
high-level Forth" is meaningless.

[Coos Haak]

Op Fri, 21 Apr 2017 20:28:40 +0000 (UTC) schreef Rudy Velthuis:

> Andrew Haley wrote:
>
>>> But it is still an assembler core with the rest in Forth. What you
>>> consider "core" may be different. Fact is that there is "a core" of
>>> assembler words on which the rest builds.
>>
>> It's never felt that way to me. Code written in Forth's assembler is
>> still Forth: it's low-level Forth
>
> Assembler is assembler, no matter how you look at it, and it doesn't
> matter if that assembler was written in Forth or any other way.

My Forth is completely written in Forth.
A lot of definitions are in assembly code that is
compiled (assembled) within Forth and its integrated Assembler.
No assembler like MASM TASM NASM or FASM has ever touched it.

groet Coos

[Cecil Bayona]

Go for creating a Forth VM is off the table for now, Go flunked my test
of pointers to create stacks.

You cannot use a pointer to go through an array of data by using
increment, and decrement operation on the pointer like you can in C.
Pointers in Go are basically used to pass data around without copying it
but you can't use pointer arithmetic in any fashion including increment
and decrement operators.

In C it's easy to create a stack by having a pointer to an array of
data, read the data and increment the pointer is a pop, increment the
pointer and write the data is a push. That can be very efficient as
increment or decrement of a pointer is a fast instruction. In Go I can
do it by incrementing or decrementing an index into an array but the
address calculations are not as fast, it could be close to the same but
I can't see the generated code to be able to tell one way or the other.
I can see their point of limiting pointers for safety reasons, in C one
needs to add code to check and make sure the pointers stay pointing
within the array but the same applies to using an array index, one needs
to make sure the index is valid.

So its back to using C for now and finish what I started, I'm pretty
close anyway with the C code to start testing the VM.

--
Cecil - k5nwa

[Rudy Velthuis]

Alex wrote:

> > So you can inline the assembly. That's fine. It is still (x-86, in
> > this case) assembly. <shrug>
> >
>
> It's the other way round. The assembler is inlining Forth.

Not sure if you are serious, but that is nonsense anyway. Something
that uses assembler mnemonics to generate machine code is an assembler,
no matter if it is written in Forth or not. Oh, it is a built-in (or
loadable) assembler, but these are not unique to Forth either.

--
Rudy Velthuis http://www.rvelthuis.de

"I was playing poker the other night... with Tarot cards.
I got a full house and 4 people died." -- Steven Wright

[hughag...@gmail.com]

On Friday, April 21, 2017 at 9:12:47 PM UTC-7, Cecil - k5nwa wrote:
> Go for creating a Forth VM is off the table for now, Go flunked my test
> of pointers to create stacks.
>
> You cannot use a pointer to go through an array of data by using
> increment, and decrement operation on the pointer like you can in C.
> Pointers in Go are basically used to pass data around without copying it
> but you can't use pointer arithmetic in any fashion including increment
> and decrement operators.
>
> In C it's easy to create a stack by having a pointer to an array of
> data, read the data and increment the pointer is a pop, increment the
> pointer and write the data is a push. That can be very efficient as
> increment or decrement of a pointer is a fast instruction. In Go I can
> do it by incrementing or decrementing an index into an array but the
> address calculations are not as fast, it could be close to the same but
> I can't see the generated code to be able to tell one way or the other.
> I can see their point of limiting pointers for safety reasons, in C one
> needs to add code to check and make sure the pointers stay pointing
> within the array but the same applies to using an array index, one needs
> to make sure the index is valid.

I wouldn't dismiss Go because of this --- I would expect that incrementing and decrementing an array index would be almost as fast as incrementing and decrementing a pointer --- the difference is like one or two extra instructions, but the instructions may parallelize so they don't actually take any extra time.

This is premature optimization!

Also, a Forth VM written in any high-level language is going to be significantly slower than generating machine-code with an STC Forth --- so the difference between C and Go in speed doesn't matter --- so long as you don't think that Perl (John Passaniti) or Python (Juergen Pintaske) is a good language to write a Forth VM in, you should get reasonable speed.

> So its back to using C for now and finish what I started, I'm pretty
> close anyway with the C code to start testing the VM.

C has a lot of problems of its own --- Anton Ertl complains about this continually --- I wouldn't use C.

I am learning Go right now. I hadn't considered writing a Forth VM in Go, because I think FASM is better --- I had just been thinking of Go as a practical language for writing programs --- Python is very popular, but it is also very slowwwwww, so Go may eventually replace it as the most supported language available (supported in the sense of having code-libraries).

Forth is just a weird hobby. It is soooooo dead! There are fewer than 20 ANS-Forth programmers in the world, and none of them are writing programs, but instead they spend their time on the Forth-200x mailing list pretending to be leaders. There are fewer than 200 Forth programmers in the world, but most of them are like Ilya Tarasov in that they write their own non-standard Forth system and have only a handful of users, and (unlike Ilya TArasov) they stay away from comp.lang.forth because it is annoying to be attacked by Elizabeth Rather's sycophants who call them stupid and tell lies about them.

I should learn a popular language such as Go or Python that people actually use --- nobody considers me to be a programmer right now --- my Forth experience doesn't count for anything in the real world.

[Rudy Velthuis]

Elizabeth D. Rather wrote:

> > Assembler is assembler, no matter how you look at it, and it doesn't
> > matter if that assembler was written in Forth or any other way.
> >
>
> What we're really trying to get at is that in a "Forth written in
> Forth" implementation there's no big ball of code generated by
> assembler and another bigger ball of code compiled by high-level
> Forth.

I get that. But whatever you do, there must be a (little, if you wish)
machine code core for the specific processor. That is unavoidable.

Now, I see that some Forths use C instead of assembler. That has its
advantages (much easier to implement things like allocation, file
handling, keyboard handling, output, etc.). Heck, I have even seen one
that is based on BBC Basic (which has a built-in assembler, BTW).

I orginally wanted to write one that is based on Delphi, but that would
make the executables pretty big. So now I use assembler and, well,
Forth and do all the hard stuff using my own code or the Windows API.

--
Rudy Velthuis http://www.rvelthuis.de

"Rarely is the question asked: Is our children learning?"
-- George W. Bush

[Rudy Velthuis]

The assembler is written in Forth. You can't deny it is still assembly
language. And I assume you (or someone else) had to start with
assembler or C or whatever for the very low level stuff, unless you
manually assembled the byte codes, or used another Forth to assemble
yours.

--
Rudy Velthuis http://www.rvelthuis.de

"Computer /nm./: a device designed to speed and automate errors."
-- From the Jargon File.

[Cecil Bayona]

On 4/21/2017 11:53 PM, hughag...@gmail.com wrote:
> On Friday, April 21, 2017 at 9:12:47 PM UTC-7, Cecil - k5nwa wrote:
>> Go for creating a Forth VM is off the table for now, Go flunked my test
>> of pointers to create stacks.
>>
>> You cannot use a pointer to go through an array of data by using
>> increment, and decrement operation on the pointer like you can in C.
>> Pointers in Go are basically used to pass data around without copying it
>> but you can't use pointer arithmetic in any fashion including increment
>> and decrement operators.
>>
>> In C it's easy to create a stack by having a pointer to an array of
>> data, read the data and increment the pointer is a pop, increment the
>> pointer and write the data is a push. That can be very efficient as
>> increment or decrement of a pointer is a fast instruction. In Go I can
>> do it by incrementing or decrementing an index into an array but the
>> address calculations are not as fast, it could be close to the same but
>> I can't see the generated code to be able to tell one way or the other.
>> I can see their point of limiting pointers for safety reasons, in C one
>> needs to add code to check and make sure the pointers stay pointing
>> within the array but the same applies to using an array index, one needs
>> to make sure the index is valid.
>
> I wouldn't dismiss Go because of this --- I would expect that incrementing and decrementing an array index would be almost as fast as incrementing and decrementing a pointer --- the difference is like one or two extra instructions, but the instructions may parallelize so they don't actually take any extra time.
>
> This is premature optimization!
>

That why I wish I could see the generated code, it might not make a
difference after optimization but I don't have a way of finding out
right now,

> Also, a Forth VM written in any high-level language is going to be significantly slower than generating machine-code with an STC Forth --- so the difference between C and Go in speed doesn't matter --- so long as you don't think that Perl (John Passaniti) or Python (Juergen Pintaske) is a good language to write a Forth VM in, you should get reasonable speed.
>
>> So its back to using C for now and finish what I started, I'm pretty
>> close anyway with the C code to start testing the VM.
>
> C has a lot of problems of its own --- Anton Ertl complains about this continually --- I wouldn't use C.

There are few system languages available that generate decent code,
C/C++, Pascal, Go, Oberon, and Forth, other higher level languages are
way too slow and require massive resources. I own several commercial
copies of C/C++, and some old copies of Delphi, and various Forth
Systems including Swift, and MPE VFX. C and Forth are the most viable
and maybe Go. I like Delphi I dug it out and installed it but my old
versions had problems with Windows 10 so I then started looking at Go,
C++ is not under consideration. I might try loading Delphi in a Windows
7 Virtual PC and see how that works out tomorrow. Too many choices can
be a major problem.

>
> I am learning Go right now. I hadn't considered writing a Forth VM in Go, because I think FASM is better --- I had just been thinking of Go as a practical language for writing programs --- Python is very popular, but it is also very slowwwwww, so Go may eventually replace it as the most supported language available (supported in the sense of having code-libraries).

I want to use Go for other purposes and I will but it would have been
interesting to use this a learning experience, I might still do it
anyway after I finish the C code so I have something to compare it
against. The whole purpose of this is to have it be easy to move to a
new PC without having to deal with a different assembler for each processor.

>
> Forth is just a weird hobby. It is soooooo dead! There are fewer than 20 ANS-Forth programmers in the world, and none of them are writing programs, but instead they spend their time on the Forth-200x mailing list pretending to be leaders. There are fewer than 200 Forth programmers in the world, but most of them are like Ilya Tarasov in that they write their own non-standard Forth system and have only a handful of users, and (unlike Ilya TArasov) they stay away from comp.lang.forth because it is annoying to be attacked by Elizabeth Rather's sycophants who call them stupid and tell lies about them.

You read any of the articles by Charles Moore or his discussions and he
sees Forth as a set of tools that are customized to the needs of the
hour, I don't see him nailed to a Standard, he does as he pleases to get
the job done. That is how I feel about Forth myself, it's nice to have a
standard but it better be a good one or I will ignore it. I'm ignoring
it for the most part, I can't stand all this ambiguity in it, I like
simplicity.

>
> I should learn a popular language such as Go or Python that people actually use --- nobody considers me to be a programmer right now --- my Forth experience doesn't count for anything in the real world.
>

Poor baby, not being loved. I firmly believe that the only one that can
make one happy is oneself, others can help, but most are in the way.

Python is handy for small programs that can afford to run slow, Go looks
interesting it is fast, and has nice libraries, I would learn both, I
intend to.

--
Cecil - k5nwa

[Paul Rubin]

"Rudy Velthuis" <newsg...@rvelthuis.de> writes:
> And I assume you (or someone else) had to start with assembler or C or
> whatever for the very low level stuff, unless you manually assembled
> the byte codes, or used another Forth to assemble yours.

Yes, that's the idea, you start with Forth and there's an assembler
written in Forth that's used during metacompilation, probably not at the
very beginning. The rest is Forth.

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> There are few system languages available that generate decent code,
> C/C++, Pascal, Go, Oberon, and Forth, other higher level languages are
> way too slow and require massive resources.

I can't quite parse that, but I'd put C, C++, Forth, and maybe Pascal
in the low-resource class; Go is high-resource (comparable to Python)
although it generates faster code. No idea about Oberon.

[Cecil Bayona]

For a Forth compiler on a desktop extra ram used is not a biggie being
slow is a big deal.

--
Cecil - k5nwa

[Andrew Haley]

Cecil Bayona <cba...@cbayona.com> wrote:
>
> That why I wish I could see the generated code, it might not make a
> difference after optimization but I don't have a way of finding out
> right now,

Surely you just use -S to get assembly language, like any other
compiler. I'll try it...

$ go tool compile -S hello-world.go

"".main t=1 size=170 args=0x0 locals=0x58
0x0000 00000 (hello-world.go:9) TEXT "".main(SB), $88-0
0x0000 00000 (hello-world.go:9) MOVQ (TLS), CX
0x0009 00009 (hello-world.go:9) CMPQ SP, 16(CX)
0x000d 00013 (hello-world.go:9) JLS 160
... lots more.

Yes. Just worked.

Andrew.

[Jan Coombs]

On Sat, 22 Apr 2017 04:49:19 +0000 (UTC)
"Rudy Velthuis" <newsg...@rvelthuis.de> wrote:

> Alex wrote:
>
> > It's the other way round. The assembler is inlining Forth.
>
> Not sure if you are serious, but that is nonsense anyway.
> Something that uses assembler mnemonics to generate machine
> code is an assembler, no matter if it is written in Forth or
> not. Oh, it is a built-in (or loadable) assembler, but these
> are not unique to Forth either.

I think that if you asked a number of assembler programmers to
use the simplest forth assemblers that I have used and written,
then the average response would be:

"That is _not_ [what I call] an assembler"

The rejection is because to a first approximation does not
support the working environment that they quite reasonably
expect.

However, the Forth assembler extension can be used to
interactively develop fragments of machine code by using the rest
of a Forth system as support tools.

Jan Coombs
--

[Mark Wills]

They may object, but after an hour of coding without having to use a
single label anywhere in their code, they normally come around, just
as I did :-)

[Andrew Haley]

Mark Wills <markwi...@gmail.com> wrote:

> They may object, but after an hour of coding without having to use a
> single label anywhere in their code, they normally come around, just
> as I did :-)

Indeed so. It's still baffling to me that assembly programs usually
don't use structured programming constructs such as loops and if
statements. It seems to me that they're just as useful in assembly-
language programs as in high-level languages.

Andrew.

[lehs]

I which there were some pseudo machine code language, not optimized to build up Forth, but optimized to be easy to be built up itselves from most machine codes in use. Of course such an intermediate stage would be less than optimal, but maybe more efficient than c and go.

Then even I would try to learn that language and try to built up a Lehs-Forth.

[Alex]

> .... lots more.
>
> Yes. Just worked.
>
> Andrew.
>

Aha! It's an assembler.

--
Alex

[Alex]

On 4/22/2017 05:49, Rudy Velthuis wrote:
> Alex wrote:
>
>>> So you can inline the assembly. That's fine. It is still (x-86, in
>>> this case) assembly. <shrug>
>>>
>>
>> It's the other way round. The assembler is inlining Forth.
>
> Not sure if you are serious, but that is nonsense anyway. Something
> that uses assembler mnemonics to generate machine code is an assembler,
> no matter if it is written in Forth or not. Oh, it is a built-in (or
> loadable) assembler, but these are not unique to Forth either.
>

It's turtles all the way down. Or up, depending where you are.

Yes, I was serious. Semantic arguments about where the assembler ends
and where Forth starts are pretty pointless, because everyone has their
own opinion. What is true is that languages are the end product of
bootstrapping from some other language. In the case of a lot of Forths,
bootstrapped from Forths with Forthish assemblers written in Forth.

--
Alex

[Mark Wills]

Absolutely. In my case I didn't realise just *how* useful there were
in assembly until I started using them in my own Forth TMS9900 assembler.

[Mark Wills]

I think the thing you just wished for is... Forth. That's what it is!

[lehs]

If so, then Forth would be the perfect platform for building an operating system.

[Ilya Tarasov]

суббота, 22 апреля 2017 г., 7:53:32 UTC+3 пользователь hughag...@gmail.com написал:

>
> Also, a Forth VM written in any high-level language is going to be significantly slower than generating machine-code with an STC Forth --- so the difference between C and Go in speed doesn't matter --- so long as you don't think that Perl (John Passaniti) or Python (Juergen Pintaske) is a good language to write a Forth VM in, you should get reasonable speed.

Perl and Python are scripting languages (as well as Ruby, Lua and Tcl). Forth has strong positions in scripting, so writing Forth on assembler will give us scripting language with pretty fast code, and writing Forth on C/C++/C# etc will give us scripting language embedded in more complex software project.

> I am learning Go right now. I hadn't considered writing a Forth VM in Go, because I think FASM is better --- I had just been thinking of Go as a practical language for writing programs --- Python is very popular, but it is also very slowwwwww, so Go may eventually replace it as the most supported language available (supported in the sense of having code-libraries).

I don't work with Go so far, but I see it may be a base like C* languages. I.e. if you need more scripting features in your Go project, Forth is one of the best solution.

> Forth is just a weird hobby. It is soooooo dead! There are fewer than 20 ANS-Forth programmers in the world, and none of them are writing programs, but instead they spend their time on the Forth-200x mailing list pretending to be leaders. There are fewer than 200 Forth programmers in the world, but most of them are like Ilya Tarasov in that they write their own non-standard Forth system and have only a handful of users, and (unlike Ilya TArasov) they stay away from comp.lang.forth because it is annoying to be attacked by Elizabeth Rather's sycophants who call them stupid and tell lies about them.

Attackers... heh :) I wonder to see a really hard attack here.

> I should learn a popular language such as Go or Python that people actually use --- nobody considers me to be a programmer right now --- my Forth experience doesn't count for anything in the real world.

I see a good way here - we should count Forth as an approach to write programs, not as a 'pure' language. Base languages here are C/Go/Assembler, and Forth is a tool, just like a collections of classes or framework. In this case you can go to your customer and say 'I know a better way to solve your problem - you need a scripting language inside your big project to make it flexible, and I know how to add this scripting language'.

[Jan Coombs]

On Sat, 22 Apr 2017 05:40:43 -0700 (PDT)
lehs <skydda...@gmail.com> wrote:
> Den lördag 22 april 2017 kl. 14:00:13 UTC+2 skrev Mark Wills:
> > On Saturday, 22 April 2017 12:30:41 UTC+1, lehs wrote:
> > >

> > > I [wish] there were some pseudo machine code language, not

> > > optimized to build up Forth, but optimized to be easy to
> > > be built up itselves from most machine codes in use. Of
> > > course such an intermediate stage would be less than
> > > optimal, but maybe more efficient than c and go.
> > >
> > > Then even I would try to learn that language and try to
> > > built up a Lehs-Forth.
> >
> > I think the thing you just wished for is... Forth. That's
> > what it is!
>
> If so, then Forth would be the perfect platform for building
> an operating system.

This would require starting from scratch, so would only happen
in a big way if something else forced this, for example:


The Unum[1] data type is a superset of integer, float, and [IMO]
BigNum which uses a compact variable length representation. It
is incompatible with current float hardware, and using it may
suggest a change to software algorithms which currently use
arrays, and suggests a different approach to handling complex
mathematical analysis.

Using Unums results in absolutely correct results from float
computation. A hardware implementation should reduce power
consumption by 50% due to reduced memory traffic[2].

Handling data items of variable length is only efficient while
they are stored without padding. In stack frames or other
compiler allocated spaces this becomes complex and/or
inefficient.

Because a Forth engine keeps data local to computation on the
stack, this can be stored efficiently with no gaps or need
for pre-allocated memory.

So, ISTM that the simplest implementation of Unum processor is
as a dual stack processor, and the obvious first choice for
low level language is fORTH.


Jan Coombs
--

[1] https://en.wikipedia.org/wiki/Unum_(number_format)
[2] http://insidehpc.com/2015/03/slidecast-john-gustafson-explains-energy-efficient-unum-computing/

Much more in book:
http://www.johngustafson.net/unums.html

Not to be confused with Unum v2:
http://ubiquity.acm.org/article.cfm?id=3001758

[Cecil Bayona]

One of the items with Go is that its assembler uses generic instructions
so they are the same with several 32/64 bit CPUs, I have never tried it.
That maybe accomplished with an assembler if good macro capabilities.

--
Cecil - k5nwa

[Cecil Bayona]

I didn't look at the options with running a compiler by command line and
yesterday I didn't get much of a chance to work with anything as a lot
of heavy thunderstorms kept moving through my area and I had to turn off
all the PCs but not so today so I will take a look after lunch.

I been using an IDE, Microsoft Visual Code, it may have an option in
there among the hundreds of options it has.

Since pointer math in any form is not allowed and the Intel chips has
addressing modes to handle indexing into an array it will be interesting
to see if the use them.

Thanks

--
Cecil - k5nwa

[Cecil Bayona]

On 4/22/2017 10:04 AM, Ilya Tarasov wrote:
> суббота, 22 апреля 2017 г., 7:53:32 UTC+3 пользователь hughag...@gmail.com написал:

>> I should learn a popular language such as Go or Python that people actually use --- nobody considers me to be a programmer right now --- my Forth experience doesn't count for anything in the real world.
>
> I see a good way here - we should count Forth as an approach to write programs, not as a 'pure' language. Base languages here are C/Go/Assembler, and Forth is a tool, just like a collections of classes or framework. In this case you can go to your customer and say 'I know a better way to solve your problem - you need a scripting language inside your big project to make it flexible, and I know how to add this scripting language'.
>

A long time ago, in a Galaxy far away, I did a similar thing. I would
use Borland Delphi and Forth for writing tools for work, so I ended
integrating a Forth in the libraries of Delphi so my applications had
Forth as an internal scripting language, I really liked it as menus and
databases could include Forth scripts to modify how the software worked
without having to re-compile and install a new version.

--
Cecil - k5nwa

[Cecil Bayona]

On 4/22/2017 4:39 AM, Andrew Haley wrote:

Just tried it out, was hard to figure out what was what so I surrounded
the test code with other simple code that can easily be spotted. The
result is that it did optimize the indexing operation fairly well and
generated fairly decent code.

But I found a few other things, it's pretty strict when it comes to
pointers and what one can do and it's very strict about data types and
their use, sort of like C with some ADA in terms of being very strict.

I'm not sure what to think of it, I did give up on C many years ago
because it was too lax and allowed me to do things that created nasty
bugs that were hard to find, I ended using Borland Delphi for many years
as it was a great development environment that gave heads up on stupid
mistakes, Go seems to be even more strict.

On the other hand Forth checks next to nothing and I like it that way
and I've never had a major bug that was not found early on. Being
interactive, and factoring a lot makes for code that can be tested well
so one gets it right with no bugs.
--
Cecil - k5nwa

[Ilya Tarasov]

суббота, 22 апреля 2017 г., 19:44:18 UTC+3 пользователь Cecil - k5nwa написал:

> > I see a good way here - we should count Forth as an approach to write programs, not as a 'pure' language. Base languages here are C/Go/Assembler, and Forth is a tool, just like a collections of classes or framework. In this case you can go to your customer and say 'I know a better way to solve your problem - you need a scripting language inside your big project to make it flexible, and I know how to add this scripting language'.
> >
>
> A long time ago, in a Galaxy far away, I did a similar thing. I would
> use Borland Delphi and Forth for writing tools for work, so I ended
> integrating a Forth in the libraries of Delphi so my applications had
> Forth as an internal scripting language, I really liked it as menus and
> databases could include Forth scripts to modify how the software worked
> without having to re-compile and install a new version.

This is an example of what I want to point to. Scripts running by visual components like buttons can greatly extend program functionality. Both programmer and user can get benefits from this. Why don't lead this way? This is a thetorical question indeed. Let's write a new program with some scripting features and we shall see what we really want from Forth.

[Coos Haak]

Op Fri, 21 Apr 2017 23:41:41 -0700 schreef Paul Rubin:

Even the structure of the assembler code is Forth-like. IF ELSE THEN
and BEGIN WHILE REPEAT are unknown in the assemblers I know.

groet Coos

[Paul Rubin]

Jan Coombs <jenfhaom...@murmic.plus.com> writes:
> The Unum[1] data type is a superset of integer, float, and [IMO]
> BigNum which uses a compact variable length representation.

You could also include pointers in the Unum type, that would themselves
point to these arbitrary-sized objects, that could then be nested to
any depth. Congratulions, you have invented Lisp :).

[Jan Coombs]

Yes, I would reserve a Unum representation for use as an
object pointer, perhaps an invalid exponent with the
fraction field containing the object address.

I'm uncertain of the value of indefinitely successive in-
direction, and showers of parentheses aggravate my dyslexia.

Python could run on a Unum stack engine with improved
performance. Three of the four numeric data types would merge:
plain integers, long integers, and floating point. The data
would be in the stack, and not require the two indirections as
used in the CPython virtual stack engine.

Who is there bold enough, willing to step outside the cage, and
be worthy of congratulions?

Jan Coombs
--

[hughag...@gmail.com]

On Friday, April 21, 2017 at 10:42:37 PM UTC-7, Cecil - k5nwa wrote:
> On 4/21/2017 11:53 PM, hughag...@gmail.com wrote:
> > I wouldn't dismiss Go because of this --- I would expect that incrementing and decrementing an array index would be almost as fast as incrementing and decrementing a pointer --- the difference is like one or two extra instructions, but the instructions may parallelize so they don't actually take any extra time.
> >
> > This is premature optimization!
>
> That why I wish I could see the generated code, it might not make a
> difference after optimization but I don't have a way of finding out
> right now,

Well, don't worry about it.

My point is that if you want speed, then you need to write in assembly-language. Any high-level language is going to be slow, but if this is just a learning exercise then don't worry about it --- most programs are okay with a slow language, because they aren't doing any heavy-duty processing, and the computer is very fast --- people program in Python and Ruby and are happy with them, although they are very slow.

> > Also, a Forth VM written in any high-level language is going to be significantly slower than generating machine-code with an STC Forth --- so the difference between C and Go in speed doesn't matter --- so long as you don't think that Perl (John Passaniti) or Python (Juergen Pintaske) is a good language to write a Forth VM in, you should get reasonable speed.
> >
> >> So its back to using C for now and finish what I started, I'm pretty
> >> close anyway with the C code to start testing the VM.
> >
> > C has a lot of problems of its own --- Anton Ertl complains about this continually --- I wouldn't use C.
>
> There are few system languages available that generate decent code,
> C/C++, Pascal, Go, Oberon, and Forth, other higher level languages are
> way too slow and require massive resources. I own several commercial
> copies of C/C++, and some old copies of Delphi, and various Forth
> Systems including Swift, and MPE VFX. C and Forth are the most viable
> and maybe Go. I like Delphi I dug it out and installed it but my old
> versions had problems with Windows 10 so I then started looking at Go,
> C++ is not under consideration. I might try loading Delphi in a Windows
> 7 Virtual PC and see how that works out tomorrow. Too many choices can
> be a major problem.

Another choice you might consider is GCC. This language has a lot of features beyond basic C. One of those features is the ability to dedicate registers globally --- this means that your stack pointer can be a register rather than a memory variable --- this can boost the speed considerably!

> > I am learning Go right now. I hadn't considered writing a Forth VM in Go, because I think FASM is better --- I had just been thinking of Go as a practical language for writing programs --- Python is very popular, but it is also very slowwwwww, so Go may eventually replace it as the most supported language available (supported in the sense of having code-libraries).
>
> I want to use Go for other purposes and I will but it would have been
> interesting to use this a learning experience, I might still do it
> anyway after I finish the C code so I have something to compare it
> against. The whole purpose of this is to have it be easy to move to a
> new PC without having to deal with a different assembler for each processor.

All computers use 64-bit x86 nowadays.

Back in the 1990s we had PowerPC and 80486, plus the MC68020 was still going strong, and the StrongARM was used in the Apple Newton and appeared to be the up-and-coming thing. Those days are past --- now all of the 32-bit processors are obsolete and the 64-bit x86 is the only processor used in desktop computers --- the ARM survived as a micro-controller.

> > Forth is just a weird hobby. It is soooooo dead! There are fewer than 20 ANS-Forth programmers in the world, and none of them are writing programs, but instead they spend their time on the Forth-200x mailing list pretending to be leaders. There are fewer than 200 Forth programmers in the world, but most of them are like Ilya Tarasov in that they write their own non-standard Forth system and have only a handful of users, and (unlike Ilya TArasov) they stay away from comp.lang.forth because it is annoying to be attacked by Elizabeth Rather's sycophants who call them stupid and tell lies about them.
>
> You read any of the articles by Charles Moore or his discussions and he
> sees Forth as a set of tools that are customized to the needs of the
> hour, I don't see him nailed to a Standard, he does as he pleases to get
> the job done. That is how I feel about Forth myself, it's nice to have a
> standard but it better be a good one or I will ignore it. I'm ignoring
> it for the most part, I can't stand all this ambiguity in it, I like
> simplicity.

This is what Ilya Tarasov says --- that Forth is a "methodology" --- at most he wants a set of guidelines for implementing and using Forth, but he doesn't seem interested in a standard. I'm not opposed to this. My MFX didn't conform to any standard, and the MiniForth processor was completely different from any other processor (then and now).

With my Straight Forth I am defining a standard, but I am also saying that the Straight Forth programmers would program in a novice-level manner 98% of the time, and program in an intermediate-level manner 2% of the time, and never program in an advanced-level manner. This is for mundane programming projects --- this is not for advanced programming --- but, advanced-level programmers don't always want to program in an advanced-level manner because most programs don't require this.

> > I should learn a popular language such as Go or Python that people actually use --- nobody considers me to be a programmer right now --- my Forth experience doesn't count for anything in the real world.
> >
>
> Poor baby, not being loved. I firmly believe that the only one that can
> make one happy is oneself, others can help, but most are in the way.

I don't aspire to be loved --- being employed would be nice though.

As long as I can remember, Forth programmers have not been considered to be programmers at all. None of the Forth Inc. books discuss structs, and the ANS-Forth standard does not make any mention of structs. It is generally believed that Forth programmers don't know what structs are, and hence that they aren't programmers at all. It is possible to write FIELD in ANS-Forth (this was one of the first things I wrote in the novice-package), but this is definitely intermediate-level programming --- the novice Forth programmer is not going to figure this out on his own --- and, for the most part, nobody is going to provide him with FIELD or even show an example of Forth code that uses FIELD so he could realize that FIELD exists.

Because FIELD is not in the ANS-Forth standard, there can be different implementations available that behave differently. For example, Forth-200x uses the name FIELD: for some obscure reason (afaik, FIELD has been the name since the 1980s). I challenge any of the comp.lang.forth experts to post code for FIELD here now --- most likely, none of them are able to do so.

Forth programmers have a reputation for being ignoramuses. Here is a typical quote from a Forth-200x committee member:
---------------------------------------------------------------------------
Aside from looking obscure and clever and satisfying the "[x] can do it, why not Forth?" test, what on earth does this buy you?
---------------------------------------------------------------------------
He is proud of his ignorance! Nobody has the time to teach him what a quotation is. Also, teaching him would be a waste of time, because it is obvious that he is going to refuse to learn. Why did he write an article about quotations and then the only thing he has to say is that he doesn't know what they are for. Obviously, his point is that he believes quotations are utterly useless, and he is not going to be convinced otherwise.

This is why Forth programmers are considered to be arrogant ignoramuses who are unable to learn --- and are considered to be ignorant of the most basic concepts such as structs --- unemployable!

[Alex]

On 4/22/2017 23:01, hughag...@gmail.com wrote:
> With my Straight Forth I am defining a standard, but I am also saying
> that the Straight Forth programmers would program in a novice-level
> manner 98% of the time, and program in an intermediate-level manner
> 2% of the time, and never program in an advanced-level manner. This
> is for mundane programming projects --- this is not for advanced
> programming --- but, advanced-level programmers don't always want to
> program in an advanced-level manner because most programs don't
> require this.

This is complete Stalinist brain fart territory.

--
Alex

[Cecil Bayona]

On 4/22/2017 5:01 PM, hughag...@gmail.com wrote:
> On Friday, April 21, 2017 at 10:42:37 PM UTC-7, Cecil - k5nwa wrote:
>> On 4/21/2017 11:53 PM, hughag...@gmail.com wrote:
>>> This is premature optimization!
>>
>> That why I wish I could see the generated code, it might not make a
>> difference after optimization but I don't have a way of finding out
>> right now,
>
> Well, don't worry about it.
>
> My point is that if you want speed, then you need to write in assembly-language. Any high-level language is going to be slow, but if this is just a learning exercise then don't worry about it --- most programs are okay with a slow language, because they aren't doing any heavy-duty processing, and the computer is very fast --- people program in Python and Ruby and are happy with them, although they are very slow.
>

I expect it to be slower, but there is no point in making it worse by
picking a poor implementation language. I wrote a small simple program
using some of the code to implement stacks and Go did well, better than
my C compiler for MSP430 CPUs so I won't worry about it and just use it.

>>> Also, a Forth VM written in any high-level language is going to be significantly slower than generating machine-code with an STC Forth --- so the difference between C and Go in speed doesn't matter --- so long as you don't think that Perl (John Passaniti) or Python (Juergen Pintaske) is a good language to write a Forth VM in, you should get reasonable speed.
>>>
>>>> So its back to using C for now and finish what I started, I'm pretty
>>>> close anyway with the C code to start testing the VM.
>>>
>>> C has a lot of problems of its own --- Anton Ertl complains about this continually --- I wouldn't use C.
>>

After looking at the Go generated code it's optimizing fairly well so I
will write the VM in Go as a programming exercise.

>
> Another choice you might consider is GCC. This language has a lot of features beyond basic C. One of those features is the ability to dedicate registers globally --- this means that your stack pointer can be a register rather than a memory variable --- this can boost the speed considerably!
>

GCC is Gnu C/C++ compiler, it's probably the reason why Anton curses at
C, it has a lot of bugs that they don't bother fixing and optimization
sometimes deletes needed code, so I will skip that.

>> I want to use Go for other purposes and I will but it would have been
>> interesting to use this a learning experience, I might still do it
>> anyway after I finish the C code so I have something to compare it
>> against. The whole purpose of this is to have it be easy to move to a
>> new PC without having to deal with a different assembler for each processor.
>
> All computers use 64-bit x86 nowadays.
>

This project is meant as a tool for embedded CPUs, the Windows version
is possible core for a tethered Forth for various non Intel CPUs that is
simple and easy to change.

>>
>> Poor baby, not being loved. I firmly believe that the only one that can
>> make one happy is oneself, others can help, but most are in the way.
>
> I don't aspire to be loved --- being employed would be nice though.

Pulling your leg, I'm quite aware on your positions on the various
personalities here, it's not you are shy about it.

>
> As long as I can remember, Forth programmers have not been considered to be programmers at all. None of the Forth Inc. books discuss structs, and the ANS-Forth standard does not make any mention of structs. It is generally believed that Forth programmers don't know what structs are, and hence that they aren't programmers at all. It is possible to write FIELD in ANS-Forth (this was one of the first things I wrote in the novice-package), but this is definitely intermediate-level programming --- the novice Forth programmer is not going to figure this out on his own --- and, for the most part, nobody is going to provide him with FIELD or even show an example of Forth code that uses FIELD so he could realize that FIELD exists.
>
> Because FIELD is not in the ANS-Forth standard, there can be different implementations available that behave differently. For example, Forth-200x uses the name FIELD: for some obscure reason (afaik, FIELD has been the name since the 1980s). I challenge any of the comp.lang.forth experts to post code for FIELD here now --- most likely, none of them are able to do so.
>

Structures, Unions, database code, Networking Stacks, Multi-Tasking, and
various data types are all vital parts to programming, quite a few
people are unaware of why they are useful which is OK since you can get
around without them sometimes but when they make that the only
acceptable way to look at things they lost me, not that they care.
Ignorance is not a virtue.


--
Cecil - k5nwa

[Ilya Tarasov]

воскресенье, 23 апреля 2017 г., 1:38:44 UTC+3 пользователь Alex написал:

I see here just an observatin and conslusion. One can dream about thousand wise professionals, waiting for standard full of cool-looking words. In reality, there is no problem with programming languages availability, so nobody can be forced to use Forth just because no other language around. There are a lot of languages. The only possibility to see Forth in action is to provide desired features to focus groups of customers. Many of them are next to programmers, but no pure programmers, and wants a tool for scripting or rapid modelling with interactive mode. I don't know how to calculate this proportion, but 98% may be true. Start to tell them about 300-400 words in standard, custom file IO and floating-point format, and they will leave you.

[hughag...@gmail.com]

Straight Forth is intended to be a way for Forthers to write mundane programs, but allow those programs to be portable --- these are programs typically written in Python, Ruby, etc. --- also, Straight Forth in intended to support Forth cross-compilers, which Python, Ruby, etc. don't support.

It is also worthwhile to make writing these mundane programs easy --- having arrays and chains already available brings most mundane programs within reach of the novice --- if other data-structures are needed, then this will require an intermediate-level programmer.

Straight Forth is not intended to be the last word on Forth. It is intended to be useful 98% of the time. There will always be advanced Forth programmers doing their own thing --- I don't stop them --- I do that too, sometimes.

[hughag...@gmail.com]

On Saturday, April 22, 2017 at 4:19:14 PM UTC-7, Cecil - k5nwa wrote:
> On 4/22/2017 5:01 PM, hughag...@gmail.com wrote:
> > All computers use 64-bit x86 nowadays.
>
> This project is meant as a tool for embedded CPUs, the Windows version
> is possible core for a tethered Forth for various non Intel CPUs that is
> simple and easy to change.

I was not aware that Go was used in micro-controllers.

[Paul Rubin]

Jan Coombs <jenfhaom...@murmic.plus.com> writes:
> Who is there bold enough, willing to step outside the cage, and
> be worthy of congratulions?

John McCarthy? Again, you're reinventing Lisp from 60 years ago.

[Cecil Bayona]

Its available for ARM, ARM64, Intel X64/i386 CPUs, PPC64, Mips and Mips
64, and IBM s390. In any case if I write it in Go it will be a compiler
tethered to a embedded target. The initial version will be for Windows,
after that I thing I will make it generate code for a J1 FPGA CPU.

--
Cecil - k5nwa

[Rod Pemberton]

On Fri, 21 Apr 2017 21:53:31 -0700 (PDT)
hughag...@gmail.com wrote:

> Also, a Forth VM written in any high-level language is going to be
> significantly slower than generating machine-code with an STC Forth

Just how did you manage to come to that conclusion?

> --- so the difference between C and Go in speed doesn't matter --- so
> long as you don't think that Perl (John Passaniti) or Python (Juergen
> Pintaske) is a good language to write a Forth VM in, you should get
> reasonable speed.

I'm surprised you didn't directly mention me here, "or C (Rod
Pemberton)". I'm not sure whether to thank you or not.

> C has a lot of problems of its own --- Anton Ertl complains about
> this continually --- I wouldn't use C.

That's still not sufficient cause someone to not use C. C and Forth are
the most ubiquitous languages (i.e., widely available). So, you need
to use one of them for portability. Otherwise, you're stuck with
porting the assembly to each and every new platform.


Rod Pemberton
--
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

[Ron Aaron]

On 23/04/2017 1:01, hughag...@gmail.com wrote:

> My point is that if you want speed, then you need to write in assembly-language

Incorrect.

A poorly-written ASM program will not out-perform a well-written (choose
your language) program.

A great ASM program using a poor algorithm will not out-perform (for
long) a poorly written HLL program using an excellent algorithm.

A complex program in ASM may take many (many!) times longer to write
than an equivalent HLL program. So even if theoretically the ASM
program would run faster, your customer will long since have fired you
for lack of delivery.

There is more than one variable to consider.

[Alex]

Yes. In particular, there is a tendency for some to write & post code,
and demand that others do so, without too much consideration to design,
maintenance, applicability etc.

Our resident Ruby/Scheme/Python obsessive is a case in point.
WJ/waxman/Robert L or whatever handle he's using this week is a
minimalist; he finds an esoteric problem, a library to call, and writes
some fantastically arcane incantation in a single line so he can declare
victory. "In Forth?" being his signature flourish.

Hugh is at the opposite end of the spectrum; volume and yardage counts
here. Piles of code, endlessly repeated, A sneering "In Forth?" is
replaced by novel's worth of hollering and shouting at everyone that
they're sales clowns because they're not advanced programmers liek wot
he is coz novice code innit.

Neither is a programmer, but neither can see it.

--
Alex

[Alex]

On 4/23/2017 00:30, Ilya Tarasov wrote:
> воскресенье, 23 апреля 2017 г., 1:38:44 UTC+3 пользователь Alex
> написал:
>> On 4/22/2017 23:01, hughag...@gmail.com wrote:
>>> With my Straight Forth I am defining a standard, but I am also
>>> saying that the Straight Forth programmers would program in a
>>> novice-level manner 98% of the time, and program in an
>>> intermediate-level manner 2% of the time, and never program in
>>> an advanced-level manner. This is for mundane programming
>>> projects --- this is not for advanced programming --- but,
>>> advanced-level programmers don't always want to program in an
>>> advanced-level manner because most programs don't require this.
>>
>> This is complete Stalinist brain fart territory.
>
> I see here just an observatin and conslusion. One can dream about
> thousand wise professionals, waiting for standard full of
> cool-looking words.

This is classic Ilya; most of your posts follow the same pattern. Dream
something up, then knock it down. It's called a straw man.

> In reality, there is no problem with programming languages
> availability, so nobody can be forced to use Forth just because no
> other language around.

Welcome back to planet Earth.

> There are a lot of languages. The only possibility to see Forth in
> action is to provide desired features to focus groups of customers.
> Many of them are next to programmers, but no pure programmers, and
> wants a tool for scripting or rapid modelling with interactive mode.
> I don't know how to calculate this proportion, but 98% may be true.
> Start to tell them about 300-400 words in standard, custom file IO
> and floating-point format, and they will leave you.

Leave you what? Behind? Impressed? Penniless?

--
Alex

[Jan Coombs]

Much as I'd like to agree with you, this is unlikely. My focus
is on hardware development. This is because the Unum data type
is incompatible with current float hardware, (see below) so
efficient modelling of Unums is not possible, and adding a
Unum library to any language nearly pointless.

As for Forth, it would be simplified: No need for a separate
float stack, automatic promotion of integers to exact floats[1]
or BigNum when arithmetic demands it. Double numbers redundant.
Significant compression of Flags and small integers.


The IEE754 float has the leftmost bit of the mantissa hidden,
and the rest in a fixed length field. In this field the bits
toward the left contain data, and the rest junk.

In a Unum[2] mantissa field, all bits contain valid data. If
padding is needed to match field allocation granularity it must
be a sign bit extension, at the left end.

So, the mantissa of an IEE754 float is left aligned, and that of
a Unum is right aligned. This is why the Unum data type cannot
be efficiently modelled in current processor hardware.

This difference is what allows a Unum processor to produce
correct results[1] and use less power. Correct because no junk
is stored in the mantissa. An anticipated 50% power saving
because of not having to move this junk to and from main
memory.[3]


Is this really an opportunity to support simpler programming
languages with greater computational efficiency, or a magical
fairy tale from the dark side, or perhaps both?

Jan Coombs
--

[1] The Unum mantissa is extended one bit past the ULP, this
'Uncertainty bit' declares whether the mantissa is exact, or is
the base of an open interval one ULP wide. Unum computation
results are correct, even where this requires declaring the
bounds of uncertainty to achieve this. (Unlike IEE754)

[2] That is Unum type 1. In Unum type 2 reduced benefits
are anticipated because the binary format used is of fixed
length.

[3] "The End of Error" pg6: Energy cost of 64b float read from
reg and MAC operation is 70pJ, the cost of fetching 64b from
DRAM is 4200pJ, 60 times more! (on 2010 era hardware) Unum data
is inherently compressed. (at the cost of on-chip complexity)

[Ilya Tarasov]

воскресенье, 23 апреля 2017 г., 6:54:30 UTC+3 пользователь Ron Aaron написал:

Both opinions has a good base. For low level code, skilled programmer, familiar with CPU architecture and assembler, can avoid overhead, that possible may be added by HLL. When moving high, even a skilled programmer cannot pay enough attention to track all aspects of his program, and resulting code probably will be poor architectured, as you mentioned. Assembler can provide many amazing abilities such as tiny code size, manually controlled register scheduling, CPU extensions (SSE provides x4 speed when coded manually and placed properly) etc. Hovewer, assembler coding should be started only after completing full specification.

[Ilya Tarasov]

воскресенье, 23 апреля 2017 г., 11:25:37 UTC+3 пользователь Alex написал:

> > I see here just an observatin and conslusion. One can dream about
> > thousand wise professionals, waiting for standard full of
> > cool-looking words.
>
> This is classic Ilya; most of your posts follow the same pattern. Dream
> something up, then knock it down. It's called a straw man.

No, this is because most of dreams follow the same pattern. I have one opinion and repeating dreams about Forth future will cause repeating my arguments. In other discussions I'm telling other words.

> > In reality, there is no problem with programming languages
> > availability, so nobody can be forced to use Forth just because no
> > other language around.
>
> Welcome back to planet Earth.

When explain me, how next statement may co-exist in reality:
1. 'We have a Standard and your feature is not compatible'
2. 'Nobody can force you or anyone else to use Standard'

1. 'Forth Inc has 40 years of experience in Forth and we see no reasons to change something'
2. 'There are no many of Forth programmers'

> > There are a lot of languages. The only possibility to see Forth in
> > action is to provide desired features to focus groups of customers.
> > Many of them are next to programmers, but no pure programmers, and
> > wants a tool for scripting or rapid modelling with interactive mode.
> > I don't know how to calculate this proportion, but 98% may be true.
> > Start to tell them about 300-400 words in standard, custom file IO
> > and floating-point format, and they will leave you.
>
> Leave you what? Behind? Impressed? Penniless?

Maybe this is a result of mixing Russian and English idioms. I don't use any translators and simple switching to English in mind when typing messages here. Just imagine you are telling about Forth and issue many many limiting rules, including obsolete ones. 'Can we change this?' - 'No, it is Forth, it is Standard!'. As a result, your possible customer, comes to you after reading about flexible and easy to implement language, will be disappointed, and you will without his money, but satisfied you successfully defend very deep Forth ideas from changing.

Can you tell YOUR opinion about what should be done next year to make Forth better?

[Julian Fondren]

On Sunday, April 23, 2017 at 8:32:45 AM UTC-5, Ilya Tarasov wrote:
>
> When explain me, how next statement may co-exist in reality:
> 1. 'We have a Standard and your feature is not compatible'
> 2. 'Nobody can force you or anyone else to use Standard'

Apart from the sheer obviousness of these easily existing in reality?
I feel like there's some fundamental confusion here, on the level of
"wage-work is slavery because if you don't work you'll starve".

> 1. 'Forth Inc has 40 years of experience in Forth and we see no reasons to change something'
> 2. 'There are no many of Forth programmers'

Again, there's no contradiction whatsoever. In practice, 'something'
is usually some specific thing that the speaker offers as the single
reason for #2. Oh if only it had been possible all those years, year
after year, for people to experiment with incompatible extensions or
reworkings of Forth (the joke to be clear is that was so possible that
it happened and keeps happening) -- if only *that*, then Forth would
be popular today!

In reality these are just shysters who guess or have discerned that
their audience is sensitive about its popularity. Once that
discernment is made, every personal goal or axe to grind becomes "the
reason Forth isn't more popular" or "the last hope for Forth to become
more popular". It's tiresome. If you're *not* a shyster, and have some
grand plan, then implement it and talk about how well it went. Talk is
cheap but ten years and five hundred "let's have something like CPAN"
posts still must've cost more than http://theforth.net/ does.

> Just imagine you are telling about Forth and issue many many limiting rules, including obsolete ones. 'Can we change this?' - 'No, it is Forth, it is Standard!'. As a result, your possible customer, comes to you after reading about flexible and easy to implement language, will be disappointed, and you will without his money, but satisfied you successfully defend very deep Forth ideas from changing.

Change what for example? The 'oppressive' "no, don't do that, do
this" that comes to mind is all oriented towards helping someoone
discover the magic of the language, and not to defend a standard. The
obvious one is using locals -- which are standard, or writing long
mega-functions, against which the standard has no provision. When code
is posted, complaints about non-standard words are usually just "what
does that mean?" Have you ever seen someone attack code having some
envionmental dependency with the same energy they would use to
recommend less use of locals or better factoring?

> Can you tell YOUR opinion about what should be done next year to make Forth better?

Produce a 'framework' for 'ninjas'.

Or less ironically:

Produce a framework for ninjas.

It's like a library but with better documentation, and a better
website.

[Ron Aaron]

On 23/04/2017 11:16, Alex wrote:
> On 4/23/2017 04:54, Ron Aaron wrote:

>> There is more than one variable to consider.
>>
>
> Yes. In particular, there is a tendency for some to write & post code,
> and demand that others do so, without too much consideration to design,
> maintenance, applicability etc.

Indeed. Not that I have anything against ASM. I like it a lot; but
it's not an automatic 'win', and can often be more of a problem than its
worth.

> Our resident Ruby/Scheme/Python obsessive is a case in point.
> WJ/waxman/Robert L or whatever handle he's using this week is a
> minimalist; he finds an esoteric problem, a library to call, and writes
> some fantastically arcane incantation in a single line so he can declare
> victory. "In Forth?" being his signature flourish.
>
> Hugh is at the opposite end of the spectrum; volume and yardage counts
> here. Piles of code, endlessly repeated, A sneering "In Forth?" is
> replaced by novel's worth of hollering and shouting at everyone that
> they're sales clowns because they're not advanced programmers liek wot
> he is coz novice code innit.
>
> Neither is a programmer, but neither can see it.

You left off werty.

Programming's about a lot more than the tool de jour. But we know that...

[Alex]

On 4/23/2017 14:32, Ilya Tarasov wrote:
> воскресенье, 23 апреля 2017 г., 11:25:37 UTC+3 пользователь Alex
> написал:
>>> I see here just an observatin and conslusion. One can dream about
>>> thousand wise professionals, waiting for standard full of
>>> cool-looking words.
>>
>> This is classic Ilya; most of your posts follow the same pattern.
>> Dream something up, then knock it down. It's called a straw man.
>
> No, this is because most of dreams follow the same pattern. I have
> one opinion and repeating dreams about Forth future will cause
> repeating my arguments. In other discussions I'm telling other
> words.
>
>>> In reality, there is no problem with programming languages
>>> availability, so nobody can be forced to use Forth just because
>>> no other language around.
>>
>> Welcome back to planet Earth.
>
> When explain me, how next statement may co-exist in reality: 1. 'We
> have a Standard and your feature is not compatible' 2. 'Nobody can
> force you or anyone else to use Standard'
>
> 1. 'Forth Inc has 40 years of experience in Forth and we see no
> reasons to change something' 2. 'There are no many of Forth
> programmers'

Since you seem think that I'd argue one or the other, and that they
represent some version of reality, let me point out that they don't; all
I can tell you is that these made up positions are not worth discussing.

>
>>> There are a lot of languages. The only possibility to see Forth
>>> in action is to provide desired features to focus groups of
>>> customers. Many of them are next to programmers, but no pure
>>> programmers, and wants a tool for scripting or rapid modelling
>>> with interactive mode. I don't know how to calculate this
>>> proportion, but 98% may be true. Start to tell them about
>>> 300-400 words in standard, custom file IO and floating-point
>>> format, and they will leave you.
>>
>> Leave you what? Behind? Impressed? Penniless?
>
> Maybe this is a result of mixing Russian and English idioms. I don't
> use any translators and simple switching to English in mind when
> typing messages here.

It might help using a translator, since sometimes I'm having difficulty
with the sense. But that's not a problem here.

> Just imagine you are telling about Forth and issue many many limiting

. ^^^^^^^^^^^^ Here we go again... This is the problem.

> rules, including obsolete ones. 'Can we change this?' - 'No, it is
> Forth, it is Standard!'. As a result, your possible customer, comes
> to you after reading about flexible and easy to implement language,
> will be disappointed, and you will without his money, but satisfied
> you successfully defend very deep Forth ideas from changing.

Another straw man. "Just imagine." Then you knock it down. Well done.
Your "just imagine" is not what I imagine, not at all.

>
> Can you tell YOUR opinion about what should be done next year to
> make Forth better?

Not a clue, since I didn't realise it needed to be made better.

--
Alex

[Alex]

On 4/23/2017 16:41, Ron Aaron wrote:
> You left off werty.

God, now that brings back bad memories.

--
Alex

[Cecil Bayona]

On 4/19/2017 6:32 PM, Cecil Bayona wrote:
> I been working on a project using C to create a small Forth VM similar
> to eForth, I have been making progress and soon it will be time to use
> that Forth VM as the core of a complete Forth system. Since the core
> it's written in C and the rest in Forth it should be easy to transport
> to various CPUs.
>
> As a side project I bought some books on Go a system programming
> language and have it setup on my development PC, so I was thinking that
> once the Forth VM in C is tested and working to rewrite the whole thing
> in Go as a Go learning exercise.
>
> I was going to write the whole thing in C++ and even bought a few books
> on C++, about $150 worth but then I rediscovered why I disliked C++ in
> the first place so many years ago so that proved a waste of money. That
> is why I started looking at Go so I could have a more modern language to
> use in writing system software, it has limited Object programming but
> unlike C++ which I dislike.
>
> Go is not available for embedded processors other that ARM but it don't
> see that as a major problem, it is available for all the major OSes like
> Windows. OS X, and a multitude of Linux and other similar OSes like BSD.
>
> I want to learn Go for other uses so the possibility to use something
> else besides Go to write this software such as Forth compilers is a
> possibility. Other options are enhanced Forth like languages such as
> 8th, or oForth. Since Go is somewhat similar to C it's not a stretch to
> rewrite working C code in it.
>
> So, does anyone in the group have experience with Go in writing a Forth
> compiler or other major software or know of links to someone else's work
> on using Go in writing compilers?
>
> Thanks in advance.
>
Well things keep getting more complicated, Delphi and Forth are my two
favorite languages.

When I wanted to do this project my first thought was Borland Delphi,
but it turns out that the software I own is no longer compatible with
Windows 10 the OS used by my horde of PCs. Embarcadero who bought
Borland did not offer a free version of Delphi, I consider that a dumb
move on their part as many were introduce to the superior environment of
Delphi that way. It seems they now offer a free version of Delphi so I
downloaded and installed it, towards the weekend I will try it out but
it seems they have made drastic changes to the interface which is now
similar to Mono so we will see if it works out. There is always Lazarus
for a Delphi interface.

In the meantime I will halt development the C version of the software
and give Go a try the VM is worked out and most of the code is in place
so I have a guide to proceed with.

I still can't believe these guys took out Unions, that is such a handy
feature but I see why one has no clue what an Union holds at any one
time, no ambiguity allowed, the Forth Standard could learn something
from that.

--
Cecil - k5nwa

[minf...@arcor.de]

Why Go and not Rust? Serious question, performance-wise.

[Joel Rees]

On Saturday, April 22, 2017 at 1:58:32 PM UTC+9, Rudy Velthuis wrote:
> Coos Haak wrote:
>
> > Op Fri, 21 Apr 2017 20:28:40 +0000 (UTC) schreef Rudy Velthuis:
> >
> > > Andrew Haley wrote:
> > >
> > >>> But it is still an assembler core with the rest in Forth. What you
> > >>> consider "core" may be different. Fact is that there is "a core"
> > of >>> assembler words on which the rest builds.
> > >>
> > >> It's never felt that way to me. Code written in Forth's assembler
> > is >> still Forth: it's low-level Forth
> > >
> > > Assembler is assembler, no matter how you look at it, and it doesn't
> > > matter if that assembler was written in Forth or any other way.
> >
> > My Forth is completely written in Forth.
> > A lot of definitions are in assembly code that is
> > compiled (assembled) within Forth and its integrated Assembler.
> > No assembler like MASM TASM NASM or FASM has ever touched it.
>
> The assembler is written in Forth. You can't deny it is still assembly
> language. And I assume you (or someone else) had to start with

> assembler or C or whatever for the very low level stuff, unless you
> manually assembled the byte codes, or used another Forth to assemble
> yours.

C has been called an assembly language for a portable run-time.

Joel Rees
--
Imagining I'm a novelist.
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html

[Lars Brinkhoff]

Joel Rees wrote:
> C has been called an assembly language for a portable run-time.

Now that I've seen Forth, I no longer consider C close to assembly
language. Even less so with contemporary C compilers.

[Rudy Velthuis]

Jan Coombs wrote:

> I think that if you asked a number of assembler programmers to
> use the simplest forth assemblers that I have used and written,
> then the average response would be:
>
> "That is not [what I call] an assembler"

That may be. I wouldn't call my wife's Smart (car) a real car either,
but it officially is. <g>

--
Rudy Velthuis http://www.rvelthuis.de

"The man with a toothache thinks everyone happy whose teeth
are sound." -- George Bernard Shaw

[Rudy Velthuis]

Alex wrote:

> Yes, I was serious. Semantic arguments about where the assembler ends
> and where Forth starts are pretty pointless

Not at all. The Forth *assemblers* (note the name) are still
assemblers, i.e. they turn assembler mnemonics into machine code.
Proper assemblers may be more comfortable, but the Forth ones remain
assemblers.

--
Rudy Velthuis http://www.rvelthuis.de

"Researchers have discovered that chocolate produces some of the
same reactions in the brain as marijuana. The researchers also
discovered other similarities between the two but can't remember
what they are." -- Matt Lauer on NBC's Today Show.

[Rudy Velthuis]

Yes, but C does not use assembler mnemonics that more or less directly
translate to the machine code produced. Assemblers do, and so do Forth
assemblers.

It is futile to deny that.

--
Rudy Velthuis http://www.rvelthuis.de

"They say such nice things about people at their funerals that it
makes me sad that I'm going to miss mine by just a few days."
-- Garrison Kielor.

[Jan Coombs]

On Sat, 29 Apr 2017 03:05:16 +0000 (UTC)
"Rudy Velthuis" <newsg...@rvelthuis.de> wrote:

> Jan Coombs wrote:
>
> > I think that if you asked a number of assembler programmers
> > to use the simplest forth assemblers that I have used and
> > written, then the average response would be:
> >
> > "That is not [what I call] an assembler"
>
> That may be. I wouldn't call my wife's Smart (car) a real car
> either, but it officially is. <g>

Perhaps there is no official designation for half a car.:)

Jan Coombs

[Alex]

On 4/29/2017 04:08, Rudy Velthuis wrote:
> Alex wrote:
>
>> Yes, I was serious. Semantic arguments about where the assembler ends
>> and where Forth starts are pretty pointless
>
> Not at all. The Forth *assemblers* (note the name) are still
> assemblers, i.e. they turn assembler mnemonics into machine code.
> Proper assemblers may be more comfortable, but the Forth ones remain
> assemblers.
>

You're proving my point.

Or, try this;
http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf

--
Alex

[lehs]

Can Paf be downloaded? Does it works well? Several processors?

[Joel Rees]

Portable run-times are not real CPUs, either.

But while I'm lost in memories, there was an assembler once that
used = for moves and + for adds, etc., and was written in infix.

One-to-one mapping, but using the more familiar symbols.

[Joel Rees]

On Saturday, April 29, 2017 at 12:08:20 PM UTC+9, Rudy Velthuis wrote:
> Alex wrote:
>
> > Yes, I was serious. Semantic arguments about where the assembler ends
> > and where Forth starts are pretty pointless
>
> Not at all. The Forth *assemblers* (note the name) are still
> assemblers, i.e. they turn assembler mnemonics into machine code.

Pointed it out elsewhere, but I'll repeat it here.

There are historical assemblers that use algebra symbols ("+", "-", "=", etc.) for mnemonics and take their statements in infix.

> Proper assemblers may be more comfortable,

Clearly, you and I have different ideas about what is comfortable.

Although I will admit that assemblers that try too much to help you follow the vendor's idea of run-time architecture get really tiring really quickly.

> but the Forth ones remain assemblers.

I've seen assemblers that can actually handle loops and conditionals
without labels, and macros can spit out optimized object code equivalent
to multiple lines of source.

But Forth assemblers allow you to go several levels of symbolic
expression beyond that.

--
Joel Rees

Chocolate?
Nothing beats pure cacao mass.

[Rudy Velthuis]

Joel Rees wrote:

> But Forth assemblers allow you to go several levels of symbolic
> expression beyond that.

Fact remains that *some* low level words in *any* Forth are written in
assembler or in a language that can go pretty low level, like C. But
then the primitives of that language are again partly written in
assembler. There is no way around that.

If I say "assembler", it doesn't matter if the assembler code is
written in Forth and has certain neat features for a Forth system or if
it is a dedicated general purpose assembler like MASM, NASM, TASM, GAS
or even a built-in assembler of languages like BBC Basic or Delphi. etc.

--
Rudy Velthuis http://www.rvelthuis.de

"That's not a lie, it's a terminological inexactitude."
-- Alexander Haig

[Anton Ertl]

lehs <skydda...@gmail.com> writes:
>Den l=C3=B6rdag 29 april 2017 kl. 10:46:04 UTC+2 skrev Alex:
>> http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf
>>=20
>> --=20

>> Alex
>
>Can Paf be downloaded? Does it works well?

No. It has not been implemented 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 2017: http://www.euroforth.org/ef17/

[lehs]

I think the idea is good. It must be simpler to translate Pof to some processors machine code than Forth to machin code. FOS could be built upon Pof.

[hughag...@gmail.com]

On Saturday, April 29, 2017 at 6:44:44 AM UTC-7, Anton Ertl wrote:

> lehs <skydda...@gmail.com> writes:
> >Can Paf be downloaded? Does it works well?
>
> No. It has not been implemented yet.

Anton Ertl has his PAF (Portable Assembler for Forth) and I have my Hugh-niversal Assembler, which has also not been implemented yet.

Anton Ertl's PAF is for 32-bit processors, but this is a mistake because ARM assembly-language already is the universal assembly-language for 32-bit processors. Mine is for 16-bit processors where we still have some variety (PIC-24, MSP-430, plus a variety of FPGA-based processors).

Anton Ertl's PAF abstractifies the number of registers, but this is a mistake because the number of registers is the one thing that has to be standardized. Mine sets the number of registers at 8 --- they correspond to the i80186 registers --- the i80186 is obsolete now, and it wasn't very good in its day either, but everybody is familiar with the assembly-language so they can learn mine easily as it is pretty similar (I don't have segment registers, or other features not needed in a micro-controller). If a processor has fewer registers (the 6812, for example), then some of my registers will have to be in memory; this will slow down execution speed a lot, but at least you get portability. If a processor has more registers (the MSP-430, for example), then some of its registers will not be exposed to the user. If a processor has a lot of registers (the PIC-24, for example), then it could have ISRs written in Forth, and not require swapping registers with memory upon entering and leaving the ISRs --- from the user's perspective, the programs only have 8 registers, so the source-code is portable to other systems --- in register-starved processors, the registers will have to be swapped with memory upon entering and leaving the ISRs, but this is not exposed to the user.

My goal with the Hugh-niversal assembly-language is that a Forth system can be written, and if it needs to be targeted to a new processor, only the assembler needs to be rewritten to generate machine-code for this processor --- all of the Forth code, and all of the Forth code-libraries, will move over without modification.

[Alex]

On 4/29/2017 12:35, Rudy Velthuis wrote:
> Joel Rees wrote:
>
>> But Forth assemblers allow you to go several levels of symbolic
>> expression beyond that.
>
> Fact remains that *some* low level words in *any* Forth are written in
> assembler or in a language that can go pretty low level, like C. But
> then the primitives of that language are again partly written in
> assembler. There is no way around that.
>
> If I say "assembler", it doesn't matter if the assembler code is
> written in Forth and has certain neat features for a Forth system or if
> it is a dedicated general purpose assembler like MASM, NASM, TASM, GAS
> or even a built-in assembler of languages like BBC Basic or Delphi. etc.
>

Is Forth a BASIC? Not really. But then here's a BASIC in Forth;
http://home.vianetworks.nl/users/mhx/basic.html. Scheme? Why not.
http://forums.parallax.com/discussion/160027/lisp-technically-scheme-written-in-forth.


Or perhaps you want a webserver; https://bernd-paysan.de/httpd-en.html.
This one is very illustrative of the Forth way; this is an HTTP
*language*. It understands HTTP directly. "... a few hundred lines of
code... has delivered an 'almost' complete Apache clone."

Classifying stuff the way you are doing is not useful; languages, and
especially Forth, don't fall into neat categories. Forth can (and has
been) all those assemblery/BASICy/Schemey/HTTPee things while still
being Forthish. Rigid boundaries and thinking will make your Forth rigid
too; your code will be stiff & unnatural.

--
Alex