Has anyone ever thought about making a 128-bit Forth?
Opened this issue · 4 comments
If I had infinite time, I'd create a 128-bit Forth that used SIMD instructions to manipulate 4 values at all times, the "cell" size would be 128-bits containing 4 32-bit values and maybe sometimes 2 64-bit values.
+
for ex. would add together 8 values returning 4.
It might require the use of an address stack. @ and friends might work somewhat as normal; address-defining words like CREATE would actually push to the address stack which would have its own stack manipulation words. >A A! A@ @A !A +A A> ADROP ASWAP
at a minimum?
Definition of @ would be: : @ @A ADROP ;
?
Its an interesting problem ...
@RogerLevy when I was building webForth, I abstracted out knowledge of the CELL size which was only partially done in eForth which was my starting point. I have javascript based versions that support 16,24, or 32 bit cell size and the same base code produces sketches in C for both Arduino (16 bit) and ESP8266 (32 bit). Going to 128 bit would take a bit of work but not over much to port a couple of the math functions (since JS is natively 32 bit) and to adapt the memory handler for larger words
I don't see the use case, unless you have hardware that natively supports 128-bit loads and stores. Lacking such hardware, an operation on 128-bit data is exactly equivalent at the machine instruction level to an operation on a pair of 64-bit cells. Only when true 128-bit hardware is available - and especially when the address space is 128 bits - will there be any advantage of a 128-bit cell size.
The advantage I presume would be ease of programming, if your data is 128 bits, since i've not worked on anything with that size of data. But even if I didn't see the use case either I'm assuming Roger might have had a reason, and just pointing out that I had tried (and succeeded for the 16,24,32 bit cases which i do have use cases for) to make webForth cell-size independent.