Subscribe
--
Keenan Paul Lynch
Software Craftsmen - {.NET, Web}
*[image: Image result for coding]*
Controlling complexity is the essence of computer programming.
Re: Pil21 on NetBSD9/aarch64
On Sun, Apr 12, 2020 at 06:25:11PM +0200, Alexander Shendi (Web.DE) wrote: > 1. Yes, Makefile and lib.c as included in pil21/src. > ... > The problem is that I can't regenerate the bitcode files from the Lisp files. > Otherwise the executable seems to work fine. Good to know. Concerning the build of the *.ll files, there is no other way than a running pil64, either for that platform, or emu, or cross-built on another platform (for example, I build on Termux/Android). > The question is: Do you or the current maintainer want these changes? Yes, please. There is no maintainer yet, we are in the raw metal early development phase. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pil21 on NetBSD9/aarch64
Hi all 1. Yes, Makefile and lib.c as included in pil21/src. 2. No, I built pil21/bin/picolisp directly. The two bitcode files base.bc and ext.bc were already included and I was able to build lib.bc from the modified lib.c (with the clang C compiler). After that I just typed: touch *.bc ; make. The problem is that I can't regenerate the bitcode files from the Lisp files. Otherwise the executable seems to work fine. The question is: Do you or the current maintainer want these changes? Best Regards, Alexander Am 12. April 2020 17:42:47 MESZ schrieb Alexander Burger : >Hi Alexander, > >> Sorry to follow up on my own post, but with some hacking at lib.c and >changing >> the Makefile I was able to bootstrap a working picolisp binary. > >The lib.c and Makefile in pil21/src/? So it worked with emu? > > >> However I can't seem to be able to regenerate the *.bc files from the >Lisp files. Two questions: >> >> 1. would anyone be interested in the changes I made? And who is the >maintainer? > >What changes are those? > >> 2. Any suggestions how to rebuild the system? Do I need a standard >picolisp (i.e. http://software-lab.de/picoLisp.tgz) install? > >Yes, download and unpack that TGZ, then "make emu" in the src64/ >directory. >Then, in pil21/src, change the path to 'pil' to the proper path, e.g > > $ tar xvfz picoLisp.tgz > $ (cd picoLisp/src64; make emu) > $ cd pil21/src/ > >Change the two "pil" calls to "../../picoLisp/pil", or plant a symbolic >link to that 'pil' etc. > > $ make > >☺/ A!ex > > >-- >UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- You have zero privacy anyway. Get over it. Scott McNealy 1999
Re: Interning symbols in lib/simul.l
thank you! On Sun, Apr 12, 2020 at 2:01 AM Mike wrote: > > I'm studying lib/sumul.l, specifically the 'grid function. > > In my repo you would find a lot of usage examples for grid: > https://git.envs.net/mpech/tankf33der/ > > (mike) > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
Re: Pil21 on NetBSD9/aarch64
Hi Alexander, > Sorry to follow up on my own post, but with some hacking at lib.c and changing > the Makefile I was able to bootstrap a working picolisp binary. The lib.c and Makefile in pil21/src/? So it worked with emu? > However I can't seem to be able to regenerate the *.bc files from the Lisp > files. Two questions: > > 1. would anyone be interested in the changes I made? And who is the > maintainer? What changes are those? > 2. Any suggestions how to rebuild the system? Do I need a standard picolisp > (i.e. http://software-lab.de/picoLisp.tgz) install? Yes, download and unpack that TGZ, then "make emu" in the src64/ directory. Then, in pil21/src, change the path to 'pil' to the proper path, e.g $ tar xvfz picoLisp.tgz $ (cd picoLisp/src64; make emu) $ cd pil21/src/ Change the two "pil" calls to "../../picoLisp/pil", or plant a symbolic link to that 'pil' etc. $ make ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Pil21 on NetBSD9/aarch64
Hi again, Sorry to follow up on my own post, but with some hacking at lib.c and changing the Makefile I was able to bootstrap a working picolisp binary. However I can't seem to be able to regenerate the *.bc files from the Lisp files. Two questions: 1. would anyone be interested in the changes I made? And who is the maintainer? 2. Any suggestions how to rebuild the system? Do I need a standard picolisp (i.e. http://software-lab.de/picoLisp.tgz) install? Many thanks in advance, Alexander Am 12. April 2020 15:16:30 MESZ schrieb "Alexander Shendi (Web.DE)" : >Dear Lisp, > >Happy Easter! > >I have tried building pil21 under NetBSD 9/aarch64. I tried to use >Ersatz-picolisp under OpenJDK8 to generate the *.ll files to bootstrap >pil21, but it seems some language constructs used in llvm.l are not >supported. > >What is the best way to work around thus? TIA. > >Best Regards and stay safe, > >Alexander > > >-- >You have zero privacy anyway. Get over it. > >Scott McNealy 1999 -- You have zero privacy anyway. Get over it. Scott McNealy 1999
Re: Pil21 on NetBSD9/aarch64
Hi Alexander, > I have tried building pil21 under NetBSD 9/aarch64. I tried to use > Ersatz-picolisp under OpenJDK8 to generate the *.ll files to bootstrap pil21, > but it seems some language constructs used in llvm.l are not supported. Unfortunately, neither Ersatz, nor pil32 or miniPicoLisp can be used to bootstrap pil21. It needs the namespaces (and possibly other things) from pil64. Not sure ATM whether NetBSD is supported in pil64's build process. But you could try to build 'emu' (cd src64; make emu) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Pil21 on NetBSD9/aarch64
Dear Lisp, Happy Easter! I have tried building pil21 under NetBSD 9/aarch64. I tried to use Ersatz-picolisp under OpenJDK8 to generate the *.ll files to bootstrap pil21, but it seems some language constructs used in llvm.l are not supported. What is the best way to work around thus? TIA. Best Regards and stay safe, Alexander -- You have zero privacy anyway. Get over it. Scott McNealy 1999
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: Towards a more readable Pico(Lisp) ... nobody needs parenthesis!
Like that WISP example. Indendation here replaces "("
https://wiki.gnome.org/Projects/Genie#Block_Indentation
Same for Python.
Means: Lisp code generally can be stripped off most brackets without losing
"meaning". And it should. For readabilty reasons, public acceptance - and
typing speed: With German Keyboard typing {([ ])}; is no fun!
Happy Easter!
Am Sonntag, 12. April 2020 schrieb :
> Looks a lot like Sweet[0] or WISP[1] to me!
> They are defined for Scheme, but can be used for any sexprs.
>
>
> Sweet example:
>
> define factorial(n)
> if {n <= 1}
> 1
> {n * factorial{n - 1}}
>
>
> WISP example:
>
> define : factorial n
> __ if : zero? n
> . 1
> * n : factorial {n - 1}
>
>
> [0] https://srfi.schemers.org/srfi-110/srfi-110.html
> [1] https://srfi.schemers.org/srfi-119/srfi-119.html
>
> --
>/c
>
> --
> 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: PicoLisp Sources
Hi Alex!
You might perhaps have noticed, that modern CPUs execute "unoptimized"
compiler code almost as fast as code produced by highly optimizing
compilers (-Os vs. -O3). Difference is almost zero!
You also might have noticed, that AMD with EPYC Rome and Threadripper are
far ahead of Intel in terms of IPC - Instructions Per Clockcycle.
That has to do with long instruction prefetch queues, a new neural "branch
prediction" and new, highly sophisticated translators from ISA instructions
into internal microcode.
I can tell you, that "SSA" tricks, such as PHI() optimizations, "register
renaming", ... all that stuff alredy has moved into the processor itself. 2
megabytes (that's the size of a full processor microcode update!) of
processor - internal "post machine code optimization" - code makes that
possible.
On AMD EPYC, even speed of completely unoptimized TCC machine code comes
quite close to - hundreds of years of intelligent man/womenpower optimized
- GCC/LLVM compiler code. Difference is negligible.
https://en.wikipedia.org/wiki/Static_single_assignment_form
These "SSA idea" is going back to 1988. Today is 2020, that's 32 years
later.
Have fun!
Guido Stepken
Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> On Sun, Apr 12, 2020 at 08:09:46AM +0200, Tomas Hlavaty wrote:
>> 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)
>
> Actually, all this will change with the new PicoLisp "pil21". It is no
longer
> oriented to machine *instructions* like pil64, but to SSA (Static Single
> Assignment) *values*.
>
> It is a radically different approach. If there is interest, work in
progress can
> be seen at
>
>https://git.envs.net/mpech/pil21
>
> or directly in
>
>https://software-lab.de/pil21.tgz
>
> Here the sources have real PicoLisp syntax (though partially different
> semantics). The compiler (in "src/lib/llvm.l") does not only use the
reader, but
> generates the LLVM-IR by *executing* the code (Forth is chuckling from
behind).
>
> This works by simply redefining some (not many) functions in llvm' and
'priv'
> namespaces.
>
>
> For example, the source of the 'car' function:
>
> In pil64 it is (in "src64/subr.l")
>
># (car 'var) -> any
>(code 'doCar 2)
> push X
> ld X E
> ld E ((E CDR)) # Get arg
> eval
> num E # Need variable
> jnz varErrEX
> ld E (E) # Take CAR
> pop X
> ret
>
> This results in e.g. AMD/Intel asssembly (in "src64/x86-64.linux.base.s")
>
> .globl doCar
>doCar:
> push %r13
> mov %rbx, %r13
> mov 8(%rbx), %r10
> mov (%r10), %rbx
> test $0x06, %bl
> jnz 1f
> test $0x08, %bl
> cmovnzq (%rbx), %rbx
> jnz 1f
> call evListE_E
>1:
> testb$0x06, %bl
> jnz varErrEX
> mov (%rbx), %rbx
> pop %r13
> ret
>
>
> Now in pil21 the source is (in "src/subr.l"):
>
># (car 'var) -> any
>(de _car (Exe)
> (car (needVar Exe (eval (cadr Exe )
>
> and the result in LLVM-IR is (in "src/base.ll"):
>
>define i64 @_car(i64) {
>$1:
>; # (cadr Exe)
> %1 = inttoptr i64 %0 to i64*
> %2 = getelementptr i64, i64* %1, i32 1
> %3 = load i64, i64* %2
> %4 = inttoptr i64 %3 to i64*
> %5 = load i64, i64* %4
>; # (eval (cadr Exe))
> %6 = and i64 %5, 6
> %7 = icmp ne i64 %6, 0
> br i1 %7, label %$4, label %$3
>$4:
> br label %$2
>$3:
> %8 = and i64 %5, 8
> %9 = icmp ne i64 %8, 0
> br i1 %9, label %$6, label %$5
>$6:
> %10 = inttoptr i64 %5 to i64*
> %11 = load i64, i64* %10
> br label %$2
>$5:
> %12 = call i64 @evList(i64 %5)
> br label %$2
>$2:
> %13 = phi i64 [%5, %$4], [%11, %$6], [%12, %$5] ; # ->
>; # (needVar Exe (eval (cadr Exe)))
> %14 = and i64 %13, 6
> %15 = icmp ne i64 %14, 0
> br i1 %15, label %$7, label %$8
>$7:
> call void @varErr(i64 %0, i64 %13)
> unreachable
>$8:
>; # (car (needVar Exe (eval (cadr Exe
> %16 = inttoptr i64 %13 to i64*
> %17 = load i64, i64* %16
> ret i64 %17
>}
>
> Looks unbelievably horrible, but works ;)
>
> ☺/ A!ex
>
> --
> 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: Towards a more readable Pico(Lisp) ... nobody needs parenthesis!
Quoting Guido Stepken :
Hi all!
Parenthesis sometimes unneccessarily seem to keep people away from Lisp as
"all day programming language". It's confusing their brain.
How about this "innovative" new Lisp syntax?
https://github.com/birchb1024/genyris/blob/master/examples/queens.g
It's the more readable version, compare to this original version here:
http://obereed.net/queens/algorithm.html
Reminds me a bit of Python or Julia ... or rather - Swift?
Looks a lot like Sweet[0] or WISP[1] to me!
They are defined for Scheme, but can be used for any sexprs.
Sweet example:
define factorial(n)
if {n <= 1}
1
{n * factorial{n - 1}}
WISP example:
define : factorial n
__ if : zero? n
. 1
* n : factorial {n - 1}
[0] https://srfi.schemers.org/srfi-110/srfi-110.html
[1] https://srfi.schemers.org/srfi-119/srfi-119.html
--
/c
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PicoLisp Sources
Happy Easter, Alex!
Nothing brings me to waste just a second on LLVM compiler suite. And i
directly will tell you why:
https://bellard.org/otcc/
OTCC is a C compiler implemented in 2048 bytes of code. It can compile
itself and translates to 386 machine code. Fully 'Turing complete'! Its
successor, TCC, can compile even Linux onto ARM, Intel, is slighly longer.
420 Megabytes .tgz LLVM can neither be understood nor *security reviewed*
-> dustbin!
No security review, no run on my machines. It's as simply as that!
I am too old for Russian Roulette. I am an engineer, not a priest, praying,
hoping for, that Microsoft, Apple haven't injected some evil code into the
compiler, as seen here:
https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/
*Not for a second* i do consider wasting my time on (by US law!) NSA
poisoned, backdoored US software stacks any longer! We have plenty of
alternatives in Europe.
Keep away from Windows and other viruses!
Have fun!
Guido Stepken
Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> On Sun, Apr 12, 2020 at 08:09:46AM +0200, Tomas Hlavaty wrote:
>> 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)
>
> Actually, all this will change with the new PicoLisp "pil21". It is no
longer
> oriented to machine *instructions* like pil64, but to SSA (Static Single
> Assignment) *values*.
>
> It is a radically different approach. If there is interest, work in
progress can
> be seen at
>
>https://git.envs.net/mpech/pil21
>
> or directly in
>
>https://software-lab.de/pil21.tgz
>
> Here the sources have real PicoLisp syntax (though partially different
> semantics). The compiler (in "src/lib/llvm.l") does not only use the
reader, but
> generates the LLVM-IR by *executing* the code (Forth is chuckling from
behind).
>
> This works by simply redefining some (not many) functions in llvm' and
'priv'
> namespaces.
>
>
> For example, the source of the 'car' function:
>
> In pil64 it is (in "src64/subr.l")
>
># (car 'var) -> any
>(code 'doCar 2)
> push X
> ld X E
> ld E ((E CDR)) # Get arg
> eval
> num E # Need variable
> jnz varErrEX
> ld E (E) # Take CAR
> pop X
> ret
>
> This results in e.g. AMD/Intel asssembly (in "src64/x86-64.linux.base.s")
>
> .globl doCar
>doCar:
> push %r13
> mov %rbx, %r13
> mov 8(%rbx), %r10
> mov (%r10), %rbx
> test $0x06, %bl
> jnz 1f
> test $0x08, %bl
> cmovnzq (%rbx), %rbx
> jnz 1f
> call evListE_E
>1:
> testb$0x06, %bl
> jnz varErrEX
> mov (%rbx), %rbx
> pop %r13
> ret
>
>
> Now in pil21 the source is (in "src/subr.l"):
>
># (car 'var) -> any
>(de _car (Exe)
> (car (needVar Exe (eval (cadr Exe )
>
> and the result in LLVM-IR is (in "src/base.ll"):
>
>define i64 @_car(i64) {
>$1:
>; # (cadr Exe)
> %1 = inttoptr i64 %0 to i64*
> %2 = getelementptr i64, i64* %1, i32 1
> %3 = load i64, i64* %2
> %4 = inttoptr i64 %3 to i64*
> %5 = load i64, i64* %4
>; # (eval (cadr Exe))
> %6 = and i64 %5, 6
> %7 = icmp ne i64 %6, 0
> br i1 %7, label %$4, label %$3
>$4:
> br label %$2
>$3:
> %8 = and i64 %5, 8
> %9 = icmp ne i64 %8, 0
> br i1 %9, label %$6, label %$5
>$6:
> %10 = inttoptr i64 %5 to i64*
> %11 = load i64, i64* %10
> br label %$2
>$5:
> %12 = call i64 @evList(i64 %5)
> br label %$2
>$2:
> %13 = phi i64 [%5, %$4], [%11, %$6], [%12, %$5] ; # ->
>; # (needVar Exe (eval (cadr Exe)))
> %14 = and i64 %13, 6
> %15 = icmp ne i64 %14, 0
> br i1 %15, label %$7, label %$8
>$7:
> call void @varErr(i64 %0, i64 %13)
> unreachable
>$8:
>; # (car (needVar Exe (eval (cadr Exe
> %16 = inttoptr i64 %13 to i64*
> %17 = load i64, i64* %16
> ret i64 %17
>}
>
> Looks unbelievably horrible, but works ;)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Subscribe
Hello Domingo Alvarez Duarte :-) You are now subscribed Hello ! Happy to join ! -- 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 >
PicoLisp Sources
On Sun, Apr 12, 2020 at 08:09:46AM +0200, Tomas Hlavaty wrote:
> 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)
Actually, all this will change with the new PicoLisp "pil21". It is no longer
oriented to machine *instructions* like pil64, but to SSA (Static Single
Assignment) *values*.
It is a radically different approach. If there is interest, work in progress can
be seen at
https://git.envs.net/mpech/pil21
or directly in
https://software-lab.de/pil21.tgz
Here the sources have real PicoLisp syntax (though partially different
semantics). The compiler (in "src/lib/llvm.l") does not only use the reader, but
generates the LLVM-IR by *executing* the code (Forth is chuckling from behind).
This works by simply redefining some (not many) functions in llvm' and 'priv'
namespaces.
For example, the source of the 'car' function:
In pil64 it is (in "src64/subr.l")
# (car 'var) -> any
(code 'doCar 2)
push X
ld X E
ld E ((E CDR)) # Get arg
eval
num E # Need variable
jnz varErrEX
ld E (E) # Take CAR
pop X
ret
This results in e.g. AMD/Intel asssembly (in "src64/x86-64.linux.base.s")
.globl doCar
doCar:
push %r13
mov %rbx, %r13
mov 8(%rbx), %r10
mov (%r10), %rbx
test $0x06, %bl
jnz 1f
test $0x08, %bl
cmovnzq (%rbx), %rbx
jnz 1f
call evListE_E
1:
testb$0x06, %bl
jnz varErrEX
mov (%rbx), %rbx
pop %r13
ret
Now in pil21 the source is (in "src/subr.l"):
# (car 'var) -> any
(de _car (Exe)
(car (needVar Exe (eval (cadr Exe )
and the result in LLVM-IR is (in "src/base.ll"):
define i64 @_car(i64) {
$1:
; # (cadr Exe)
%1 = inttoptr i64 %0 to i64*
%2 = getelementptr i64, i64* %1, i32 1
%3 = load i64, i64* %2
%4 = inttoptr i64 %3 to i64*
%5 = load i64, i64* %4
; # (eval (cadr Exe))
%6 = and i64 %5, 6
%7 = icmp ne i64 %6, 0
br i1 %7, label %$4, label %$3
$4:
br label %$2
$3:
%8 = and i64 %5, 8
%9 = icmp ne i64 %8, 0
br i1 %9, label %$6, label %$5
$6:
%10 = inttoptr i64 %5 to i64*
%11 = load i64, i64* %10
br label %$2
$5:
%12 = call i64 @evList(i64 %5)
br label %$2
$2:
%13 = phi i64 [%5, %$4], [%11, %$6], [%12, %$5] ; # ->
; # (needVar Exe (eval (cadr Exe)))
%14 = and i64 %13, 6
%15 = icmp ne i64 %14, 0
br i1 %15, label %$7, label %$8
$7:
call void @varErr(i64 %0, i64 %13)
unreachable
$8:
; # (car (needVar Exe (eval (cadr Exe
%16 = inttoptr i64 %13 to i64*
%17 = load i64, i64* %16
ret i64 %17
}
Looks unbelievably horrible, but works ;)
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Lisp, a language for "Stratified Design" Podcast and paper.pdf
Me too, love the podcast, thanks for sharing!! Happy Easter everyone!! BR, Geo On Sunday, 12 April 2020, 01:49:21 pm GMT+9, C K Kashyap wrote: Thanks for sharing ... loved the podcast! Regards, Kashyap On Fri, Apr 10, 2020 at 2:28 PM Guido Stepken wrote: > A highly inspiring, philosophical Podcast about Abstractions in Lisp, that - > until today - you simply can't do in other programming languages: > > https://podcasts.google.com/?q=Lisp+stratified > > https://www.researchgate.net/profile/Gerald_Sussman/publication/37596906_Lisp_A_Language_for_Stratified_Design/links/53d142ce0cf220632f392c19/Lisp-A-Language-for-Stratified-Design.pdf > > Also see that strage discussion about PicoLisp and 'Graph Database': > > https://www.mail-archive.com/picolisp@software-lab.de/msg09451.html > > Even with a Bachelor in Computer Science, people simply don't get the power > of Picolisp. They don't see the forest for the trees. > > Have fun listening! > > Guido Stepken > > > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Interning symbols in lib/simul.l
> I'm studying lib/sumul.l, specifically the 'grid function. In my repo you would find a lot of usage examples for grid: https://git.envs.net/mpech/tankf33der/ (mike) -- 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: Interning symbols in lib/simul.l
Hi Bruno,
> I'm studying lib/sumul.l, specifically the 'grid function. I understand how
> it works now, but I have two doubts:
>
> 1) why are symbols in the grid interned?
> ...
>(if (> DX 26)
> (box)
> (intern (pack (char (+ X 96)) Y)) ) ) # why
It is just to conveniently access them by name (e.g. a1 - z1), in programs and
during debugging. For example in "games/chess.l":
(bookMove 'd2 'd4)
or
$ pil games/chess.l -main +
...
: (go d2 d4)
...
-> ("BlackPawn" d7 . d5)
: (show 'd4)
d4 ((c4 . e4) d3 . d5)
piece "WhitePawn"
x 4
whAtt ("WhiteQueen")
color
y 4
-> d4
> 2) what does the F in FX and FY stand for?
> ...
> (de grid (DX DY FX FY)
> ...
> (let West (and FX (last Grid))
It stands for "Flag", as these parameters are boolean values.
☺/ 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
