64-bit Forth opinion?

[minf...@arcor.de]

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...

[Alex]

On 22-Aug-17 16:32, minf...@arcor.de wrote:
> 64-bit CPUs seem to use only 48 bit

Currently.
https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf

--
Alex

[Ron Aaron]

On 22/08/2017 18:32, 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.
>
> OTOH sometimes speed matters, e.g. image processing or analyzing big data files.

Well, yes. 4G is a lot of RAM for *most* uses, but certainly there are
many situations where you can comfortably (or profitably, more's the
point) use a lot more than that.

I worked on a system with 128G of RAM, 32 cores, and all of that HW was
actually necessary.

> But for this a full 64-bit system is not really needed. Code size is never that large.

Don't be so sure. Despite Bill Gates' declaration that 640K is enough,
I wouldn't be surprised if the Office suite started requiring more than
4G to run properly.

But besides that, running native 64-bit (on 64-bit CPUs, obviously) has
advantages in terms of register availability as well as more capable
maths functions. So it's not just code or data-size issues.

[m...@iae.nl]

On Tuesday, August 22, 2017 at 5:32:33 PM UTC+2, 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.

That is new to me (and to iForth users) :-)
I've just spent a day on adding robpole(https://www.mathworks.com/matlabcentral/fileexchange/53969-robpole)
to iForth64's digital control and system simulation library.

> OTOH sometimes speed matters, e.g. image processing or analyzing
> big data files.

I remember reports a few weeks ago that some Linuxes
stopped supporting 32bit code.

We have definitely stopped support for 32bit iForth
a long time ago.

> 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???

"Those who cannot remember the past are condemned to repeat it." (George Santayana). Remember those old time Forths? 64k segment switching,
32bit bit pointers (normalized segment+offset, or even naked),
DOS extenders ... All dead, all code gone, all effort wasted.
The future is 64bit (and 128bit floats of course).

> 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...

Code written this way will not survive the ages
(nor the decade). At least the old tricks let you
do something that couldn't be done any other way.

-marcel

[Anton Ertl]

minf...@arcor.de writes:
>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???

Sure, a reason why you would complicate the Forth system with
quad-adrs etc. 64-bit cells work nicely, no complications needed.

>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...

There are programming language implementations (JavaScript) that work
that way; Pointers and other non-FP types are encoded as FP NaNs. Of
course, given that upcoming Intel CPUs make use of up to 57 bits (and
maybe in the future all 64 bits), avoid such stunts if possible (and
in Forth it's easily possible).

- 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://euro.theforth.net/

[gavino himself]

is gforth 64 bit? now?

[Anton Ertl]

gavino himself <jack...@gmail.com> writes:
>is gforth 64 bit? now?

Gforth has supported 64-bit platforms since 1995.

[minf...@arcor.de]

Yes, thanks for pointing this out.

OTOH the "boundaries" between classic embedded processors and bigger CPUs
are dwindling. Some day a complete rPi board will fit into a single chip,
running raspberry internally w/o too many thermal problems. The embedded world
is changing rapidly. Micropython is just a prominent example.

[minf...@arcor.de]

Thanks, this was new to me. One never learns out.

[minf...@arcor.de]

Am Dienstag, 22. August 2017 18:42:59 UTC+2 schrieb m...@iae.nl:
> On Tuesday, August 22, 2017 at 5:32:33 PM UTC+2, 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.
>
> That is new to me (and to iForth users) :-)
> I've just spent a day on adding robpole(https://www.mathworks.com/matlabcentral/fileexchange/53969-robpole)
> to iForth64's digital control and system simulation library.
>

Interesting. You are using adaptive state controllers in the loop
or is it off-line in some engineering tool?

> > OTOH sometimes speed matters, e.g. image processing or analyzing
> > big data files.
>
> I remember reports a few weeks ago that some Linuxes
> stopped supporting 32bit code.
>
> We have definitely stopped support for 32bit iForth
> a long time ago.
>

I assume that for smaller-sized CPUs you are using iForth only for cross-
compilation of binaries, right?

> > 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???
>
> "Those who cannot remember the past are condemned to repeat it." (George Santayana). Remember those old time Forths? 64k segment switching,
> 32bit bit pointers (normalized segment+offset, or even naked),
> DOS extenders ... All dead, all code gone, all effort wasted.
> The future is 64bit (and 128bit floats of course).
>
> > 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...
>
> Code written this way will not survive the ages
> (nor the decade). At least the old tricks let you
> do something that couldn't be done any other way.
>

Well, I no longer care about "the ages", but some decades will do fine. ;-)

But I wouldn't be so pessimistic about all being 64 bitters in the future.
There is still a huge and still growing market for small low-power devices!

[Albert van der Horst]

In article <onhmlr$p6l$1...@dont-email.me>,

I like 64 bits.
I've yet an other prime counting program with a balance between
sieving and splitting. A spin off of euler problem 521.

It counts 10^14 in 28 minutes (indirect threaded Forth 4 Ghz)
Gives
3,204,941,750,802
which doesn't fit in 32 bits anymore.

The last line in the pi(x) table of Ribenboim "The new book of
prime number records" (new but dated)

10^11 takes 4.7 seconds, so it is sublinear in this range.

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

[Cecil Bayona]

MacOS will soon not support 32 bit applications.


--
Cecil - k5nwa

[m...@iae.nl]

On Tuesday, August 22, 2017 at 10:18:33 PM UTC+2, minf...@arcor.de wrote:
> Am Dienstag, 22. August 2017 18:42:59 UTC+2 schrieb m...@iae.nl:
> > On Tuesday, August 22, 2017 at 5:32:33 PM UTC+2, 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.
> >
> > That is new to me (and to iForth users) :-)
> > I've just spent a day on adding robpole
> (https://www.mathworks.com/matlabcentral/fileexchange/53969-robpole)
> > to iForth64's digital control and system simulation library.
> >
>
> Interesting. You are using adaptive state controllers in the loop
> or is it off-line in some engineering tool?

In an engineering tool. Leave it to software vendors and our
tools of the trade become bigger and slower until they fill
all of memory, eat all CPU time and our spare time, too.
I'm not joking :-)

[..]

> > Code written this way will not survive the ages
> > (nor the decade). At least the old tricks let you
> > do something that couldn't be done any other way.
> >
>
> Well, I no longer care about "the ages", but some decades
> will do fine. ;-)
>
> But I wouldn't be so pessimistic about all being 64 bitters
> in the future. There is still a huge and still growing
> market for small low-power devices!

If you ask the users, they want smaller, less power, the
same speed, simpler, and *lower cost*. Obviously the industry
cannot give us what we *really* want, so they keep the cost
the same and increase the size, power, complexity, and speed.
The software guys (see above) face the same problem,
so they help the hardware guys to make you need all the
negatives, after all.

IOW, we will see 64bit controllers go into that huge market
you spot. You must find something for them to do.

-marcel

[minf...@arcor.de]

Am Dienstag, 22. August 2017 23:23:14 UTC+2 schrieb m...@iae.nl:
> On Tuesday, August 22, 2017 at 10:18:33 PM UTC+2, minf...@arcor.de wrote:
> > Am Dienstag, 22. August 2017 18:42:59 UTC+2 schrieb m...@iae.nl:
> > > On Tuesday, August 22, 2017 at 5:32:33 PM UTC+2, 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.
> > >
> > > That is new to me (and to iForth users) :-)
> > > I've just spent a day on adding robpole
> > (https://www.mathworks.com/matlabcentral/fileexchange/53969-robpole)
> > > to iForth64's digital control and system simulation library.
> > >
> >
> > Interesting. You are using adaptive state controllers in the loop
> > or is it off-line in some engineering tool?
>
> In an engineering tool. Leave it to software vendors and our
> tools of the trade become bigger and slower until they fill
> all of memory, eat all CPU time and our spare time, too.
> I'm not joking :-)
>

Don't tell me. We still have 640k DOS boxes in the field.
20 years old, but speed-wise they leave everything behind.

It's a pity that some cyber-security idiots are considering to
replace them by some "hardened" servers. Blatant stupidity always wins
in the end.

[Ron Aaron]

Though of course, there are still plenty of applications where an 8-bit
processor is plenty (and so cheap and power-saving, why would you not
use it?).

I just recently got a Raspberry Pi 3 so I could make a 64-bit RPI port
of 8th. Ironically, the default RPI distro is only 32-bits, so I had to
use a custom one...

Debugging ARM 64-bit code on a RPI3 is *much* nicer than trying to do it
on an iPhone. Just FYI, in case you were tempted to try it yourself.

[Ron Aaron]

On 23/08/2017 0:09, Albert van der Horst wrote:
> In article <onhmlr$p6l$1...@dont-email.me>,
> Ron Aaron <ramb...@gmail.com> wrote:


>> But besides that, running native 64-bit (on 64-bit CPUs, obviously) has
>> advantages in terms of register availability as well as more capable
>> maths functions. So it's not just code or data-size issues.
>
> I like 64 bits.

I do too -- both ARM and Intel have much more powerful instructions as
well as more registers. But 64-bit *does* come at a cost if you care
about that cost (power usage, size, expense...)

> I've yet an other prime counting program with a balance between
> sieving and splitting. A spin off of euler problem 521.
>
> It counts 10^14 in 28 minutes (indirect threaded Forth 4 Ghz)
> Gives
> 3,204,941,750,802
> which doesn't fit in 32 bits anymore.
>
> The last line in the pi(x) table of Ribenboim "The new book of
> prime number records" (new but dated)
>
> 10^11 takes 4.7 seconds, so it is sublinear in this range.

Nice. I'll have to see about that on 8th.

[Ron Aaron]

On 23/08/2017 0:19, Cecil Bayona wrote:
> On 8/22/2017 10:32 AM, minf...@arcor.de wrote:

> MacOS will soon not support 32 bit applications.

True. But e.g. 8th will still support 32-bit macOS, because the legacy
installations aren't going away just because Apple (rightly) wants to
simplify things for themselves.

Though I do expect that Apple users are much more likely to upgrade than
other platform users.

[Rod Pemberton]

On Tue, 22 Aug 2017 08:32:32 -0700 (PDT)
minf...@arcor.de wrote:

> 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 ).

If it's a 64-bit Forth, why wouldn't C@ use a quad address? ...

I.e., it's probably better to use CD@ or C32@ to restrict addresses to
32-bits or 4GB where needed for a 64-bit Forth, and use C@ for the
native address size of 64-bits. Ditto for 16-bit.

> Or am [I] missing something here???

...


Rod Pemberton
--
Isn't anti-hate just hate by another name? Isn't
anti-protesting just protesting by another name?
Peace is a choice that both sides rejected.

[minf...@arcor.de]

Am Mittwoch, 23. August 2017 08:44:50 UTC+2 schrieb Rod Pemberton:
> On Tue, 22 Aug 2017 08:32:32 -0700 (PDT)
> minf...@arcor.de wrote:
>
> > 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 ).
>
> If it's a 64-bit Forth, why wouldn't C@ use a quad address? ...
>
> I.e., it's probably better to use CD@ or C32@ to restrict addresses to
> 32-bits or 4GB where needed for a 64-bit Forth, and use C@ for the
> native address size of 64-bits. Ditto for 16-bit.
>

It was meant the other way round. How address 64-bit addresses from within
a 32-bit system?

But I fear it it is not easily possible to address real physical addresses
from the limited virtual address space assigned to a 32-bit program running
in a 64-bit Linux/BSD/Windows OS.

Nevertheless it would be helpful if the standard defines basic cell types
of fixed size like e.g. cell8/cell16/cell32/cell64 and ucell8/...
CHAR is unsigned in the standard, so signed byte arithmetics in Forth looks
strange. 1 CELLS varies from system to system, etc. IMO this is cumbersome.

C99 did it already for integer types.

[Anton Ertl]

Ron Aaron <ramb...@gmail.com> writes:
>I just recently got a Raspberry Pi 3 so I could make a 64-bit RPI port
>of 8th. Ironically, the default RPI distro is only 32-bits, so I had to
>use a custom one...

From what I understand about the Raspberry Pi, the idea is to keep the
software environment pretty constant and working on all models, so
they did not go for a 64-bit system (which would only work on the
rpi3). So your 64-bit port will not work in the rpi software
ecosystem, and I would not call it a RPI port, just and Aarch64 port.

Congratulations for getting a 64-bit system for the Rpi3, I never
found one when I searched for it.

For anybody who wants a not-too-expensive Aarch64 board with a 64-bit
OS (Ubuntu or Android) as standard OS, we use an Odroid C2. It's also
faster then the RPI3 and has more RAM.

[Anton Ertl]

minf...@arcor.de writes:
>It was meant the other way round. How address 64-bit addresses from within
>a 32-bit system?

Not at all! If you want 64-bit addresses, use 64-bit cells, i.e., a
64-bit system. Everything else is just needless complication.

>C99 did it already for integer types.

C's zoo of integer type is a source of bugs (especially portability
bugs), far more than I experience in Forth. It's not something we
should emulate.

[minf...@arcor.de]

Am Mittwoch, 23. August 2017 16:24:58 UTC+2 schrieb Anton Ertl:
> minf...@arcor.de writes:
> >It was meant the other way round. How address 64-bit addresses from within
> >a 32-bit system?
>
> Not at all! If you want 64-bit addresses, use 64-bit cells, i.e., a
> 64-bit system. Everything else is just needless complication.

I thought rewriting a complete working 32-bit system to 64 bits
might be a needless complication. ;-)
And eliminatng all the double words ... who needs 128 bit math but
for some number crunchers or crypto guys.

> >C99 did it already for integer types.
>
> C's zoo of integer type is a source of bugs (especially portability
> bugs), far more than I experience in Forth. It's not something we
> should emulate.

In my experience it was the int type that could cause such bugs, never
when properly declared as int32_t or int64_t as per <stdint.h>.

Forth's cell is ambiguous just like C's int.

[Anton Ertl]

minf...@arcor.de writes:
>Am Mittwoch, 23. August 2017 16:24:58 UTC+2 schrieb Anton Ertl:
>> minf...@arcor.de writes:
>> >It was meant the other way round. How address 64-bit addresses from within
>> >a 32-bit system?
>>
>> Not at all! If you want 64-bit addresses, use 64-bit cells, i.e., a
>> 64-bit system. Everything else is just needless complication.
>
>I thought rewriting a complete working 32-bit system to 64 bits
>might be a needless complication. ;-)

In the case of Gforth the port to support 64-bit cells as well as
32-bit cells was pretty easy.

>And eliminatng all the double words ... who needs 128 bit math but
>for some number crunchers or crypto guys.

Crypto guys need integers >128 bits. Number crunchers need FP.
Standard Forth needs 128 bits, e.g., for # and >NUMBER. It's easier
to define the few primitives that work with the existing double-using
code than to replace all this code with single-using code. And
occasionally it is also useful for other stuff.

>> C's zoo of integer type is a source of bugs (especially portability
>> bugs), far more than I experience in Forth. It's not something we
>> should emulate.
>
>In my experience it was the int type that could cause such bugs, never
>when properly declared as int32_t or int64_t as per <stdint.h>.

Too bad you are the only one doing it "properly", and, in particular,
various language features and library functions do it improperly.

>Forth's cell is ambiguous just like C's int.

Forth's cell is as it should be. Evidence: Forth programs tend to
just work on both 32-bit and 64-bit systems, while C programs tend to
need some porting effort.

[minf...@arcor.de]

This is nonsense and you know it. @ reads different-sized chunks of memory
in 32-bit and 64-bit Forths.

[Albert van der Horst]

In article <fa074faa-fb9c-44c6...@googlegroups.com>,
<minf...@arcor.de> wrote:
<SNIP>

>
>Forth's cell is ambiguous just like C's int.

I got sick and tired of this use of ambiguous.

If you have a program that factorises
numbers in 16 bit 32 or 64 bits Forths, with the difference
that it says :
"number too big"
for a different range, then we have not ambiguous int's.
There is also no reason to introduce a 16 bit type to have
the 64 bit Forth give the same error message that the 16 bits
Forth gives.

The reason to need int16 and the like in C is that linking is
still on the assembler level, especially linking with an
operating system.

[Ilya Tarasov]

вторник, 22 августа 2017 г., 18:32:33 UTC+3 пользователь minf...@arcor.de написал:

When I type VAR1 @ VAR2 @ + VAR3 ! it is no matter what exactly cell size I use. The only difference may appear if number is too big for 16 bits but ok for 32 or 64.

I think Forth should be ready to use 'native' datasize for given CPU/OS. In this case, operations like @ ! will use this size, while prefixes will be used for explicit size definition (for example, C(har), W(ord), D(oubleword), Q(uadword) etc.).

To make life easier at this way, promoting Forth as product must be replaced by promoting Forth by approach. This will make Forth suitable for wider usage, with certain bad impact on Forth vendors position... but who cares? :)

[rickman]

Ilya Tarasov wrote on 8/23/2017 5:15 PM:
> вторник, 22 августа 2017 г., 18:32:33 UTC+3 пользователь minf...@arcor.de написал:
>> 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...
>
> When I type VAR1 @ VAR2 @ + VAR3 ! it is no matter what exactly cell size I use. The only difference may appear if number is too big for 16 bits but ok for 32 or 64.
>
> I think Forth should be ready to use 'native' datasize for given CPU/OS. In this case, operations like @ ! will use this size, while prefixes will be used for explicit size definition (for example, C(har), W(ord), D(oubleword), Q(uadword) etc.).

Forth already works on the "native" size of words, provided the author
designs it that way. Some use cell sizes that are larger than the native
word size, such as 16 bit cells on 8 bit machines or 32 bit cells on 16 bit
CPUs. For anything else they are typically written for the native word
size, such as 32 bit cells on 32 bit CPUs and 64 bit cells on 64 bit CPUs.
I guess there are exceptions.

I don't see the advantage of having to declare your word size when it
doesn't change the size of the cell. Forth already has 2! and 2@. Do you
think it is important to change the way data sizes are handled?

> To make life easier at this way, promoting Forth as product must be replaced by promoting Forth by approach. This will make Forth suitable for wider usage, with certain bad impact on Forth vendors position... but who cares? :)

Bingo! I don't think there is much to be done to make Forth more palatable
for those who aren't using Forth. As Juergen and others think, I also
believe the way to promote Forth is to teach it to the young. There is too
much bias against it for anyone to take it seriously at this point.

--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

[Brad Eckert]

A Forth VM can implement any cell size, not just the native int of the CPU. You can run a 32-bit VM on an 8-bit 8051 or a 64-bit desktop. I wouldn't worry about OSes orphaning 32-bit Forth apps.

The value of VMs seems to be trending upward. If all your Forth bytecode fits in L0 cache because it's much more compact than native code, saving all those cache misses helps level the playing field. Time critical words and algorithms can always be VM tokens.

32-bit code runs on 8-bit machines without too much extra overhead. Having a 32-bit code base is kind of nice for reuse. It also plays nice with 32-bit PC Forths. 64-bit on an 8051 fits in the "just because you can doesn't mean you should" category.

[Ron Aaron]

On 08/23/17 17:06, Anton Ertl wrote:
> Ron Aaron <ramb...@gmail.com> writes:
>> I just recently got a Raspberry Pi 3 so I could make a 64-bit RPI port
>> of 8th. Ironically, the default RPI distro is only 32-bits, so I had to
>> use a custom one...
>
> From what I understand about the Raspberry Pi, the idea is to keep the
> software environment pretty constant and working on all models, so
> they did not go for a 64-bit system (which would only work on the
> rpi3). So your 64-bit port will not work in the rpi software
> ecosystem, and I would not call it a RPI port, just and Aarch64 port.

Yes, I think you're right about their notions, though one might ask why
they decided to use a 64-bit CPU if they didn't intend on taking
advantage of it. The RPI3 only has 1G RAM, so it's a dubious bit of HW
anyway, IMO.

But it *is* faster compared to the RPI2.

The port *is* RPI64. It runs on the RPI3 in 64-bit mode; although to be
honest, it would probably run on any 64-bit ARM linux, at least if it
were a Debian-based distro.

I am planning on expanding my "RPI" ports to handle other embedded-Linux
platforms, but I need some cooperation from the HW vendors to make this
worthwhile.

> Congratulations for getting a 64-bit system for the Rpi3, I never
> found one when I searched for it.

Here you go: https://github.com/bamarni/pi64

I found it trivial to install/run.

[minf...@arcor.de]

Am Mittwoch, 23. August 2017 20:52:18 UTC+2 schrieb Albert van der Horst:
> In article <fa074faa-fb9c-44c6...@googlegroups.com>,
> <minf...@arcor.de> wrote:
> <SNIP>
> >
> >Forth's cell is ambiguous just like C's int.
>
> I got sick and tired of this use of ambiguous.
>
> If you have a program that factorises
> numbers in 16 bit 32 or 64 bits Forths, with the difference
> that it says :
> "number too big"
> for a different range, then we have not ambiguous int's.
> There is also no reason to introduce a 16 bit type to have
> the 64 bit Forth give the same error message that the 16 bits
> Forth gives.
>
> The reason to need int16 and the like in C is that linking is
> still on the assembler level, especially linking with an
> operating system.

This is exactly my point.

[Anton Ertl]

Ron Aaron <ramb...@gmail.com> writes:
>Yes, I think you're right about their notions, though one might ask why
>they decided to use a 64-bit CPU if they didn't intend on taking
>advantage of it.

They are working with SoCs for mobile phones. Just like for mobile
phones, every year there are new ones, and old ones go out of
production after one or two years; these are not chips for embedded
systems with 10+ years of availability. So they have to change the
SoC (which is most of the hardware) regularly. I guess they also
wanted something faster than the RPi2 SoC.

>Here you go: https://github.com/bamarni/pi64

Thanks.

[Anton Ertl]

An obvious lack of arguments.

>@ reads different-sized chunks of memory
>in 32-bit and 64-bit Forths.

Yes, that's why they are called "32-bit Forths", and "64-bit Forths".
And yet Forth programs tend to work on both kinds of Forth systems.
Among the programs I collected for the appbench suite, only one had a
portability problem between 32-bit and 64-bit systems, and I am pretty
sure that most of the authors had tested them only on 32-bit systems.

[rickman]

Ron Aaron wrote on 8/22/2017 12:42 PM:
>
>
> On 22/08/2017 18:32, 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.
>>
>> OTOH sometimes speed matters, e.g. image processing or analyzing big data files.
>

> Well, yes. 4G is a lot of RAM for *most* uses, but certainly there are
> many situations where you can comfortably (or profitably, more's the
> point) use a lot more than that.
>
> I worked on a system with 128G of RAM, 32 cores, and all of that HW was
> actually necessary.
>
>

>> But for this a full 64-bit system is not really needed. Code size is never that large.
>

> Don't be so sure. Despite Bill Gates' declaration that 640K is enough,

"I didn't say all those things I said".

[m...@iae.nl]

On Thursday, August 24, 2017 at 5:07:43 AM UTC+2, rickman wrote:
[..]

> I don't see the advantage of having to declare your word size when it
> doesn't change the size of the cell. Forth already has 2! and 2@. Do you
> think it is important to change the way data sizes are handled?

There is an important problem to be considered: When Forth links to
foreign code, it needs to know the size of the foreign items and use
a corresponding @ and ! (32b! 32b@ 64b@ 64b! ... ) If these words
are not standardized, authors may be tempted to use @ and ! when
they use a 32bit Forth on a 32bit OS. If one wants to run such
code on a 64bit Forth for a 32 or 64bit OS, this code fails. The
reverse (porting 64bit to 32bit) is also problematic.

Note that e.g. a 32bit C library recompiled for a 64bit OS will
still have 32bit values in its structs.

-marcel

[menti...@gmail.com]

On Thursday, August 24, 2017 at 4:28:10 AM UTC-7, m...@iae.nl wrote:
> On Thursday, August 24, 2017 at 5:07:43 AM UTC+2, rickman wrote:

> [..] [...]

> If one wants to run such code on a 64bit Forth
> for a 32 or 64bit OS, this code fails.

> [...]
> -marcel

64-bit is important for MindForth AI.

--
http://dl.acm.org/citation.cfm?doid=307824.307853
http://github.com/kernc/mindforth/blob/master/wiki/AiStandards.wiki

[minf...@arcor.de]

Avoiding the unbeloved a.. word, @ is a.. ;-)
and since D@ and D! would be confusing for 32-bit access,
I like your proposal of (32b! 32b@ 64b@ 64b! ... )

[Alex]

The default operand size for x86-64 is 32 bits.

Only the address size defaults to 64 bits; and addresses are not
necessarily 64 bits long. For instance, base addresses from RIP (a
pseudo register that is the value of the instruction pointer) or
calculated implicit offsets from IP as in jump or call addresses are 32
bits.

--
Alex

[Anton Ertl]

m...@iae.nl writes:
>There is an important problem to be considered: When Forth links to
>foreign code, it needs to know the size of the foreign items and use
>a corresponding @ and ! (32b! 32b@ 64b@ 64b! ... )

For items in memory, yes, Forth needs to use the corresponding @ and
!, but the number of bits of the item is often platform-dependent, and
therefore the Forth source code must not just use words corresponding
to a specific bit width.

E.g., an item can be defined as

off_t x;

in C source code, and off_t is typically 32 bits or 64 bits (and on
32-bit systems, it is either, depending on other circumstances).

So what we actually need in the Forth source to fetch from x is
something like

x off_t.2@

or

x.2@

and the Forth system has to know what size off_t (or, in the latter
case, x) is, and provides a 2@ that accesses an off_t-wide memory.
Because the result does not fit in a single cell when off_t is 64 bits
and a cell is 32 bits, the Forth programmer uses 2@ (and this provides
2 cells even in cases when off_t fits in one cell, in order for the
surrounding Forth code to work).

>Note that e.g. a 32bit C library recompiled for a 64bit OS will
>still have 32bit values in its structs.

I have no idea what you mean with "32bit C", but if you compile C
source code on a 32-bit and on a 64-bit system, some types have the
same size, and some have different sizes; and some C types have
different sizes on 64-bit Windows and most 64-bit Unixes. And as
shown above, some C types even have different sizes on the same 32-bit
Unix.

If, OTOH, you mean a C library compiled to 32-bit code on a 64-bit
system, you cannot call functions of such a library from 64-bit code
on AMD64 and ARMv8, because 32-bit and 64-bit code have incompatible
instruction sets. And on systems where 64-bits are an extension of
the 32-bit instruction set (e.g., MIPS, SPARC, Power), I very much
doubt that this direction works, because the 32-bit library will do
bad things to 64-bit addresses.

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>The default operand size for x86-64 is 32 bits.
>
>Only the address size defaults to 64 bits;

Which is interesting to those writing an assembler or disassembler,
but has no effect on other things.

>and addresses are not
>necessarily 64 bits long. For instance, base addresses from RIP (a
>pseudo register that is the value of the instruction pointer) or
>calculated implicit offsets from IP as in jump or call addresses are 32
>bits.

Again the encoding of offsets in RIP-relative addressing is
interesting to writers of assemblers and disassemblers, but irrelevant
for most others. And note that an offset is not an address. The
offset for conditional jumps can be encoded as 8-bit or 32-bit value.
Does that mean that AMD64 has 8-bit addresses? No.

[rickman]

Using 32b! and 32b@ will *still* fail with a 64 bit Forth if 64 bit memory
operations are required.

[m...@iae.nl]

On Thursday, August 24, 2017 at 5:50:43 PM UTC+2, rickman wrote:
> m...@iae.nl wrote on 8/24/2017 7:28 AM:
> > On Thursday, August 24, 2017 at 5:07:43 AM UTC+2, rickman wrote:
> > [..]
> >

> > Note that e.g. a 32bit C library recompiled for a 64bit OS will
> > still have 32bit values in its structs.
>
> Using 32b! and 32b@ will *still* fail with a 64 bit Forth if 64 bit memory
> operations are required.

Of course. But I write

( 32bit Forth 32bit OS ) : close 6 door.offs 32b@ ... >floor ;
( 32bit Forth 64bit OS ) : close 6 door.offs 32b@ ... >floor ;
( 64bit Forth 32bit OS ) : close 6 door.offs 32b@ ... >floor ;
( 64bit Forth 64bit OS ) : close 6 door.offs 32b@ ... >floor ;

The only "bad thing" here is that I have to know the physical
size of the object to fetch.

-marcel

[Ilya Tarasov]

четверг, 24 августа 2017 г., 6:11:15 UTC+3 пользователь Brad Eckert написал:

> A Forth VM can implement any cell size, not just the native int of the CPU. You can run a 32-bit VM on an 8-bit 8051 or a 64-bit desktop. I wouldn't worry about OSes orphaning 32-bit Forth apps.
>
> The value of VMs seems to be trending upward. If all your Forth bytecode fits in L0 cache because it's much more compact than native code, saving all those cache misses helps level the playing field. Time critical words and algorithms can always be VM tokens.
>
> 32-bit code runs on 8-bit machines without too much extra overhead. Having a 32-bit code base is kind of nice for reuse. It also plays nice with 32-bit PC Forths. 64-bit on an 8051 fits in the "just because you can doesn't mean you should" category.

CPU native datasize is important mainly in the terms of effectiveness. Of course, we will lost a part of performance processing 32-bit data on 8-bit CPU. Other side is integration of Forth code into software environment. If most external programs exported data fits into 32 bits, we will have problems with 16-bit Forth, typing 2@ 2! every time. Similarly, 32-bit Forth feels itself bad into 64-bit environment. Writing wrappers for OS functions will be harder too.

In this case, having native datasize is valuable mostly because we will work with the same datasize for most programming tools, including Forth. So we can easily include Forth code into data processing chains, convert data, process big files etc. It is not too user-friendly to force him to remember he use one PL with different datasize than the rest if his PLs.

[Rod Pemberton]

On Wed, 23 Aug 2017 03:25:15 -0700 (PDT)
minf...@arcor.de wrote:

> Am Mittwoch, 23. August 2017 08:44:50 UTC+2 schrieb Rod Pemberton:
> > On Tue, 22 Aug 2017 08:32:32 -0700 (PDT)
> > minf...@arcor.de wrote:

> > > 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 ).
> >
> > If it's a 64-bit Forth, why wouldn't C@ use a quad address? ...
> >
> > I.e., it's probably better to use CD@ or C32@ to restrict addresses
> > to 32-bits or 4GB where needed for a 64-bit Forth, and use C@ for
> > the native address size of 64-bits. Ditto for 16-bit.
> >
>
> It was meant the other way round. How address 64-bit addresses from
> within a 32-bit system?
>

CQ@ or C64@ could be used, if you can define larger address pointers to
work correctly. I'd doubt that this is possible without both hardware
and operating system support.


Can't you overload C@ to work in both 32-bit and 64-bit situations?

: C@ CSTATE @ IF C@ ELSE CQ@ THEN ;

Other systems wouldn't have this C@ redefinition, so your code would
only use C@ and be portable. Of course, the ported code would need to
be excised of the code or words for setting and clearing of CSTATE for
other systems.

If the Forth standards required words indicating which size machine,
e.g., 16-bit, 32-bit, 64-bit, etc, that Forth code was executing upon,
perhaps F16, F32, F64, etc, then you could just query those words to
decide on size appropriate definitions of C@ .

If unknown,

: C@ F16 @ IF C16@ THEN F32 @ IF C32@ THEN F64 @ IF C64@ THEN ;

If known,

: C@ C16@ ; \ for 16-bit system
: C@ C32@ ; \ for 32-bit system
: C@ C64@ ; \ for 64-bit system

[minf...@arcor.de]

Am Freitag, 25. August 2017 08:49:55 UTC+2 schrieb Rod Pemberton:
> On Wed, 23 Aug 2017 03:25:15 -0700 (PDT)
> minf...@arcor.de wrote:
>
> > Am Mittwoch, 23. August 2017 08:44:50 UTC+2 schrieb Rod Pemberton:
> > > On Tue, 22 Aug 2017 08:32:32 -0700 (PDT)
> > > minf...@arcor.de wrote:
>
> > > > 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 ).
> > >
> > > If it's a 64-bit Forth, why wouldn't C@ use a quad address? ...
> > >
> > > I.e., it's probably better to use CD@ or C32@ to restrict addresses
> > > to 32-bits or 4GB where needed for a 64-bit Forth, and use C@ for
> > > the native address size of 64-bits. Ditto for 16-bit.
> > >
> >
> > It was meant the other way round. How address 64-bit addresses from
> > within a 32-bit system?
> >
>
> CQ@ or C64@ could be used, if you can define larger address pointers to
> work correctly. I'd doubt that this is possible without both hardware
> and operating system support.
>
>
> Can't you overload C@ to work in both 32-bit and 64-bit situations?
>
> : C@ CSTATE @ IF C@ ELSE CQ@ THEN ;
>

I am no OS expert but I once read that for 32-bit applications the Win64
system emulates a Win32 environment and provides a different set of runtime
libraries with it.

So I fear that the address space >4 gigs is not emulated and CQ@ won't work.

I don't know whether BSD/Linux/OSX behave similarly.

[Brad Eckert]

On Tuesday, August 22, 2017 at 8:32:33 AM UTC-7, 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.
>
> OTOH sometimes speed matters, e.g. image processing or analyzing big data files.
>

I can think of two reasons: OS calls and external code calls. I don't really see Forth being used for all of the complex middleware and libraries. The desktop Forths I use for actual work are mostly useful because they talk to hardware-specific DLLs and OS libraries.

I can also think of a reason why not. Using Forth is a matter of taste, and some of us think 64-bit apps are downright tasteless. Interface issues between the 64-bit OS and 32-bit application should not exist. It's Microsoft orphaning 16-bit apps all over again. Their answer to the problem (back in the day): Buy the non-existent 32-bit version of the app. The big difference between then and now is that 32 bits is not a wall. The other difference with the 64-bit "revolution" is that 32-bit is too big to break. They can't reasonably get away with it.

You could take the view that Moore's Law will add an address bit to your data memory every couple of years, so it won't be long before data memory in those systems exceeds 32-bit addressing. However, I don't think linear addressing is the right way to solve the problem. DRAM of today is like the floppy disk of old. Opening or closing a row in a modern DRAM takes something like 50ns, the same amount of time it takes to burst 128 words (1K bytes) into cache with a 1.33GHz bus. 1K bytes (128 64-bit words) would cost 64ns. 2^32 1K blocks is 2^42 (4T) bytes. It would be nice if DMA would make that transfer non-blocking. Blocks. Remember blocks? Still useful. With data sets beyond 32-bit, do we really have any business doing willy-nilly memory access? Thrashing DRAM rows can slow applications to a crawl.

Anyway, let me know when your home computer has more than 4T bytes of RAM and I'll think about 64-bit.

[Cecil Bayona]

32 bit has 4GB of addressing space not 4TB

--
Cecil - k5nwa

[Albert van der Horst]

In article <ad735e36-3dfd-46bd...@googlegroups.com>,

Brad Eckert <hwf...@gmail.com> wrote:
>On Tuesday, August 22, 2017 at 8:32:33 AM UTC-7, minf...@arcor.de wrote:
>> Just musing whether I should engage on this road or not:

>>=20
>> 16/32 bit is adequate enough for ~ 98% of Forth applications. After all F=

>orth is not in the same ballpark league as SciPy for example.

>>=20
>> OTOH sometimes speed matters, e.g. image processing or analyzing big data=
> files.
>>=20
>
>I can think of two reasons: OS calls and external code calls. I don't reall=
>y see Forth being used for all of the complex middleware and libraries. The=
> desktop Forths I use for actual work are mostly useful because they talk t=
>o hardware-specific DLLs and OS libraries.=20
>
>I can also think of a reason why not. Using Forth is a matter of taste, and=
> some of us think 64-bit apps are downright tasteless. Interface issues bet=
>ween the 64-bit OS and 32-bit application should not exist. It's Microsoft =
>orphaning 16-bit apps all over again. Their answer to the problem (back in =
>the day): Buy the non-existent 32-bit version of the app. The big differenc=
>e between then and now is that 32 bits is not a wall. The other difference =
>with the 64-bit "revolution" is that 32-bit is too big to break. They can't=

> reasonably get away with it.
>

>You could take the view that Moore's Law will add an address bit to your da=
>ta memory every couple of years, so it won't be long before data memory in =
>those systems exceeds 32-bit addressing. However, I don't think linear addr=
>essing is the right way to solve the problem. DRAM of today is like the flo=
>ppy disk of old. Opening or closing a row in a modern DRAM takes something =
>like 50ns, the same amount of time it takes to burst 128 words (1K bytes) i=
>nto cache with a 1.33GHz bus. 1K bytes (128 64-bit words) would cost 64ns. =
>2^32 1K blocks is 2^42 (4T) bytes. It would be nice if DMA would make that =
>transfer non-blocking. Blocks. Remember blocks? Still useful. With data set=
>s beyond 32-bit, do we really have any business doing willy-nilly memory ac=

>cess? Thrashing DRAM rows can slow applications to a crawl.
>

>Anyway, let me know when your home computer has more than 4T bytes of RAM a=

>nd I'll think about 64-bit.

My computer may be able to handle more, but my Forth is restricted to
0.1 Tbyte:

~$ lina64 -g 100,000 aap
~$ aap

AMDX86 ciforth 5.3.0
DSP@ HERE -
OK
.
104859592136 OK

BYE

~$ lina64 -g 150,000 aap
~$ aap
Killed

I may be using that much shortly, for counting primes.

[Anton Ertl]

Brad Eckert <hwf...@gmail.com> writes:
>It's Microsoft =
>orphaning 16-bit apps all over again. Their answer to the problem (back in =
>the day): Buy the non-existent 32-bit version of the app. The big differenc=
>e between then and now is that 32 bits is not a wall. The other difference =
>with the 64-bit "revolution" is that 32-bit is too big to break. They can't=

> reasonably get away with it.

Once upon a time DOS was too big to break. So they supported DOS apps
until DOS had lost enough significance. It will be the same way with
32-bit applications. Some others are more aggressive in this regard.
IIRC Apple only allows applications into its app store that can be
made to run on Aarch64, and some people expect that one of the next
iPhone CPUs from Apple will not support 32-bit ARM code.

>However, I don't think linear addr=
>essing is the right way to solve the problem. DRAM of today is like the flo=
>ppy disk of old. Opening or closing a row in a modern DRAM takes something =
>like 50ns, the same amount of time it takes to burst 128 words (1K bytes) i=
>nto cache with a 1.33GHz bus. 1K bytes (128 64-bit words) would cost 64ns. =
>2^32 1K blocks is 2^42 (4T) bytes. It would be nice if DMA would make that =
>transfer non-blocking. Blocks. Remember blocks? Still useful. With data set=
>s beyond 32-bit, do we really have any business doing willy-nilly memory ac=

>cess? Thrashing DRAM rows can slow applications to a crawl.

Yes, but blocks have nothing at all to offer here. Block access will
always be slower; if you access DRAM in an inefficient order through
64-bit addresses, doing the same accesses with blocks is even slower,
and moreover, cumbersome to program. And if you can reorder the
accesses in a way that fits the performance characteristics of DRAM
better, you can do it with direct addressing at least as well as with
blocks, and direct addressing avoids the overhead of blocks.

There used to be hardware where your approach makes more sense: The
SPEs of the Cell processors each had 256KB of local memory, and could
access DRAM only through a DMA engine. Unsurprisingly, the Cell SPEs
were a feature that was used much less in applications than in
marketing, and eventually the whole concept was canceled; not just did
the PlayStation 4 switch to a more conventional architecture, the
plans to use Cell in supercomputers (where "hard-to-program" is
usually not a reason to rethink the approach) were cancelled, too.

[Anton Ertl]

minf...@arcor.de writes:
>I am no OS expert but I once read that for 32-bit applications the Win64
>system emulates a Win32 environment and provides a different set of runtime
>libraries with it.

Yes, something like this. On AMD64 32-bit has a different
architecture (the same instruction bits mean something different than
in the 64-bit architecture) than the 64-bit stuff. 32-bit code is
executed on a 64-bit OS in compatibility mode; when such a program
makes a system call, the CPU switches to 64-bit mode, but of course it
knows that the system call is coming from a program running in
compatibility mode and acts accordingly (essentially every system call
has a 32-bit variant and a 64-bit variant). I expect that it's the
same in ARMv8.

For architectures that run 32-bit and 64-bit code in the same mode,
the OS can use the same system call infrastructure, but has to ensure
that it never hands an address outside the 32-bit range to a 32-bit
application.

>So I fear that the address space >4 gigs is not emulated and CQ@ won't work.
>
>I don't know whether BSD/Linux/OSX behave similarly.

On AMD64 there is no other way to deal with legacy 32-bit code, so
yes, they all deal with it in this way.

There has been an effort to define a 32-bit ABI for AMD64 64-bit mode
(called x32) for Linux, similar in spirit to what the single-mode
architectures do for 32-bit code. That would be a platform for
implementing a 32-bit Forth that could have a CQ@. Of course, if you
use this mode as it is intended, there is no need for a CQ@, because
the OS will never make any address accessible that you cannot access
with C@.

x32 did not catch on; given that we have (32-bit) IA-32 and (64-bit)
AMD64, there is no need for x32; people argued for x32 with
performance advantages, but they were obviously not enough. Lesson
for Forth systems: Just go with 64 bit cells on 64-bit platforms.

The failure of x32 has not been enough of a lesson, so there are
people proposing the same thing for Aarch64 (Aarch64 ILP32); they have
a slightly better case, because there are CPUs in the pipeline that
understand Aarch64, but not 32-bit ARM, and there may still be some
(C/C++) code around that does not port to 64-bit platforms). Still,
even the page presenting this ABI
<https://wiki.linaro.org/Platform/arm64-ilp32> it says:

| This is a very weak reason for a whole new ABI, but it is technically
| possible if people wish to do the work.

My guess is, that like for x32, there will be a lack of people who
wish to do the work.

However, for a Forth system like those of Albert van der Horst that
just deals with system calls and never calls a library function, the
Forth system implementor can do the work: Have 32-bit cells, ask the
OS for addresses in 32-bit space (e.g., with the MAP_32BIT flag of
mmap in Linux), and you have a 32-bit system. And when you then
allocate memory outside the 32-bit range (by not using MAP_32BIT), you
get addresses that need a CQ@ or somesuch. I would not recommend
using such a system, but who knows, maybe it's just what everybody
else in the the world has waited for.

[Hans Bezemer]

minf...@arcor.de Wrote in message:

> 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...
>

4tH itself doesn't care that much for 32bit or 64bit. I already
applied a lot of portable fixes in the library code to cater for
64bit. Some code will run, but suboptimal, but I'm sure I will
weed out these (where applicable) when 4tH-64 becomes the main
version. Already I will supply a 64bit version on the newer libs
(e.g. randjava.4th). So I'm not too afraid of making the
change.

Hans Bezemer
--


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[minf...@arcor.de]

Yeah, I think so since 4th is completely in C.

[Bernd Paysan]

Am Tue, 22 Aug 2017 18:42:28 GMT
schrieb an...@mips.complang.tuwien.ac.at (Anton Ertl):

> gavino himself <jack...@gmail.com> writes:
> >is gforth 64 bit? now?
>
> Gforth has supported 64-bit platforms since 1995.

To be more precise, Gforth had mostly complete support for 64-bit
platforms before we could get one, and then, the major obstacle to get
it running on the first 64 bit platform we got was that GCC's long long
type was broken (back then it was defined "twice as long as long").

--
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/

[Kip Ingram]

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.
>
> 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."

[Marcel Hendrix]

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

[Anton Ertl]

Kip Ingram <kip.i...@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 <2005Apr...@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

[S Jack]

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

[Myron Plichota]

Why don't you spend the time developing a solution that doesn't make you puke?

- Myron

[Myron Plichota]

PS Jimbo is not James Bond

[Paul Rubin]

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.

[S Jack]

Thanks, I learned something.
--
me

[minf...@arcor.de]

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.

[Anton Ertl]

"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? 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.

[minf...@arcor.de]

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.

[Marcel Hendrix]

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

[Stephen Pelc]

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

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, ste...@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

[none albert]

In article <2022Apr1...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Kip Ingram <kip.i...@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

[Stephen Pelc]

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.

[minf...@arcor.de]

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.

[Marcel Hendrix]

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

[Anton Ertl]

Marcel Hendrix <m...@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

[Anton Ertl]

Stephen Pelc <ste...@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 Ertl]

"minf...@arcor.de" <minf...@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.