Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
Am Sonntag, 12. April 2020 schrieb Alexander Burger : > Hi Guido, > >> All you need to do, is to let PicoLisp Interpreter convert PicoLisp Source >> into that Lisp dialect, Webassembly VM does understand, and you're done! > > OK, if it is so easy, why don't you do it? I've hoped, you would have an insight, that going that way could bring you lots of revenue. :-/ > Still it doesn't solve the portability issue. I want PicoLisp to run also in iOS > (also MacOS, and other server setups). pil64 is fine (and probably the absolute > optimum in terms of performance), but it can't be ported to e.g. RISC-V. Just a question of time, until Webassembly will be the standard (containered = secure) way of starting processes, microservices on mobiles, Linux Servers in general. That's going quick now, we're already replacing Docker containers by Webassembλy containers for all kinds of microservices: Webassembλy rules RISC-V ... i am playing around with that, recently adapted TCC to the Kendryte 210 Board. Holy fuck, that thing ist fast!!! And cheap! https://www.heise.de/newsticker/meldung/RISC-V-50-Dollar-Entwicklerboard-aus-China-4198639.html uLisp is dominating here: http://www.ulisp.com/show?30X8 Inline RISC-V Assembler brings speedup of upto 1000x ... http://www.ulisp.com/show?30ZU Here the original and assembler accelerated Mandelbrot example: http://forum.ulisp.com/t/mandelbrot-set-using-risc-v-assembler/522 First i've thought, German Industry would hop on microPython, but no ... uLisp on RISC-V is making it. Lisp is much smaller and faster to implement. The fastest growing market of all times ... Embedded Lisp ... Have fun! > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
Hi Guido, > All you need to do, is to let PicoLisp Interpreter convert PicoLisp Source > into that Lisp dialect, Webassembly VM does understand, and you're done! OK, if it is so easy, why don't you do it? Still it doesn't solve the portability issue. I want PicoLisp to run also in iOS (also MacOS, and other server setups). pil64 is fine (and probably the absolute optimum in terms of performance), but it can't be ported to e.g. RISC-V. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
Hi Alex! Maybe, i am repeating myself. But Webassembly containers use LLVM already. https://github.com/WAVM/WAVM/blob/master/README.md All you need to do, is to let PicoLisp Interpreter convert PicoLisp Source into that Lisp dialect, Webassembly VM does understand, and you're done! Greetings from another universe ... Have fun! Am Sonntag, 12. April 2020 schrieb Alexander Burger : > On Sun, Apr 12, 2020 at 10:36:58AM +0200, Guido Stepken wrote: >> Why porting Picolisp onto LLVM, when there already is a JIT compiler in >> every Webassembly container, that accepts Lisp code? > > The answer is "portability" > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
On Sun, Apr 12, 2020 at 10:36:58AM +0200, Guido Stepken wrote: > Why porting Picolisp onto LLVM, when there already is a JIT compiler in > every Webassembly container, that accepts Lisp code? The answer is "portability" -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
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 >
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
Hi Rowan, > 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 Not at all. It is perfectly as I see it too :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
Rowan Thorpe writes: > 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." because picolisp doesn't have a compiler (program) it is "compiled" to the picolisp assembly manually ahead of time by Alex (human) once you have a compiler (lisp program), parenthesis make sense because they simply show lisp datastructures manipulated by the compiler you can write lisp without parenthesis in similar spirit (see common lisp loop for example) but that is rather "ugly" -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!
On Sun, 12 Apr 2020 at 01:04, Guido Stepken wrote: > Hello, all! > > It might sound a little bit weird, when i tell you, that recently > standardized Webassembly Containers in your browser are - Lisp machines. 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
Did you know? Webassembly Containers are (Pico-)Lisp machines!
Hello, all! It might sound a little bit weird, when i tell you, that recently standardized Webassembly Containers in your browser are - Lisp machines. Emscripten C/C++ "emcc" compiler does not translate into machine code directly, but rather some kind of meta machine code (Intermediate Bytecode), that the processor (Intel, ARM, ...) then can easily JIT - transform into its final, executable machine code. That Intermediate Bytecode, in fact, is a pure Lisp, just like PicoLisp is: https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format PicoLisp and Webassembly containers have a lot in common. They even have same capabilities, features. Nothing speaks against letting PicoLisp run directly in a browser container or - serverside as Webassembly container. PicoLisp thus - was far ahead of its time! Here a famous quote by the Docker inventor on twitter: https://twitter.com/solomonstre/status/004913222324225 Solomon Hykes @solomonstre If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! PicoLisp *is* a genius strike, but some get it at least a decade later ... :-( Even Microsoft now is on the train to port its ASP DOTNET CORE 3.0 Blazor Library onto Webassembly Lisp: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://github.com/AdrienTorris/awesome-blazor/blob/master/README.md It's just ridiculous! Have fun! Happy easter and keep away from Windows and other viruses! Guido Stepken
