<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