none albert schrieb am Mittwoch, 9. November 2022 um 14:59:51 UTC+1:
> In article <2022Nov...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> <SNIP>
> >
> >[1] FAXPY ( ra f-x nstridex f-y nstridey ucount -- ) multiplies ra
> >with f-x and adds the result to f-y, where f-x and f-y are arrays and
> >ucount elements are accessed with strides nstridex and nstridey,
> >respectively. This is the Forth float variant of BLAS's SAXPY,
> >DAXPY, CAXPY and ZAXPY routines.
> This can be done with nested loops: I and J
> Rejecting local variables and then using I and J
> (actually similar to adding a special A registers.)
> that are a sort of register variables with a special purpose?
> I have to admit that feels like cheating.
> It makes the case for locals stronger, but local
> TO-VALUEs have the same cludgy feeling as I and J.
>

Any 'reasonable' implementation would use CPU vector registers
when available. So any argumentation based on single scalar
stack or local elements (these are the only ones treated in the
Forth standard) barely counts.

The BLAS interfaced is explained here:
https://www.ibm.com/docs/en/essl/6.2?topic=vss-saxpy-daxpy-caxpy-zaxpy-multiply-vector-by-scalar-add-vector-store-in-vector

With my non-standard array/buffer/matrix locals I could define this in
a one-liner:
: DAXPY { f: ra M: X Y == Y } ra X mscale Y m+ ;
\ mscale : vectorized scalar multiply
\ m+ : vectorized add
Alternatively: looping over all elements and applying fused multiply-add
function FMA; there are many ways to Rome.

So limiting oneself to what the Standard or Mr. Moore said or not said
is close to mental self-multilation IMO.

dxforth <dxforth@gmail.com> writes:
>On 9/11/2022 8:33 pm, Anton Ertl wrote:
>> ...
>> One reason for having locals was for implementing words that
>> have so many items in constant use that a pure-stack variant is
>> cumbersome.
>
>Both are complicated solutions AFAICS. One has lots of stack
>operations and the other has lots of variables. They're as bad
>as each other. Were folks to see that, they might look for
>another solution.

What would be your solution? Elizabeth Rather suggested assembler,
and I expect that's what Chuck Moore used before doing his own
hardware. On i21 he then added A and enhanced R.

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

albert@cherry.(none) (albert) writes:
>In article <2022Nov9.103332@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>
>>[1] FAXPY ( ra f-x nstridex f-y nstridey ucount -- ) multiplies ra
>>with f-x and adds the result to f-y, where f-x and f-y are arrays and
>>ucount elements are accessed with strides nstridex and nstridey,
>>respectively. This is the Forth float variant of BLAS's SAXPY,
>>DAXPY, CAXPY and ZAXPY routines.
>
>This can be done with nested loops: I and J

Please demonstrate. I see only one loop.

>Rejecting local variables and then using I and J
>(actually similar to adding a special A registers.)
>that are a sort of register variables with a special purpose?
>I have to admit that feels like cheating.

Unlike the A register, the loop parameters are stack-managed.

But note that machine Forth (and, I think, colorForth) has no
?DO...LOOP.

So let's do a few Forth variants of AXPY (the integer sibling of
FAXPY, probably not needed by anyone, but similar to what we would see
for FAXPY with 1-cell floats; all untested):

\ Gforth with locals
: axpy1 {: na a-x nstridex a-y nstridey ucount -- :}
a-x a-y ucount 0 ?do {: a-x1 a-y1 :}
a-x1 @ na * a-y1 +!
a-x1 nstridex + a-y1 nstridey + loop
2drop ;

\ Standard Forth without locals
: axpy2 ( na a-x nstridex a-y nstridey ucount -- )
>r >r rot r> swap rot r> 0 do ( na nstridex nstridey a-x1 a-y1 )
over @ 5 pick * over +!
2over rot + >r + r> loop
2drop 2drop drop ;

\ Standard Forth without locals, loop, and with tail recursion (machine-Forth-like)
: axpy3 ( na a-x nstridex a-y nstridey ucount -- )
dup 0> if
4 pick @ 6 pick * 3 pick +!
>r dup >r + >r dup >r + r> r> r> r> 1- recurse
then ;

Ok, writing AXPY2 and AXPY3 was not too hard, but reading is a
different issue.

I guess that Chuck Moore would consider the stride parameters to be
too general and would eliminate them; and that's usually also a good
idea on current general-purpose architectures: try to arrange your
data so that the x and y array elements you access are contiguous,
possibly by copying them around first (which pays off if you then
access the array more than once); and in Forth splitting axpy into
rearrangement, computation, and rearrangement (with the rearrangement
steps hopefully unnecessary) would reduce the number of needed items
accessed in each loop.

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

anti...@math.uni.wroc.pl schrieb am Mittwoch, 9. November 2022 um 18:07:31 UTC+1:
> Paul Rubin <no.e...@nospam.invalid> wrote:
> > dxforth <dxf...@gmail.com> writes:
> > > My point was it went from 4 locals to 6 for reasons of style. It may be
> > > C-style to expend resources this way (I wouldn't know)
> >
> > In C these days, the extra locals wouldn't expend any resources in most
> > cases, since the compiler would optimize them away.
> >
> > > but I doubt it's Moore's.
> >
> > This I don't know. A traditional thread Forth interpreter (Moore's
> > invention) is probably 10x slower than CODE doing the same thing, but
> > Moore only used CODE when he had to. If 9x extra compute cycles is
> > fine, why are a few memory cells a big deal?
>
> I think origin of Forth explain this. In his book "PROGRAMMING
> A PROBLEM-ORIENTED-LANGUAGE" Moore write about "programs with
> input". In more clear language he wanted to have interactive
> command processor. For processing user commands even minis
> from 1970 and early micros have enough speed that you can lose
> some (not too much, but factor of 10 is acceptable). OTOH
> some minis were quite small. More writes about 4kB RAM, but
> I think that he could put only very stripped down system on
> such machine, full system that he outlines probably need
> something between 8 and 16 kB RAM (FIG Forth executable is
> slightly bigger than 6kB, but needs extra memory for block
> buffers and for words defined in Forth).

To get a feeling (nostalgic for us oldtimers) for the available "interactive
command processors" of that time, watch:

https://www.youtube.com/watch?v=_DTpQ4Kk2wA

It is not about Forth but about APL, a very interesting matrix processing
language. But those teletype terminals had been high luxury. We poor
students had to shuffle shoe boxes full with stacks of punch cards around... ;o)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Unix as OS, and of Forth as a programming language. Both had no
> memory protection (Unix acquired virtual memory only with 3BSD in
> 1979), both acquired multi-tasking (and multi-user) pretty soon.

Unix had memory protection on the PDP-11, long before it got virtual
memory. The PDP-11/40 and friends had memory segments with protection
registers, so processes couldn't clobber each other or reach into the
kernel. With earlier models (11/20, PDP-7 etc.) you could crash a whole
timesharing system by having a pointer bug in your program. I thought
that Unix had multi-tasking from the beginning, but am not sure.

I'd be interested to know if Forth used memory protection on machines
that had it in that era.

"minf...@arcor.de" <minforth@arcor.de> writes:
>none albert schrieb am Mittwoch, 9. November 2022 um 14:59:51 UTC+1:
>> In article <2022Nov...@mips.complang.tuwien.ac.at>,
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> <SNIP>
>> >
>> >[1] FAXPY ( ra f-x nstridex f-y nstridey ucount -- ) multiplies ra
>> >with f-x and adds the result to f-y, where f-x and f-y are arrays and
>> >ucount elements are accessed with strides nstridex and nstridey,
>> >respectively. This is the Forth float variant of BLAS's SAXPY,
>> >DAXPY, CAXPY and ZAXPY routines.
....
>Any 'reasonable' implementation would use CPU vector registers
>when available. So any argumentation based on single scalar
>stack or local elements (these are the only ones treated in the
>Forth standard) barely counts.

The point of the example is not how to get a fast FAXPY on a
mainstream CPU, but how to deal with the many values that are all used
in the loop.

>With my non-standard array/buffer/matrix locals I could define this in
>a one-liner:
>: DAXPY { f: ra M: X Y == Y } ra X mscale Y m+ ;
>\ mscale : vectorized scalar multiply
>\ m+ : vectorized add

The question is: How have you implemented MSCALE and M+? If it's not
in Forth, this indicates that Forth is not up to the task, which one
may consider to be ok, or which one may consider to be a challenge to
make Forth more versatile.

And wrt 1xForth, how would one implement FAXPY or AXPY on machine
Forth for i21?

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

Anton Ertl schrieb am Mittwoch, 9. November 2022 um 23:09:30 UTC+1:
> >With my non-standard array/buffer/matrix locals I could define this in
> >a one-liner:
> >: DAXPY { f: ra M: X Y == Y } ra X mscale Y m+ ;
> >\ mscale : vectorized scalar multiply
> >\ m+ : vectorized add
> The question is: How have you implemented MSCALE and M+? If it's not
> in Forth, this indicates that Forth is not up to the task, which one
> may consider to be ok, or which one may consider to be a challenge to
> make Forth more versatile.

Those exemplary vector words could be implemented in slow high-level Forth
but are actually primitives using AVX operators.

But this is besides the point. F.ex. in a scalar imperative language one has to add
matrices in a nested loop (here in C form, Forth would be similar):
for (i = 0; i < n; i++)
for (j = 0; j < n; j++)
a[i][j] += b[i][j];
In a language that supports arrays one would just write A = A + B. Nothing
spectacular in many high-level languages.

The challenge had been how to bring this concept into Forth, so that the
code remains embeddable without having to pull in external algebra libraries.

Solution elements:
1) a matrix stack (similar to a dynamic string stack, nothing new)
matrix elements are just fat pointers to the "real" arrays/vectors in heap
2) global matrix values (they have a name)
3) matrix locals (they have names too)
4) some elementary words to operate with a.m. matrices (elementary linear
algebra, some I/O)

From a programmers perspective the most important element of these became
matrix locals. Not because they replaced equivalent matrix stack juggling,
but because they have NAMES!

Algorithms prototyped in MATLAB/SIMULINK can now be "transported"
literally into Forth without reengineering. The syntax only looks like a
postfix Matlab formulation. Finetuning follows in Forth.

I am not selling anything here. But the discussion in this thread whether locals
are evil practice, and that real programmers instead factor longish stack ops
like hell into small digestible chunks is complete BS.

Why? Because locals are means towards higher abstraction and solution orientation!
See my example.

Torturing a stack machine is hidden sadism. ;o)

On 10/11/2022 4:22 am, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> On 9/11/2022 8:33 pm, Anton Ertl wrote:
>>> ...
>>> One reason for having locals was for implementing words that
>>> have so many items in constant use that a pure-stack variant is
>>> cumbersome.
>>
>> Both are complicated solutions AFAICS. One has lots of stack
>> operations and the other has lots of variables. They're as bad
>> as each other. Were folks to see that, they might look for
>> another solution.
>
> What would be your solution? Elizabeth Rather suggested assembler,
> and I expect that's what Chuck Moore used before doing his own
> hardware. On i21 he then added A and enhanced R.

Firstly I don't see more variables and variable operations as a
solution. Apparently many do. When 99% of the world of the world's
languages is using variables both to solve its problems and craft
its functions, it's perhaps no surprise forthers will also come to
see them as a solution too - such is the conscious (and unconscious)
bias.

For cherry-picked worst-case examples used to justify locals, if
hand-coded assembler does a better job than either stack or locals,
what's wrong with that?

On 10/11/2022 10:22 am, minf...@arcor.de wrote:
> ...
> Torturing a stack machine is hidden sadism. ;o)

Don't do it then. Force-feeding stack machines with locals to produce
a C result, is akin to force-feeding geese to produce “foie gras” :)

On Thursday, November 10, 2022 at 1:27:32 AM UTC+1, dxforth wrote:
[..]
> For cherry-picked worst-case examples used to justify locals, if
> hand-coded assembler does a better job than either stack or locals,
> what's wrong with that?

You need *very* "complicated" matrix-math to have a simple micro do
embedded control of the switched-mode power supplies that are
literally everywhere. One can set about implementing everything in
Forth from scratch, but it will take a single person a decade to get
a debugged library that is good enough to start experimenting
with the real problems at hand. (I am talking from experience).

Now some people may want to take this route, others may prefer
to start with the real problem and work back to the minimum
that is needed in their Forth to get results. In such a case one
wants minf's approach.

In Forth, the problem is that the libraries developed with such
approaches work only on certain machines for certain persons,
and that the certain persons have absolutely no problems with
that.

-marcel

In article <676b958b-5bce-46e0-9dab-bbc9599af1edn@googlegroups.com>,
<SNIP>
>The challenge had been how to bring this concept into Forth, so that the
>code remains embeddable without having to pull in external algebra libraries.
>
>Solution elements:
>1) a matrix stack (similar to a dynamic string stack, nothing new)
> matrix elements are just fat pointers to the "real" arrays/vectors in heap
>2) global matrix values (they have a name)
>3) matrix locals (they have names too)
>4) some elementary words to operate with a.m. matrices (elementary linear
> algebra, some I/O)

Given that you rarely needs generate matrix in a recursive fashion,
isolation by wordlist is a feasible solution.
Heap beats stack. If I wanted to program in this vein, I surely
wanted to ALLOCATE matrices.
So in fact 2 and 3 require no special measures in a Forth.

>
>From a programmers perspective the most important element of these became
>matrix locals. Not because they replaced equivalent matrix stack juggling,
>but because they have NAMES!

Right.

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 10/11/2022 5:18 pm, Marcel Hendrix wrote:
> On Thursday, November 10, 2022 at 1:27:32 AM UTC+1, dxforth wrote:
> [..]
>> For cherry-picked worst-case examples used to justify locals, if
>> hand-coded assembler does a better job than either stack or locals,
>> what's wrong with that?
>
> You need *very* "complicated" matrix-math to have a simple micro do
> embedded control of the switched-mode power supplies that are
> literally everywhere. One can set about implementing everything in
> Forth from scratch, but it will take a single person a decade to get
> a debugged library that is good enough to start experimenting
> with the real problems at hand. (I am talking from experience).

I'm not aware Moore promised ready-made solutions, or said programmers
would have the capacity to do it themselves. What Standard Forth
promised, I leave to its administration to elucidate.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> if [C.M.'s] old (1971-1978) Forth had been incomprehensible, Forth
>> would not have seen the takeup it has seen. Dean Sanderson would have
>> been unable to design microForth, Seltzer and Ragsdale would have been
>> unable to do fig-Forth, and so on... And I think ... [C.M.]
>> considers the concepts more valuable than the code.
>
>Did Sanderson etc. do their implementations by studying C.M.'s source
>code, or did they simply reimplement its behaviour?

<https://www.forth.com/resources/forth-programming-language/#233_Influences>:
|Although Sanderson worked closely with Moore and shared most of his
|basic philosophies, differences in style and approach were
|inevitable. But the major new influence came from the broader customer
|base that resulted from the wider marketing of microFORTH. It was
|customer pressure that brought back multiprogramming, and this larger
|customer base also caused standards groups to form.

<https://www.forth.com/resources/forth-programming-language/#31_The_Forth_Interest_Group>:
|Ragsdale then looked for someone with the knowledge of microFORTH and
|intimate familiarity with the 6502 to port a version of microFORTH to
|the 6502. He found Maj. Robert Selzer, who had used microFORTH for an
|AMI 6800 development system on an Army project and was privately
|developing a standalone editor/assembler/linker package for the
|6502. Selzer wrote a 6502 Forth assembler, and used the Army’s
|microFORTH metacompiler to target compile the first 6502 stand-alone
|Forth for the Jolt single board computer.
| |Selzer and Ragsdale subsequently made substantial modifications and
|improvements to the model

That's all I know about that topic.

>What I found hard to understand
>was the actual Forth code written by C.M. that I looked at. I also
>found fig-Forth to be hard to understand, if that matters. I'm
>unfamiliar with microForth.

Can you give examples? Both figForth and cmForth have been documented
extensively by C.H. Ting ("System Guide to fig-Forth" and "Footsteps
in an Empty Valley"), but I found I could understand
<https://github.com/ForthHub/cmFORTH/blob/combined/cmforth.fth> for
the most part with just the code and the shadow screens. I have not
looked at fig-Forth for a long time, but looking at it again, it lacks
stack-effect comments, but with knowledge of the stack effects and
some of the principles behind fig-Forth most of the code is quite
understandable to me.

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

"minf...@arcor.de" <minforth@arcor.de> writes:
>Anton Ertl schrieb am Mittwoch, 9. November 2022 um 23:09:30 UTC+1:
>> >With my non-standard array/buffer/matrix locals I could define this in
>> >a one-liner:
>> >: DAXPY { f: ra M: X Y == Y } ra X mscale Y m+ ;
>> >\ mscale : vectorized scalar multiply
>> >\ m+ : vectorized add
>> The question is: How have you implemented MSCALE and M+? If it's not
>> in Forth, this indicates that Forth is not up to the task, which one
>> may consider to be ok, or which one may consider to be a challenge to
>> make Forth more versatile.
>
>Those exemplary vector words could be implemented in slow high-level Forth
>but are actually primitives using AVX operators.
....
>Solution elements:
>1) a matrix stack (similar to a dynamic string stack, nothing new)
> matrix elements are just fat pointers to the "real" arrays/vectors in heap
>2) global matrix values (they have a name)
>3) matrix locals (they have names too)
>4) some elementary words to operate with a.m. matrices (elementary linear
> algebra, some I/O)

That's somewhat similar to my vector work (see references below and my
incomplete implementation <https://github.com/AntonErtl/vectors>),
except that there are no vector locals (you could have them by using
V! on a cell-sized local buffer), and I am not sure whether your
global matrix corresponds to what I do by V!ing to a variable.

My implementation is based on generating GNU C code for the various
words from Forth, compiling this code and dynamically linking the
result; this code uses the GNU C extension
<https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/using-vector-instructions-through-built-in-functions.html>.
There is also a slow path in standard Forth.

I find this state of affairs unsatisfying. I think that we should be
able to write such code in Forth and get competetive performance.

@InProceedings{ertl17,
author = {M. Anton Ertl},
title = {{SIMD} and Vectors},
crossref = {euroforth17},
pages = {25--36},
url = {http://www.euroforth.org/ef17/papers/ertl.pdf},
video = {https://wiki.forth-ev.de/lib/exe/fetch.php/events:ef2017:simd-vectors.mp4},
OPTnote = {refereed},
abstract = {Many programs have parts with significant data
parallelism, and many CPUs provide SIMD instructions
for processing data-parallel parts faster. The weak
link in this chain is the programming language. We
propose a vector wordset so that Forth programmers
can make use of SIMD instructions to speed up the
data-parallel parts of their applications. The
vector wordset uses a separate vector stack
containing opaque vectors with run-time determined
length. Preliminary results using one benchmark
show a factor~8 speedup of a simple vector
implementation over scalar Gforth code, a smaller
(factor 1.8) speedup over scalar VFX code; another
factor of 3 is possible on this benchmark with a
more sophisticated implementation. However, vectors
have an overhead; this overhead is amortized in this
benchmark at vector lengths between 3 and 250
(depending on which variants we compare).}
}

@Proceedings{euroforth17,
title = {33rd EuroForth Conference},
booktitle = {33rd EuroForth Conference},
year = {2017},
key = {EuroForth'17},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef17/papers/proceedings.pdf}
}

@InProceedings{ertl18manlang,
author = {M. Anton Ertl},
title = {Software Vector Chaining},
booktitle = {15th International Conference on Managed Languages &
Runtimes (Manlang'18)},
year = {2018},
pages = {Article-18},
url = {http://www.complang.tuwien.ac.at/papers/ertl18manlang.pdf},
doi = {10.1145/3237009.3237021},
abstract = {Providing vectors of run-time determined length as
opaque value types is a good interface between the
machine-level SIMD instructions and portable
application-oriented programming languages.
Implementing vector operations requires a loop that
breaks the vector into SIMD-register-sized chunks.
A compiler can fuse the loops of several vector
operations together. However, during normal
compilation this is only easy if no other control
structures are involved. This paper explores an
alternative: collect a trace of vector operations at
run-time (following the program control flow during
this collecting step), and then perform the combined
vector loop. This arrangement has a certain
run-time overhead, but its implementation is simpler
and can happen independently, in a library.
Preliminary performance results indicate that the
overhead makes this approach beneficial only for
long vectors ($>1$KB). For shorter vectors, unfused
loops should be used in a library setting.
Fortunately, this choice can be made at run time,
individually for each vector operation.}
}

@InProceedings{ertl18chaining,
author = {M. Anton Ertl},
title = {Software Vector Chaining},
crossref = {euroforth18},
pages = {54-55},
url = {http://www.euroforth.org/ef18/papers/ertl-chaining.pdf},
url-slides = {http://www.euroforth.org/ef18/papers/ertl-chaining-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2018:vectors},
OPTnote = {presentation slides, paper published at Manlang'18},
abstract = {Providing vectors of run-time determined length as
opaque value types is a good interface between the
machine-level SIMD instructions and portable
application-oriented programming languages.
Implementing vector operations requires a loop that
breaks the vector into SIMD-register-sized chunks.
A compiler can fuse the loops of several vector
operations together. However, during normal
compilation this is only easy if no other control
structures are involved. This paper explores an
alternative: collect a trace of vector operations at
run-time (following the program control flow during
this collecting step), and then perform the combined
vector loop. This arrangement has a certain
run-time overhead, but its implementation is simpler
and can happen independently, in a library.
Preliminary performance results indicate that the
overhead makes this approach beneficial only for
long vectors ($>1$KB). For shorter vectors, unfused
loops should be used in a library setting.
Fortunately, this choice can be made at run time,
individually for each vector operation.}
}

@Proceedings{euroforth18,
title = {34th EuroForth Conference},
booktitle = {34th EuroForth Conference},
year = {2018},
key = {EuroForth'18},
url = {http://www.euroforth.org/ef18/papers/proceedings.pdf}
}

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

dxforth <dxforth@gmail.com> writes:
>On 10/11/2022 4:22 am, Anton Ertl wrote:
>> What would be your solution? Elizabeth Rather suggested assembler,
>> and I expect that's what Chuck Moore used before doing his own
>> hardware. On i21 he then added A and enhanced R.
>
>Firstly I don't see more variables and variable operations as a
>solution. Apparently many do. When 99% of the world of the world's
>languages is using variables both to solve its problems and craft
>its functions, it's perhaps no surprise forthers will also come to
>see them as a solution too - such is the conscious (and unconscious)
>bias.

This does not tell me how you would solve the problem.

>For cherry-picked worst-case examples used to justify locals, if
>hand-coded assembler does a better job than either stack or locals,
>what's wrong with that?

It's not Forth. Also, people who reject locals usually claim that a
good Forth programmer can do without them, and typically there are
also claims made that factoring is helpful.

Concerning "cherry-picked example", one example is enough to refute a
general claim.

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

dxforth <dxforth@gmail.com> writes:
> For cherry-picked worst-case examples used to justify locals, if
> hand-coded assembler does a better job than either stack or locals,
> what's wrong with that?

The worst-case examples are where using pure stack ops causes pain so
excruciating that it stops your work, unless some other approach is
found.

But there are also more numerous non-worst-case examples, where the
stack ops cause only moderate pain that doesn't completely stop the
work. It only distracts from the work and slows it down. This pain is
endurable, but I still don't understand why inviting it on purpose is
not masochism.

Anton Ertl schrieb am Donnerstag, 10. November 2022 um 19:35:00 UTC+1:
> That's somewhat similar to my vector work (see references below and my
> incomplete implementation <https://github.com/AntonErtl/vectors>),
> except that there are no vector locals (you could have them by using
> V! on a cell-sized local buffer), and I am not sure whether your
> global matrix corresponds to what I do by V!ing to a variable.
>
> My implementation is based on generating GNU C code for the various
> words from Forth, compiling this code and dynamically linking the
> result; this code uses the GNU C extension
> <https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/using-vector-instructions-through-built-in-functions.html>.
> There is also a slow path in standard Forth.
>
> I find this state of affairs unsatisfying. I think that we should be
> able to write such code in Forth and get competetive performance.

AFAIU your project it has a more generic approach to map a rather
comprehensive range of SIMD instructions to Forth words that operate
on a stack of vectors with different data types.

My system is much narrower ie. application-oriented. Coding of vector-numeric primitives
is somewhat like described here:
https://www.codeproject.com/Articles/874396/Crunching-Numbers-with-AVX-and-AVX
Vectors in my applications are mostly time series of measured/calculated data.
So the requirements are more special/narrower than generic.

Matrix/vector values and locals occupy just 2 cells: heap memory address plus encoded
data info. Matrices/vectors in heap comprise dimensions, type info, signal tag, etc. pvelus
of course the vector "data string". For instance, vector addition uses the type info
to select the suitable intrinsic instruction. Kind of dumb operator overloading,
but coded within the primitive, without generic Forth words like in your project

As to further developing your vector project, with all due respect, I doubt that this path leads to
more satisfactory results simply because there is way too much variety between CPU
generations and brands (and C compilers). I would leave those SIMD/AVX instructions
in their assembler or bultins/intrinsics world, but you may of course have other ideas
of which I am not aware.

On 11/11/2022 7:47 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> For cherry-picked worst-case examples used to justify locals, if
>> hand-coded assembler does a better job than either stack or locals,
>> what's wrong with that?
>
> The worst-case examples are where using pure stack ops causes pain so
> excruciating that it stops your work, unless some other approach is
> found.

Pure variable ops cause pain to forthers. What now?

On 11/11/2022 5:35 am, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> On 10/11/2022 4:22 am, Anton Ertl wrote:
>>> What would be your solution? Elizabeth Rather suggested assembler,
>>> and I expect that's what Chuck Moore used before doing his own
>>> hardware. On i21 he then added A and enhanced R.
>>
>> Firstly I don't see more variables and variable operations as a
>> solution. Apparently many do. When 99% of the world of the world's
>> languages is using variables both to solve its problems and craft
>> its functions, it's perhaps no surprise forthers will also come to
>> see them as a solution too - such is the conscious (and unconscious)
>> bias.
>
> This does not tell me how you would solve the problem.

By avoiding them. If my hands are so tied that I can't, I'll go for
the least worst option. AFAIR I've never used locals - at least not
in code written for myself as I consider them lazy and promiscuous.

>> For cherry-picked worst-case examples used to justify locals, if
>> hand-coded assembler does a better job than either stack or locals,
>> what's wrong with that?
>
> It's not Forth.

Since when. ISTR Moore saying something to the effect portability
was a myth.

Paul Rubin wrote:
> Blocks instead of files. I thought this one had resolved some decades
> ago.

I'm using blocks in my day job right now. What do bare metal Forths
with things like flash storage do these days?

Lars Brinkhoff schrieb am Freitag, 11. November 2022 um 08:40:38 UTC+1:
> Paul Rubin wrote:
> > Blocks instead of files. I thought this one had resolved some decades
> > ago.
>
> I'm using blocks in my day job right now. What do bare metal Forths
> with things like flash storage do these days?

Blocks are still viable. Huffman-compressed text takes less storage.

"minf...@arcor.de" <minforth@arcor.de> writes:
>For instance, vector addition uses the type info
>to select the suitable intrinsic instruction. Kind of dumb operator overloading,
>but coded within the primitive, without generic Forth words like in your project

I think I decided to let the programmer specify the type mainly to
follow Forth tradition, but also to avoid the need to decide what
happens when the programmer wants to mix types. E.g.,

( dfv1 dfv2 ) vdup 0e df>=vs ( dfv1 dfv2 xv ) andv ( dfv1 dfv3 ) df+v ( dfv4 )

When ANDV sees a vector of DFs (64-bit floats) and a vector of Xs
(64-bit integers), what should the result be? I as programmer know
that I want to mask the FP numbers here, but on another occasion I
might want to extract the mantissa fields or somesuch. The most
plausible result is that ANDV produces a bit-vector. When an
overloading +v sees a DF vector and a bit vector, what kind of
addition should it do? With DF+V, it's clear that it should do a DF
addition.

But this issue can be resolved (e.g., by explicitly specifying the
result type of the ANDV), and maybe overloaded operators are
preferable in the end. Normally Forth has few types (cells and
double-cells, sometimes with unsigned variants, characters in memory,
and one float type on the FP stack), while there are 10 different
vector types in my vector wordset; it may be that this is too much
mental load on the programmer and that the Forth system should take
care of that.

>As to further developing your vector project, with all due respect, I doubt that this path leads to
>more satisfactory results simply because there is way too much variety between CPU
>generations and brands (and C compilers). I would leave those SIMD/AVX instructions
>in their assembler or bultins/intrinsics world, but you may of course have other ideas
>of which I am not aware.

It's not sure which path you mean. The current implementation deals
with the variety between architectures by delegating it to gcc. The
difference between CPUs supporting more or fewer instruction set
extensions can be dealt with by compiling for the CPU variety at hand.
Given that the C code is in principle compiled when the vector wordset
is loaded, this could relatively straightforward; in practice the
compiled code is cached, and currently the caching does not take the
CPU variant into account.

In a path I would hope for we provide lower-level SIMD facilities
directly in Forth so that we don't need to defect to C or assembly
language. That path would suffer from the vastness of the SIMD
instruction sets, so it needs a lot of effort, and we may not see
enough interest in that path and its benefits to make this effort.
But in a hypothetical future where Forth occupies the close-to-machine
space that C is retreating from we should be taking this path.

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

In article <1155bad1-7e20-47e4-b7b5-b53c82390b4cn@googlegroups.com>,
minf...@arcor.de <minforth@arcor.de> wrote:
>Lars Brinkhoff schrieb am Freitag, 11. November 2022 um 08:40:38 UTC+1:
>> Paul Rubin wrote:
>> > Blocks instead of files. I thought this one had resolved some decades
>> > ago.
>>
>> I'm using blocks in my day job right now. What do bare metal Forths
>> with things like flash storage do these days?
>
>Blocks are still viable. Huffman-compressed text takes less storage.

The way I use blocks is wasting 40%, compared to regular text files, but the
overhead allows the library to be organized as a database of sorts.
It could be compressed to 25% for transporting.
On the other hand, the library don't take a zillion files, and is the
same accross linux apple and MS, and 16/32/64.

250 Kbyte. This include an assembler, floating point, a full screen
editor for MSDOS, compilation and scripting (not in the kernel),
debugging tools, and tools that install on a hard disk, other tools.
Space is not everything.

It is not all that hard to come up with a ISO compatible FILE wordset
in MSP430. Willem Ouwerkerk did it.
I have made a FILE wordset, that uses a tig Gbyte memory stick,
that should work on a OS that handles the USB communication to the stick.

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

In article <tkkako$1sl1$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
<SNIP>
>
>Since when. ISTR Moore saying something to the effect portability
>was a myth.

He was wrong. gcc and gforth are portable to an undeniable extent.
Hell, programs written in ciforth are portable across a spectrum
of OSes.

The only point he can possibly contest, is that he don't think it's
worth the effort.

We recently discussed the compiling of pforth. There was a hitch and
it ultimately succeeded. This cannot be compared with writing pforth
from scratch.

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 11/11/2022 8:25 pm, albert wrote:
> In article <tkkako$1sl1$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
> <SNIP>
>>
>> Since when. ISTR Moore saying something to the effect portability
>> was a myth.
>
> He was wrong. gcc and gforth are portable to an undeniable extent.
> Hell, programs written in ciforth are portable across a spectrum
> of OSes.
>
> The only point he can possibly contest, is that he don't think it's
> worth the effort.
>
> We recently discussed the compiling of pforth. There was a hitch and
> it ultimately succeeded. This cannot be compared with writing pforth
> from scratch.

I chased down some references re Moore on portability. Folks can make
of them what they will. It's with good reason he's a thorn to many :)

http://www.ultratechnology.com/antiansi.htm
http://www.ultratechnology.com/levels.htm