Happy Easter, Rowan! Unlike (Pico-)Lisp, where operator comes first "> (+ 2 3)" Forth is *Reverse Polish notation*, so (2) values are pushed onto a stack and operator (+) comes last "> 3 2 +". That's von Neumann friendly in so far, as CPU also has to load values first and then calls the add() function: "Prefix" and "Postfix" notation.
Next evolutionary step in interpreter/compiler technology were (split) multistacks and "named stack" engines, as with one stack only, as now happens in my SISC Computer, things are quickly piling up, plenty of unproductive in-between operations needed, like in Towers of Hanoi problem, which goes with 2^N-1, but with far less, when you can use far more than just 3 piles (stacks). That brought the GCC developers to the "endless registers" machine. GCC, in fact, is translating the code into some abstract Intermediate Code, where the CPU initially has endless number of registers and the Lisp like "MELT" language then reduces that problem to a multi-stack problem with number of registers, the individual target CPU has. That's the secret behind the portability of GCC. And this is, how i made my compiler for my experimental SISC machine. Building that "MOV Fuscator" is a piece of cake. Just set - deeply inside GCC - the number of available registers to 1 in MELT optimization layer and there u are: https://github.com/xoreaxeaxeax/movfuscator/blob/master/README.md Means: The transition from "stack engine" to "register engine" is fluent. Does your CPU have more (orthogonal) registers, the less "stack work" (compare to Towers of Hanoi problem with increasing number of piles) is needed. Code becomes more compact, CPU gets faster. See Motorola 68000 design, a genius strike. Is super easy to write highly optimizing compilers for. Back to Webassembly: You just have to transpile PicoLisp code into WASM S-Expressions: https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API let the Webassembly Container translate that into machine code, do the work. Finished is your PicoLisp JIT engine. Why porting Picolisp onto LLVM, when there already is a JIT compiler in every Webassembly container, that accepts Lisp code? The only thing, Alex would have to do, is to translate (Pico-)Lisp into (Webassembly-) Lisp or S-Expressions. Piece of cake! Have fun! > Aside from the surface syntactic similarities due to the use of > s-expressions in the text format, I think the better > content-comparison of WebAssembly is to a register machine (hence > "assembly" in the name, but something closer to the LLVM IR - which > can be JITted or statically compiled - feels like a good comparison), > as opposed to lisp which is functional. I used to think of it as being > like other stack-machine languages like Forth (or even the JVM), and > the design rationale at https://webassembly.org/docs/rationale/ even > describes it as "a structured stack machine", but > http://troubles.md/posts/wasm-is-not-a-stack-machine/ explains why > this is not quite accurate. Also several Forths (like gforth) are > considered "stack-machine implementations" due to being a forth, but > they can use registers in addition to the typical 2-stack forth core, > so the stack/register boundary gets a little fuzzy there too. When I > first read about WebAssembly the thought that hit me was not that it > was like Picolisp but that it is very similar to the 64-bit assembly > written for and used at the core of the 64-bit Picolisp > implementation, except that - unlike WebAssembly's text format - there > parentheses are not used because as is stated at > https://picolisp.com/wiki/?src64 "Assembly language is not a > functional language, i.e. the individual instructions do not "return" > a value. So a fully parenthesized syntax is useless and just tedious." > > By the way what I love most about Picolisp is that it feels like as > good a hybrid as you can get between the "typical functional > lisp/scheme" mental model and something that feels "forth-like" in > terms of minimalism/precision/close-to-the-metal von-neumann > architecture-friendliness. I describe it to friends as "as close as > you can get a lisp to forth while still being able to call it a lisp" > (I hope Alex doesn't hate that oversimplification too much, if he has > a better soundbite-way to capture the core of that sentiment I'd be > keen to hear it and would be happy to modify my soundbite). My two > favourite programming idioms are lisp and forth (rust comes third, and > part of its coolness is its comprehensive support for compiling to > webasm, which is why I started learning rust). > > -- > Rowan Thorpe > http://twitter.com/rowanthorpe > PGP fingerprint: 92FA 6C6F ABF2 C1B2 7E1C 7CCD 131F D7A9 542F 12F0 > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
