machineforth != forth?

[Mux]

Philosophical question...

Where do you draw the line as to what's considered a forth implementation? I've got a minimal forth that's much closer to machine forth and (therefore) doesn't conform to any of the ANS-forth standards. Is that still considered forth?

Thoughts?

-Y

[Bernd Paysan]

Machine Forth is probably 3/4th of a Forth:

- Has words (blank separated symbols and numbers)? yes
- Has stacks? yes
- Has definitions? yes
- Is interactive? no

ANS Forth or Forth 2012 don't mandate that you include everything into the
system, it only requires that you can load it as source, which means that
even very minimal systems can potentially comply - by loading the source.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[m.a.m....@tue.nl]

On Wednesday, August 19, 2015 at 10:49:49 PM UTC+2, Bernd Paysan wrote:
> Mux wrote:
>
> > Philosophical question...
> >
> > Where do you draw the line as to what's considered a forth implementation?
> > I've got a minimal forth that's much closer to machine forth and
> > (therefore) doesn't conform to any of the ANS-forth standards. Is that
> > still considered forth?
>
> Machine Forth is probably 3/4th of a Forth:
>
> - Has words (blank separated symbols and numbers)? yes
> - Has stacks? yes
> - Has definitions? yes

Ok.

> - Is interactive? no

Then it isn't Forth, in my book.

[..]

-marcel

[Anton Ertl]

Mux <Yvo....@gmail.com> writes:
>Philosophical question...
>
>Where do you draw the line as to what's considered a forth implementation? I've got a minimal forth that's much closer to machine forth and (therefore) doesn't conform to any of the ANS-forth standards. Is that still considered forth?

Many non-standard compliant systems are considered Forth by most
people. It's more an issue of some basic properties; probably most
people consider the requirements that Bernd Paysan posted as
essential, but many will also have additional requirements. E.g.,
Wolf Wejgaards HolonForth does not support metaprogramming (e.g.,
writing macros), so I don't cosider it a full Forth. Others may
disagree.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

[Roelf Toxopeus]

Like any underlying virtual machine or CPU instruction set.

So a Forth (all 4 ticks) based upon MachineForth is Forth! Like
ColorForth. Perhaps the OT's Forth is likewise. I recall an interactive
MachineForth for ARM around 1999.

At iTV, weren't they using (Machine)Forth harware upon which they
implemented an ANS Forth as well as a non-ANS Forth called MachineForth?

The name MachineForth is used for at least 3 things:
-hardware and thus the assembler for ...
-virtual machine (upon whatever CPU) for a Forth implementation
-the name for some of those realized implementations

As a reminder:
http://www.ultratechnology.com/forth0.htm#mf

[Roelf Toxopeus]

On 20/08/15 10:10, Anton Ertl wrote:
> Mux <Yvo....@gmail.com> writes:
>> Philosophical question...
>>
>> Where do you draw the line as to what's considered a forth implementation? I've got a minimal forth that's much closer to machine forth and (therefore) doesn't conform to any of the ANS-forth standards. Is that still considered forth?
>
> Many non-standard compliant systems are considered Forth by most
> people. It's more an issue of some basic properties; probably most
> people consider the requirements that Bernd Paysan posted as
> essential, but many will also have additional requirements. E.g.,
> Wolf Wejgaards HolonForth does not support metaprogramming (e.g.,
> writing macros), so I don't cosider it a full Forth. Others may
> disagree.

I quite like this statement, thank you Anton!

Now Bernd's requirements might give the first impression for something
being Forth or not. Some, like me, might put the useability, the
practical usage, as the first most requirement. There are some systems
called Forth(ish) I'd rather not use.

[Mux]

> > - Is interactive? no
>
> Then it isn't Forth, in my book.
>
> [..]
>
> -marcel

By that definition, any interpreted language can be considered forth, no? For me, forth embodies more than ticking a number of boxes. The hardware architecture itself, a way of thinking and applying the KISS approach. Interactivity can be part of it but that's in now way implied. Like I said, by that token writing a script in php falls into that category.

-Y

P.S. Just stating my opinion :-) Thanks for sharing yours!

[hughag...@gmail.com]

He isn't saying that every interactive language is Forth, just that Forth has to be interactive to be Forth.

My MFX wasn't interactive --- I just cross-compiled into a memory image and then uploaded that to the board, similar to a C cross-compiler --- Testra has since written a traditional interactive on-board Forth system in MFX, although it doesn't support assembly-language so MFX is still required for ye olde Pareto Analysis upgrades.

An on-board Forth system can't generate machine-code because it can't write into program memory --- this is a common limitation in Harvard Architecture systems --- it is unlikely that Marcel Hendrix knows what Harvard Architecture is, or he wouldn't have stated that Forth has to be interactive.

[m.a.m....@tue.nl]

On Friday, August 21, 2015 at 5:29:21 AM UTC+2, Mux wrote:
> > > - Is interactive? no
> >
> > Then it isn't Forth, in my book.
> >
> > [..]
> >
> > -marcel
>
> By that definition, any interpreted language can be considered forth, no?

No, of course not, that is a logically unsound / wrong statement.
Apples have cores, but having a core doesn't make my computer
a Granny Smith.

> For me, forth embodies more than ticking a number of boxes.
> The hardware architecture itself, a way of thinking and applying
> the KISS approach. Interactivity can be part of it but that's in
> now way implied. Like I said, by that token writing a script in
> php falls into that category.

False reasoning. I said that it had to have an interpreter to be
Forth, not that that was the only thing it has to have. PHP does
not qualify.

> The hardware architecture itself, a way of thinking and applying
> the KISS approach.

If I must be more specific: I am sure the hardware has nothing
to do with being Forth -- Forth can be implemented on anything
(One can imagine crappy hardware architectures or incompetent
programmers that make the interpreter very inefficient).

'A way of thinking' is obviously true but says nothing.

I am not a big KISS proponent, but lately it has become clear to
me that any program / programming system will develop into a
monster of complexity over its lifetime (look at SPICE or Matlab,
or gcc, or Linux ...). One should fight that, but not every battle
needs to be or can be won. What helps is not to let lots of
developers work on it, and luckily for a Forth you don't
need many.

-marcel

[Rod Pemberton]

On Fri, 21 Aug 2015 00:28:19 -0400, <hughag...@gmail.com> wrote:

> An on-board Forth system can't generate machine-code because
> it can't write into program memory --- this is a common limitation
> in Harvard Architecture systems ---

True.

> it is unlikely that Marcel Hendrix knows what Harvard Architecture
> is, or he wouldn't have stated that Forth has to be interactive.

False.

There is no correlation between an "on-board Forth system" with
a "Harvard Architecture" and Forth being interactive. Even in
an embedded system, of Harvard or von Neumann design, with no
writable memory, Forth can still be interactive. For an interpreted
Forth, you can enter Forth words with "interpretation semantics" and
they will (or should) execute. They were already compiled and stored
in non-writable memory. You just can't add any new definitions to a
dictionary or use PAD, etc, without writable memory. The two stacks
are obviously being excluded as being writable memory here, even though
they usually are.


Rod Pemberton

--
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[Rod Pemberton]

On Fri, 21 Aug 2015 04:46:55 -0400, <m.a.m....@tue.nl> wrote:

> I am not a big KISS proponent, but lately it has become clear to
> me that any program / programming system will develop into a
> monster of complexity over its lifetime (look at SPICE or Matlab,
> or gcc, or Linux ...). One should fight that, but not every battle
> needs to be or can be won.

I usually keep C programs small and dedicated for just this reason.

We've all seen the massively bloated Linux utilities, which do way
too much, have way too many parameters. Yet, you can't use that one
utility to get the job done. You still need two more utilities, each
of which do basically the same thing as the first, but they have one
additional feature the others don't have, which is needed to get the
job done.

e.g.,

'ps -e' and 'kill' versus 'pkill'
'du' versus 'df'
'find' versus 'ls'
'nc' versus 'nmap','telnet','ping'

Why are there three web browsers installed in Linux?

[Jan Coombs <Jan-54 >]

On Fri, 21 Aug 2015 07:11:27 -0400
"Rod Pemberton" <b...@fasdfrewar.cdm> wrote:

> On Fri, 21 Aug 2015 00:28:19 -0400, <hughag...@gmail.com>
> wrote:
>
> > An on-board Forth system can't generate machine-code because
> > it can't write into program memory --- this is a common
> > limitation in Harvard Architecture systems ---
>
> True.

Hate to haggle, but...

I have CamelForth for test purposes on Harvard Architecture
systems. (flash 8051 boards [1]). The compiler works, and I have
no reason to think that an assembler would not.

Jan Coombs
--
[1] https://en.wikipedia.org/wiki/Intel_MCS-51
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[hughag...@gmail.com]

The 8051 is not Harvard Architecture.

[Raimond Dragomir]

A strict Harvard machine cannot read program memory as constant data. All data in program memory must be literals. Any other data (constant or not) should be on a separate bus. The program and data buses are hardware distinct.
I don't know even one modern cpu (since 1990) that has this architecture. All modern Hardward machines are either "modified" or "relaxed". There are cases with separate program and data spaces on the same physical bus (or not) (program space read-only - but readable) or cases with (internal) separate buses for instruction and data but acting in an unified address space (cortex-m3/m4) backed with complex switched matrix buses.

8051 is a relaxed Hardward because it has readable program memory as data, separated from the data memories. It doesn't have however separate buses for program and data.

[Matthias Trute]

> I don't know even one modern cpu (since 1990) that has this architecture. All > modern Hardward machines are either "modified" or "relaxed". There are cases > with separate program and data spaces on the same physical bus (or not)
> (program space read-only - but readable) or cases with (internal) separate
> buses for instruction and data but acting in an unified address space (cortex-
> m3/m4) backed with complex switched matrix buses.

The Atmel AVR8 Atmegas have three distinct address spaces: RAM, Flash and
EEPROM. Only RAM is directly accessible via load/store operations, the other
memories need special actions, for flash even a special instruction (LPM/SPM).
That comes pretty close to a pure Harvard. They were designed in the 90ties and
are still in use.

Matthias

[dunno]

"Rod Pemberton" <b...@fasdfrewar.cdm> wrote:
> On Fri, 21 Aug 2015 04:46:55 -0400, <m.a.m....@tue.nl> wrote:
>
>> I am not a big KISS proponent, but lately it has become clear to
>> me that any program / programming system will develop into a
>> monster of complexity over its lifetime (look at SPICE or Matlab,
>> or gcc, or Linux ...). One should fight that, but not every battle
>> needs to be or can be won.
>
> I usually keep C programs small and dedicated for just this reason.
>
> We've all seen the massively bloated Linux utilities, which do way
> too much, have way too many parameters. Yet, you can't use that one
> utility to get the job done. You still need two more utilities, each
> of which do basically the same thing as the first, but they have one
> additional feature the others don't have, which is needed to get the
> job done.
>
> e.g.,
>
> 'ps -e' and 'kill' versus 'pkill'
> 'du' versus 'df'
> 'find' versus 'ls'
> 'nc' versus 'nmap','telnet','ping'

Agreed.

> Why are there three web browsers installed in Linux?

Web browsers are different story (mostly for historical reasons and because
they have an UI). While I'm totally agree with you on other utilities, I
think browsers are not a good example of the problem, same as text editors,
graphic editors, or music composers.

> Rod Pemberton



--
dunno