On 15/09/2021 05:39, Paul Rubin wrote:
>
> On an 8-bit target with 16-bit Forth cells, I think I really have to use
> bytecode, since otherwise even simple arithmetic or stack operations
> take multiple instructions. Traditional bytecode VM's for Forth are
> simple stack machines with primitives for common Forth words like DUP,
> SWAP, etc. But if the VM is a compiler target, it may be better to
> design it in conjunction with the compiler. For example, maybe it
> should have registers that the compiler can use.
>
> I'm surprised this type of question has not gotten more attention in the
> Forth world, given the long association between Forth and memory starved
> targets.

I vaguely recall something called assembler. What programmers used
before they decided they needed to be coddled.

dxforth <dxforth@gmail.com> writes:
> I vaguely recall something called assembler. What programmers used
> before they decided they needed to be coddled.

I don't see what you're getting at here. VM bytecode doing 16 bit
operations should be much denser than 8-bit assembly code using multiple
instructions for the same operations.

On 15/09/2021 09:23, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> I vaguely recall something called assembler. What programmers used
>> before they decided they needed to be coddled.
>
> I don't see what you're getting at here.

???

> VM bytecode doing 16 bit
> operations should be much denser than 8-bit assembly code using multiple
> instructions for the same operations.

There's a consideration called performance. Assuming small mcu's have
become fast enough to consider bytecode, it won't be everyone. Then
there's time - getting a project done before it's obsolete. I should
be the last to talk - taking 30 years to do what I initially gave
myself three. There are folk here who have never gone past the
compiler stage - and likely never will.

dxforth <dxforth@gmail.com> writes:
> There's a consideration called performance. Assuming small mcu's have
> become fast enough to consider bytecode, it won't be everyone.

Sure, there will be places where the bytecode is too slow, and the fix
will be assembler or C. That's traditional with Forth. Meanwhile the
current MCU with bytecode is probably about as fast as vintage 8 bitters
with ITC, so it evens out.

> Then there's time - getting a project done before it's obsolete.

Yeah, writing a fancy compiler of the kind we're now discussing is way
out of scope for the immediate application, but it's still interesting.
Lots of people have implemented Forth in many ways. It's surprising
that this particular approach hasn't been used much. That's part of
what makes it interesting.

On 15/09/2021 11:29, Paul Rubin wrote:
>
> Lots of people have implemented Forth in many ways. It's surprising
> that this particular approach hasn't been used much.

Early on there was the 1802 and CHIP-8. These may have been seen
as too much of a toy for Forth to employ. The early FD editors
made it clear in reviews that Forth was 'BLOCKS and ITC' and
anything else 'wasn't the real deal'.

dxforth <dxforth@gmail.com> writes:
>I vaguely recall something called assembler. What programmers used
>before they decided they needed to be coddled.

Assembly language is for wimps. Real men program in machine language.
And not machine language on a sissy architecture that gives good
performance for consecutive instructions, but on the good old hardware
where, for best performance, the next instruction to be executed
resides at some distance on the drum.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Bytecode didn't come into consideration because of the
>resulting slowdown, and the relative abundance of memory on those
>targets.

The question is why byte code was not used more on the severely
memory-restricted systems in the early days of Forth.

Probably the most important reason is that byte code pretty much
forces you to use primitive-centric code, which is larger for
non-primitives. E.g., with 16-bit addresses a call to the following
type of word takes the following number of bytes:

BC ITC
primitive 1 2
colon definition 3 2
variable 3 2
constant 3 2
DOES>-defined 3 2

Primitive-centric code also requires that you use an intelligent
COMPILE, rather than simply using ",".

On a very memory-limited system where you do not have room for more
than 256 words, you can work with something that's like ITC in
allowing to call a colon definition without providing an extra
address, but that takes only one byte for every called word. This
requires reorganizing the code fields into a 512-byte table, which
requires some changes to the code field.

You can extend this to 256+n*255 words by having n byte codes for
extension tables, making the organization even more complex.

>I'm surprised this type of question has not gotten more attention in the
>Forth world, given the long association between Forth and memory starved
>targets.

I have seen many such discussions, typically under the name
token-threaded code rather than byte-code.

It may not have been discussed much in the last years, though.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 12 Sep 2021 at 13:27:52 CEST, "Anton Ertl" <Anton Ertl> wrote:
>
> IIRC Stephen Pelc wrote that what I called reconciling recently is
> very complicated. I think you can make it less complicated by
> modeling it as first moving everything to a temporary location, and
> then moving everything to the target location, eliminating moves if
> liveness permits, and finally emitting the remaining moves. There are
> more optimal ways, and I can look them up if you want, but they are
> not simpler.

We call it the canonical stack shuffle, where you return the current
state of the model stack to the canonical state, e.g. TOS in register
and the rest in deep stack.

The algorithm that we use took a few years to perfect, and I'sure that
we could do better. The really tricky part is what to do when you run
out of resources (registers), usually push something on the return
stack, but what to do when that needs a spare register?

VFX includes the source code.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

In article <shro6k$not$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>On 15/09/2021 11:29, Paul Rubin wrote:
>>
>> Lots of people have implemented Forth in many ways. It's surprising
>> that this particular approach hasn't been used much.
>
>Early on there was the 1802 and CHIP-8. These may have been seen
>as too much of a toy for Forth to employ. The early FD editors
>made it clear in reviews that Forth was 'BLOCKS and ITC' and
>anything else 'wasn't the real deal'.

1802 was not a toy by any stretch. It was used in spacecraft and
it was a good target for Forth. It was one of the FIG
implementations. (got the source here.)

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

On 17/09/2021 06:57, albert wrote:
> In article <shro6k$not$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>>On 15/09/2021 11:29, Paul Rubin wrote:
>>>
>>> Lots of people have implemented Forth in many ways. It's surprising
>>> that this particular approach hasn't been used much.
>>
>>Early on there was the 1802 and CHIP-8. These may have been seen
>>as too much of a toy for Forth to employ. The early FD editors
>>made it clear in reviews that Forth was 'BLOCKS and ITC' and
>>anything else 'wasn't the real deal'.
>
> 1802 was not a toy by any stretch. It was used in spacecraft and
> it was a good target for Forth. It was one of the FIG
> implementations. (got the source here.)

The reference was to compact methods of program execution. The 1802
had a few niche applications but is mostly known for being the first
CMOS cpu.

On Wednesday, September 15, 2021 at 1:46:37 AM UTC-5, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> >I vaguely recall something called assembler. What programmers used
> >before they decided they needed to be coddled.
> Assembly language is for wimps. Real men program in machine language.
> And not machine language on a sissy architecture that gives good
> performance for consecutive instructions, but on the good old hardware
> where, for best performance, the next instruction to be executed
> resides at some distance on the drum.
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: http://www.forth200x.org/forth200x.html
> EuroForth 2021: https://euro.theforth.net/2021

Real men hand assemble and program in column binary
Rumor had that Cray did this at one point on the 6600 using a 12-button manual keypunch.

James Brakefield schrieb am Freitag, 17. September 2021 um 03:31:45 UTC+2:
> On Wednesday, September 15, 2021 at 1:46:37 AM UTC-5, Anton Ertl wrote:
> > dxforth <dxf...@gmail.com> writes:
> > >I vaguely recall something called assembler. What programmers used
> > >before they decided they needed to be coddled.
> > Assembly language is for wimps. Real men program in machine language.
> > And not machine language on a sissy architecture that gives good
> > performance for consecutive instructions, but on the good old hardware
> > where, for best performance, the next instruction to be executed
> > resides at some distance on the drum.
> > - anton
> > --
> > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> > New standard: http://www.forth200x.org/forth200x.html
> > EuroForth 2021: https://euro.theforth.net/2021
> Real men hand assemble and program in column binary
> Rumor had that Cray did this at one point on the 6600 using a 12-button manual keypunch.

Huh ... so I also had been a real man, back then when I punched hex codes into
a Sym-1 board. :o)

On Friday, September 17, 2021 at 8:13:09 AM UTC+2, minf...@arcor.de wrote:
[..]
> Huh ... so I also had been a real man, back then when I punched hex codes into
> a Sym-1 board. :o)

At the university they had us toggle in an 8008 program using a row of 8 switches (i.e. binary).
The instructors probably thought they did us a favor, but it went far over our heads.

-marcel

Marcel Hendrix schrieb am Freitag, 17. September 2021 um 21:51:44 UTC+2:
> On Friday, September 17, 2021 at 8:13:09 AM UTC+2, minf...@arcor.de wrote:
> [..]
> > Huh ... so I also had been a real man, back then when I punched hex codes into
> > a Sym-1 board. :o)
> At the university they had us toggle in an 8008 program using a row of 8 switches (i.e. binary).
> The instructors probably thought they did us a favor, but it went far over our heads.
>

.... that had been good enough for youngsters ... we sported with Hollerith cards ... :o)

On Tuesday, September 14, 2021 at 11:46:37 PM UTC-7, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> >I vaguely recall something called assembler. What programmers used
> >before they decided they needed to be coddled.
> Assembly language is for wimps. Real men program in machine language.
> And not machine language on a sissy architecture that gives good
> performance for consecutive instructions, but on the good old hardware
> where, for best performance, the next instruction to be executed
> resides at some distance on the drum.

I wrote MFX for the MiniForth processor in 1994 --- that was a difficult assembly language.
Nobody has ever done anything comparable.

Anton Ertl is not qualified to criticize my code.
He is an idiot --- at the same level as DXforth --- babbling nonsense such as seen above.

All of the Forth-200x committee members are idiots ---
Peter Knaggs failed badly at implementing a linked-list, but declared himself the world expert.
Stephen Pelc failed badly at implementing a string-stack, but declared himself the world expert.
Anton Ertl and Bernd Paysan failed badly at inventing rquotations; they have only :NONAME still.
Stephen Pelc failed badly at implementing SYNONYM in ANS-Forth,
etc., etc. ...