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...
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.
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.
First time I dumped a 32-bit Forth I wanted to puke; where's the code, nothing but a bunch of zero'sWhy don't you spend the time developing a solution that doesn't make you puke?
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:PS Jimbo is not James Bond
First time I dumped a 32-bit Forth I wanted to puke; where's the code, nothing but a bunch of zero'sWhy don't you spend the time developing a solution that doesn't make you puke?
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
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!
S Jack <sdwj...@gmail.com> writes:Thanks, I learned something.
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 <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.
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.
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" <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?
So, there is no need for maintenance for new CPU generations.
"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 :--)
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.
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
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,I believe the commercial implementations moved from threaded code to
nothing but a bunch of zero's and small splattering of one's!
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.
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.
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.
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.
The bigger problem is that ISAs have become baroque in the last 10 years or >so.
RISC-V is no better than the rest!
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 44:34:16 |
| Calls: | 6,710 |
| Calls today: | 3 |
| Files: | 12,243 |
| Messages: | 5,354,111 |