discussion
discussion copied to clipboard
ForthHub
Has anyone ever thought about making a 128-bit Forth?
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 ; ?
Yes. VLIW (Vary long instruction Word) are interesting to me. I see analog as a infinite bit instruction. It's late for me now.
I recall in my FORTH VLIW experiments, the compiler benefited from variable sized variables, supported by some some automatic stack loading unloading methods, with some literals to specify/override the normal stack load unload methods.
On Mon, Sep 4, 2017 at 11:32 PM, Roger Levy [email protected] wrote:
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 https://github.com/a !A +A A> ADROP ASWAP at a minimum?
Definition of @ would be: : @ @A ADROP ; ?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/53, or mute the thread https://github.com/notifications/unsubscribe-auth/AFC6xSTFQfCMIzJglVrNs4TgkxcFd95Vks5sfM74gaJpZM4PMbkM .
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.