Search
Friday, 5th of August 2022, 5:59:49 UTC
12:45:45
drmeister
I think we should implement the interpreter straight into c++. In Common Lisp it will be weird and require more functions to be exposed.
12:46:21
jackdaniel
drmeister: common lisp interpreter?
12:48:19
drmeister
jackdaniel: for testing ideas but it would be more cumbersome than c++
12:49:20
drmeister
Incrementing a pointer, or dereferencing a pointer is so much easier in c++
12:49:21
jackdaniel
ecl has bytecodes compiler and interpreter written in C
12:49:42
drmeister
I know. We are writing one now.
12:49:44
jackdaniel
maybe you have accidently ported it already
12:51:05
drmeister
I don’t understand it. We will probably end up with something similar but with exception handling built in.
12:52:47
jackdaniel
the bytecodes vm is basically a stack machine
12:55:31
drmeister
So will ours be. We are influenced by the clisp design.
12:56:05
drmeister
Does ecl have a side-stack?
12:56:23
Bike
we have a stack machine with a variable size register file, kind of like the jvm as i understand it
12:56:28
drmeister
An additional stack for the cem besides the c stack?
13:04:49
drmeister
Ok - then I feel better about that. How big is it typically?
13:05:34
jackdaniel
a default avlue is 32768 + 128 (safety area)
13:05:43
jackdaniel
it is configurable and resizeable
13:06:00
jackdaniel
ecl has numerous stacks
13:06:25
jackdaniel
bind stack, frame stack, lisp (interpreter) stack, c stack
13:07:17
jackdaniel
all that to ensure seamless integration between native code and the bytecodes vm
13:55:09
drmeister
That's 32768 bytes or quad-words (8-bytes)
14:07:02
jackdaniel
32768 [pointer-size], on 64bit it will be 8-bytes, on 32bit it will be 4-bytes
14:17:47
drmeister
Understood - thank you.
Friday, 5th of August 2022, 17:59:49 UTC