beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: | Check for more information
geri has joined #picolisp
<geri> hey, is picolisp's vm stack or register based?
<geri> considering it was ported to hardware and is very performant id guess register-based , but im not very good at understanding language vms haha
<bjorkintosh> why would it matter if it were register or stack?
<bjorkintosh> they can both be put on bare iron.
<geri> idk man, i still cant get over the fact its not tree based
<geri> lol
<bjorkintosh> should it be?
<geri> i thought like every language were haha
<geri> i unironically have no idea, just trying to understand how it works
<bjorkintosh> i'm sure a b u [ 7 ] knows the ins and outs.
<bjorkintosh> trying not to alert them since I suspect its late.
<geri> its early :)
<bjorkintosh> yes. too early, for them, too late for me.
<geri> its nice and peaceful early in the mornings
_whitelogger has joined #picolisp
<abu[7]> Yeah, still early. Good morning! :)
<abu[7]> Logically it is stack based, there is no concept of registers
<abu[7]> Physically the target CPU uses registers, unless it is a FORTH CPU or similar
<abu[7]> On the Le LLVM level it is a machine with an infinite number of registers (SSA, Static Single Assignment)
<geri> okay, good to know
_whitelogger has joined #picolisp
<geri> hey i got more silly questions - how does it work that picolisp is not byte compiled but has a virtual machine? :D
<abu[7]> You mean that a VM needs bytecode?
<geri> i thought it does at least
<abu[7]> A VM may even run native code, e.g. if qemu emulates Arm or PowerPC code on x86
<geri> what does picolisp vm run then? :D
<abu[7]> It runs or cells instead of bytes :)
<geri> hmmm
<geri> another question - let's say i setq X to be 20, and there's apparently no variable lookup right? next time i write X into repl for example, what happens during/after (read)?
<geri> well, during i guess it just read from a stream and allocates cells, like (+ 1 2) becomes an actual list (chain of cells), but then again, that's kind of AST, no?
<geri> but it's got a VM...
<geri> confusion!
<abu[7]> The reader finds 'X', and eval accesses the value
<geri> so setq interns it so reading it again returns the already interned symbol?
<abu[7]> setq is independent of that
<abu[7]> Just 'read' finds the symbol
<geri> oh well i guess the reader interns it and setq sets the value of that found/interned symbol
<geri> okay..
<geri> now just gotta find out how interning works :D
<abu[7]> (namespace lookup)
<abu[7]> Yes, 'intern'
<geri> where/how are interned symbols stored?
<geri> i think that might be related to the DB, sec
<geri> okay, internal symbols are added to index structure
<abu[7]> No, they are only stored in the namespace
<abu[7]> : pico
<abu[7]> : (namespaces T)
<geri> oh
<geri> is it an enum?
<geri> i mean pico symbol
<geri> or namespaces in general
<abu[7]> A namespace is a symbol, its value is two 'idx' trees
<abu[7]> as a cons pair
<geri> okay, now it makes sense :D
<abu[7]> ☺
<geri> so basically there's no variable lookup, but there's like symbol lookup?
<geri> you find the symbol itself in the namespace and it points directly to the value of itself
<abu[7]> Only at read time
<abu[7]> At runtime there is no lookup
<geri> you mean like you get the symbol's value directly from the symbol itself instead of relying on like hash tables?
<abu[7]> T
<geri> okay
<geri> more I know
<geri> :D
<abu[7]> One pointer indirection
<geri> instead of hashing + pointer indirection and maintaining a hash table code on top of that
<geri> is interning fast?
<abu[7]> Not so fast, it involves a tree lookup
<geri> i wonder if strings get interned in other lisps
<geri> apparently no
<abu[7]> I think so too
<geri> meanwhile in pico transient symbols get interned too, plus its using a tree search vs a hash table
<geri> so reading should technically be slow? 🤔
<abu[7]> Yes. A bit
<geri> good to know
<geri> although it isnt really noticable
<abu[7]> But the transiert tree is small
<abu[7]> T
<geri> its really amazing how much you can do with linked lists with pretty good performance on top of that
<beneroth> as long as its a short list (short being probably in the range of 100s easily still), the linked list is still faster than the additional overhead for a tree or dictionary
<geri> doesnt it depend on how many times you look stuff up?
<abu[7]> Each single lookup takes the same time
<geri> oh wait, hash table overhead like doing hashing?
<geri> i thought like allocating a hash table for some reason
<abu[7]> hashing a value may take longer than traversing a short list
<geri> okay, got it
<bjorkintosh> geri, archival information on (one of?) the ancestors of picolisp:
<geri> wasn't (8? 16? 32?) bit lisp its ancestor?
<geri> i dont remember the name clearly...
<geri> that
<bjorkintosh> I thought portable standard lisp was at least a close cousin.
<geri> oh, 8k uses <'s and ['s, kinda weird
<geri> <'s are superparens?
<abu[7]> Yes, very different
<geri> ive come to understand that i dont really like superparens too much either, only because its hard to jump between parens
<geri> you can jump from anywhere to closing superparen but you can't jump from a superparen to where you wanna go
<geri> only to outermost paren
<geri> gotta go, enjoy the day
<abu[7]> ☺/
geri has quit [Quit: ERC (IRC client for GNU Emacs 29.3)]
pablo_escoberg has joined #picolisp
inara has quit [Quit: Leaving]
inara has joined #picolisp