On 2017-08-22, minforth@arcor.de <minforth@arcor.de> wrote:
> Just musing whether I should engage on this road or not:
>
> 16/32 bit is adequate enough for ~ 98% of Forth applications. After all Forth is not in the same ballpark league as SciPy for example.
>
> OTOH sometimes speed matters, e.g. image processing or analyzing big data files.
>
> But for this a full 64-bit system is not really needed. Code size is never that large.
> It would suffice to being able to address the larger address range of > 4GB.
> E.g. by special new cperators a la CQ@ ( quad-adr -- char ).
>
> Or am i missing something here???
>
> P.S. as 64-bit CPUs seem to use only 48 bit, quad addresses would fit into the mantissa of floating poiint numbers. But I fear such overloading would make
> the thing too slow...

My own home-grown Forth is a 64/32 bit system. The data stacks, variables, and so on are 64 bits - all of the "internals" of the system
(cells in definition lists, CFAs, PFAs, etc.) are 32 bits. I'm currently using a Fedora 34 system, but I first wrote thhis Forth under
MacOS, and Apple's MACHO executable format requires code to be fully relocatable. I dealth with this by having all "address specifying"
entities in the system be offsets - either from the base of the word "bodies" or the base of the "headers." I keep both of those quantities
in registers, so I just do a quick register add to offsets, as appropriate, to get addresses.

Once an address lands on the stack, it's a right and proper 64-bit address (i.e., the "dovar" handler adds the right base address and so on).

I've been quite happy with this structure so far. I get 64-bit data and calculations, but the systems not so bloated as it would be if
EVERYTHING were 64 bits.

My reasonging on this was that this allows me to have self-contained Forth operation over a 4 GB span, and I just can't imagine ever filling
that up. On the other hand, I can at least IMAGINE filling up 64k, though we all know how compact Forth is, so it might take a while.

Anyway, just thought I'd inject here that such a "hybrid" system can work quite well, and sort of "straddles the fence."

On Sunday, April 10, 2022 at 5:50:55 AM UTC+2, Kip Ingram wrote:
> On 2017-08-22, minf...@arcor.de <minf...@arcor.de> wrote:
> > Just musing whether I should engage on this road or not:
> >
> > 16/32 bit is adequate enough for ~ 98% of Forth applications. After all Forth
> > is not in the same ballpark league as SciPy for example.

Then you're doing it wrong :--)

> > OTOH sometimes speed matters, e.g. image processing or analyzing big data files.
> >
> > But for this a full 64-bit system is not really needed. Code size is never that large.
> > It would suffice to being able to address the larger address range of > 4GB.

Not a bad assumption. The problem is that you might be isolating yourself from
others, be it Forth or foreign libraries, and it might limit you to certain hardware.

The first versions of iForth had a single 64k segment for code and many
segments for data (so address where 32bit), and I tried a few variants of
that. It worked fine, but none of that code I can, or will, use anymore (the
limitation influenced the source code).

If it is possible to *completely* hide the limited code size in the software,
it is of course a different matter. E.g., are constants, variables and values
32bit or 64bit? What about hardcoded offsets? Will external code be able
to do a callback to your Forth?

-marcel

Kip Ingram <kip.ingram@gmail.com.invalid> writes:
>I've been quite happy with this structure so far. I get 64-bit data and calculations, but the systems not so bloated as it would be if
>EVERYTHING were 64 bits.

True, but how bloated is that. Here are a few metrics from IA-32
vs. AMD64 gforth without assembler/disassembler:

IA-32 AMD64
261132 478240 dictionary space used after startup (in bytes)
444412 441329 gforth-fast native code size (in bytes)

There is quite a bit of relative difference in the dictionary space,
true, but the absolute savings is small compared to the memory size on
a 64-bit machine (and for a hybrid 32/64-bit system it would be even
smaller). So do you really care? Even on the first 64-bit machine I
worked on, an Alpha with 128MB in 1995, the "bloat" of 64-bit Gforth
never was a problem.

>My reasonging on this was that this allows me to have self-contained Forth operation over a 4 GB span, and I just can't imagine ever filling
>that up.

It's easy to imagine data space sizes >4GB. E.g., just load a big
file. We replaced one 32GB machine with a 128GB machine, because the
32GB machine became too small for using Emacs on my some of my email
files (which contain emails I stored in the last 30 years). Email
seems a common problem: A collegue works with email in a completely
different setup (using some MacOS X program), and he bought a new Mac
because the RAM of the old Mac became too small for his emails.

Data bases, video and photo processing are also reasons for large data
spaces. And in this group we talked about 7GB data spaces alredy 17
years ago <2005Apr1.151240@mips.complang.tuwien.ac.at>, although we
actually managed to keep the needed space within the 4GB limit
(probably mostly by necessity, because physical memory on the machine
I used was 8GB, and I could not occupy that much on this shared
machine for jobs that ran on the order of days).

As for dictionary size, yes, if the dictionary is limited to 4GB, we
can work around that by ALLOCATEing data space. But is the reduction
in size worth that complication?

- 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

First time I dumped a 32-bit Forth I wanted to puke; where's the code, nothing but a bunch of zero's
and small splattering of one's!
Yes, 32- 64- bit is fine for data space but keep code space to 16-bits (no program needs to be
larger than 640K).
There was a Forth 16-bit system that used doubles on the data stack; something I avoided at the
time. Hope someone with the time would explore building one maybe with a separate 64-bit wide
data stack and a 16-bit wide code stack and see if it could be made workable (palatable).
--
me

On Sunday, April 10, 2022 at 9:30:38 AM UTC-4, S Jack wrote:
> First time I dumped a 32-bit Forth I wanted to puke; where's the code, nothing but a bunch of zero's
> and small splattering of one's!
> Yes, 32- 64- bit is fine for data space but keep code space to 16-bits (no program needs to be
> larger than 640K).
> There was a Forth 16-bit system that used doubles on the data stack; something I avoided at the
> time. Hope someone with the time would explore building one maybe with a separate 64-bit wide
> data stack and a 16-bit wide code stack and see if it could be made workable (palatable).
> --
> me
Why don't you spend the time developing a solution that doesn't make you puke?

- Myron

On Sunday, April 10, 2022 at 11:52:15 AM UTC-4, Myron Plichota wrote:
> On Sunday, April 10, 2022 at 9:30:38 AM UTC-4, S Jack wrote:
> > First time I dumped a 32-bit Forth I wanted to puke; where's the code, nothing but a bunch of zero's
> > and small splattering of one's!
> > Yes, 32- 64- bit is fine for data space but keep code space to 16-bits (no program needs to be
> > larger than 640K).
> > There was a Forth 16-bit system that used doubles on the data stack; something I avoided at the
> > time. Hope someone with the time would explore building one maybe with a separate 64-bit wide
> > data stack and a 16-bit wide code stack and see if it could be made workable (palatable).
> > --
> > me
> Why don't you spend the time developing a solution that doesn't make you puke?
>
> - Myron
PS Jimbo is not James Bond

S Jack <sdwjack69@gmail.com> writes:
> First time I dumped a 32-bit Forth I wanted to puke; where's the code,
> nothing but a bunch of zero's and small splattering of one's!

I believe the commercial implementations moved from threaded code to
native compilation along with the switch to 32 bits, in order to
increase code density, for the reason you describe.

On Sunday, April 10, 2022 at 1:00:17 PM UTC-5, Paul Rubin wrote:
> S Jack <sdwj...@gmail.com> writes:
> > First time I dumped a 32-bit Forth I wanted to puke; where's the code,
> > nothing but a bunch of zero's and small splattering of one's!
> I believe the commercial implementations moved from threaded code to
> native compilation along with the switch to 32 bits, in order to
> increase code density, for the reason you describe.
Thanks, I learned something.
--
me

Paul Rubin schrieb am Sonntag, 10. April 2022 um 20:00:17 UTC+2:
> S Jack <sdwj...@gmail.com> writes:
> > First time I dumped a 32-bit Forth I wanted to puke; where's the code,
> > nothing but a bunch of zero's and small splattering of one's!
> I believe the commercial implementations moved from threaded code to
> native compilation along with the switch to 32 bits, in order to
> increase code density, for the reason you describe.

May be. I guess that it has also to do with the complexity of the compiler
back-end for 64-bit CPUs with their plethora of registers and operators.

Given the typical smallish Forth applications it is just not worth while
to develop your own 64-bit back-end - and maintain it over CPU generations.

"minf...@arcor.de" <minforth@arcor.de> writes:
>Paul Rubin schrieb am Sonntag, 10. April 2022 um 20:00:17 UTC+2:
>> I believe the commercial implementations moved from threaded code to
>> native compilation along with the switch to 32 bits, in order to
>> increase code density, for the reason you describe.
>
>May be. I guess that it has also to do with the complexity of the compiler
>back-end for 64-bit CPUs with their plethora of registers and operators.

Why should the switch to native code when moving from 16-bit to 32-bit
have anything to do with 64-bit CPUs? MPE and Forth, Inc. switched
to native code around 1996 or 1997, 64-bit CPUs for PCs were only
introduced in 2003.

Marcel Hendrix and Stephen Pelc can tell you more about it, but I see
no reason that 64-bit code generation should be any more complex than
32-bit code generation. The bigger problem is probably flushing out
all the 32-bit assumptions in the Forth system.

>Given the typical smallish Forth applications it is just not worth while
>to develop your own 64-bit back-end - and maintain it over CPU generations.

Concerning native-code compilers, Marcel Hendrix and Stephen Pelc
probably disagree that it's not worthwhile.

Concerning maintenance: The cool thing about computer architectures
such as AMD64 is that they provide a single interface to different CPU
implementations, whether marketing sells them as generations or not;
e.g., a Gforth binary that first ran on an Athlon 64 (from AMD) also
runs on a Core 2 (from Intel), a Xeon-W 1370P (Intel), a Ryzen 7 5800X
(AMD), a Celeron J3455 (Intel), and many other CPUs, all with
different microarchitectures and implementations.

So, there is no need for maintenance for new CPU generations.

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

Anton Ertl schrieb am Montag, 11. April 2022 um 11:06:14 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >Paul Rubin schrieb am Sonntag, 10. April 2022 um 20:00:17 UTC+2:
> >> I believe the commercial implementations moved from threaded code to
> >> native compilation along with the switch to 32 bits, in order to
> >> increase code density, for the reason you describe.
> >
> >May be. I guess that it has also to do with the complexity of the compiler
> >back-end for 64-bit CPUs with their plethora of registers and operators.
> Why should the switch to native code when moving from 16-bit to 32-bit
> have anything to do with 64-bit CPUs?

I stand corrected, having not read close enough that 32 bit architectures were
in the discussion.

> So, there is no need for maintenance for new CPU generations.

My experience is different. But agreed that it had been more in the 90s
which in the end drove us to replace (most) assembly code with C.

On Monday, April 11, 2022 at 11:06:14 AM UTC+2, Anton Ertl wrote:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >Paul Rubin schrieb am Sonntag, 10. April 2022 um 20:00:17 UTC+2:
> >> I believe the commercial implementations moved from threaded code to
> >> native compilation along with the switch to 32 bits, in order to
> >> increase code density, for the reason you describe.

> So, there is no need for maintenance for new CPU generations.

Well, I needed to fool around an hour with sse2 to implement register
locals (your sha-512 challenge of late), and I plan some months when
AVX512 becomes usable. I will definitely want to have native
quad-floats when they are made available (somebody, please, write
a killer game that needs quadruple precision :--)

-marcel

On 11 Apr 2022 at 09:45:16 CEST, "minforth@arcor.de" <minforth@arcor.de>
wrote:

> Paul Rubin schrieb am Sonntag, 10. April 2022 um 20:00:17 UTC+2:
>> S Jack <sdwj...@gmail.com> writes:
>>> First time I dumped a 32-bit Forth I wanted to puke; where's the code,
>>> nothing but a bunch of zero's and small splattering of one's!
>> I believe the commercial implementations moved from threaded code to
>> native compilation along with the switch to 32 bits, in order to
>> increase code density, for the reason you describe.
>
> May be. I guess that it has also to do with the complexity of the compiler
> back-end for 64-bit CPUs with their plethora of registers and operators.
>
> Given the typical smallish Forth applications it is just not worth while
> to develop your own 64-bit back-end - and maintain it over CPU generations.

Given the difference in performance of a good Forth code generator over a
mediocre one, it's well worth while writing one. Given for x86 we have had16,
32
and 64 bit in 40 years, it's not such a big deal. Similarly for ARM32 and
ARM64
in (say) 20/30 years.

The bigger problem is that ISAs have become baroque in the last 10 years or
so.
RISC-V is no better than the rest!

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 <2022Apr10.092209@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Kip Ingram <kip.ingram@gmail.com.invalid> writes:
>>I've been quite happy with this structure so far. I get 64-bit data and calculations, but the systems not so bloated as it would be if
>>EVERYTHING were 64 bits.
>
>True, but how bloated is that. Here are a few metrics from IA-32
>vs. AMD64 gforth without assembler/disassembler:
>
>IA-32 AMD64
>261132 478240 dictionary space used after startup (in bytes)
>444412 441329 gforth-fast native code size (in bytes)
>
>There is quite a bit of relative difference in the dictionary space,
>true, but the absolute savings is small compared to the memory size on
>a 64-bit machine (and for a hybrid 32/64-bit system it would be even
>smaller). So do you really care? Even on the first 64-bit machine I
>worked on, an Alpha with 128MB in 1995, the "bloat" of 64-bit Gforth
>never was a problem.

I agree completely. This discussion should be over by now.

>M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

--
"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 Apr 2022 at 12:26:13 CEST, "Marcel Hendrix" <mhx@iae.nl> wrote:
>
> Well, I needed to fool around an hour with sse2 to implement register
> locals (your sha-512 challenge of late), and I plan some months when
> AVX512 becomes usable. I will definitely want to have native
> quad-floats when they are made available (somebody, please, write
> a killer game that needs quadruple precision :--)
>
On of the surprises in the AMD64 development was that all our clients
wanted their 80 bit floats back. So it's going back in. 128 bit float will
probably fix all those issues for for my and my clildren's lives.

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

Stephen Pelc schrieb am Montag, 11. April 2022 um 12:39:12 UTC+2:
> On 11 Apr 2022 at 12:26:13 CEST, "Marcel Hendrix" <m...@iae.nl> wrote:
> >
> > Well, I needed to fool around an hour with sse2 to implement register
> > locals (your sha-512 challenge of late), and I plan some months when
> > AVX512 becomes usable. I will definitely want to have native
> > quad-floats when they are made available (somebody, please, write
> > a killer game that needs quadruple precision :--)
> >
> On of the surprises in the AMD64 development was that all our clients
> wanted their 80 bit floats back. So it's going back in. 128 bit float will
> probably fix all those issues for for my and my clildren's lives.

Elliptic curve crypto-currency mining algorithms will drive the demand
for CPUs with fatter floats soon enough.

On Monday, April 11, 2022 at 2:00:43 PM UTC+2, minf...@arcor.de wrote:
> Stephen Pelc schrieb am Montag, 11. April 2022 um 12:39:12 UTC+2:
> > On 11 Apr 2022 at 12:26:13 CEST, "Marcel Hendrix" <m...@iae.nl> wrote:
[..]
> Elliptic curve crypto-currency mining algorithms will drive the demand
> for CPUs with fatter floats soon enough.

I didn't believe it at first, but indeed ...

"Many common processors possess floating-point hardware that can be
used to implement prime field arithmetic. A fast method presented by
Bernstein using floating-point methods is outlined in §5.1.2."

'Guide to elliptic curve cryptography', Darrel Hankerson, Alfred J. Menezes,
Scott Vanstone. ISBN 0-387-95273-X

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>On Monday, April 11, 2022 at 11:06:14 AM UTC+2, Anton Ertl wrote:
>> "minf...@arcor.de" <minf...@arcor.de> writes:
>> >Paul Rubin schrieb am Sonntag, 10. April 2022 um 20:00:17 UTC+2:
>> >> I believe the commercial implementations moved from threaded code to
>> >> native compilation along with the switch to 32 bits, in order to
>> >> increase code density, for the reason you describe.
>
>> So, there is no need for maintenance for new CPU generations.
>
>Well, I needed to fool around an hour with sse2 to implement register
>locals (your sha-512 challenge of late), and I plan some months when
>AVX512 becomes usable.

AVX-512 is a new architectural feature that you may choose to use or
ignore.

SSE2 has been available on all AMD64 CPUs since the beginning. If you
chose not to use it, this supports my statement above:-). If you then
decide to use it, it is certainly notmaintenance for new CPU
generations.

- 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

Stephen Pelc <stephen@vfxforth.com> writes:
>The bigger problem is that ISAs have become baroque in the last 10 years or
>so.
>RISC-V is no better than the rest!

Anything in particular about RISC-V? My impression is that they are
relatively spartan. In particular, they make it a philosophy not to
add architectural features if they can avoid it, in particular with
instruction fusion (e.g., instead of an indexed addressing mode, fuse
a shift, an add and a load into an indexed-load micro-instruction).

However, looking at the disassembler sizes (in lines) does not really
support this impression:

610 amd64/disasm.fs

523 arm64/disasm.fs

289 riscv/disasm.fs
60 riscv/inst16.fs
177 riscv/inst32.fs
526 total

Ok, the latter includes two additional file boilerplates, but even
considering that, riscv is not much smaller.

- 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

"minf...@arcor.de" <minforth@arcor.de> writes:
>My experience is different. But agreed that it had been more in the 90s
>which in the end drove us to replace (most) assembly code with C.

What is your experience?

90s would be from the 486 to the Pentium III and the Athlon, maybe
starting from code for the 386 or earlier. Of course, if you start
with 16-bit code (286) and want to switch to 32-bit code, you
certainly have to do something. The rest is mainly performance
issues, but that is icing on the cake rather than necessary. I have
certainly used code built on a 486 on a Pentium, a K6-2, and an
Athlon.

- 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