Post #1540793

@tusharhero He, good old SICP. With Forth it's the same but for different reasons: you don't wanna to juggle with the stack by design, you are enforced to modularize you code from day 1. Even for EForth running under subleq/muxleq the system it's small enough to write floating number support, complex numbers, fraction arithmetic... by hand in "userspace", not by low-level Subleq calls. Performance? under Muxleq not much compared to even TCL 7.x with no bytecode, but fast enough to prototype trivial code. Muxleq already gives a huge boost over subleq. And the output for sure will be reproducibe. Then there's some kind of 'JIT' ted Subleq interpreter from the book of the subleq VM author where low level calls are mapped to C ones giving a good boost too for that Eforth, on par maybe on gawk. And if it works fast on that, expect great speeds on current 32 bit microcontrollers. If something like this can be good for engineering contraints, it can be good anywhere (modulo QM levels/ astronomical distances): : pi* 355 113 */ ; 1000 pi* . 3141 If you want more precision, adapt it for double numbers. : pi* 355 113 m*/ ; ok 100.000 pi* d. 314159 ok And Forth is not a fast language, but if your code run fast under Eforth+Subleq, it will be crazy fast under GForth *and* without even needing GMP and the like for big numbers and even float support in hardware. Remember that some Unix engineers with proper C code kicked Nvidia CUDA's ass which lasted 5 months to simulate some complex ice dynamics. The simplified code in plain ANSI C and simple math (math.h) with some off the self 64 bit machine? 15 minutes