4 ms·

"Bytecode is first-class, can be printed and read, and is human readable (the representation is a string of normal low-ASCII characters)." Anyone know where I

"Bytecode is first-class, can be printed and read, and is human readable (the representation is a string of normal low-ASCII characters)." Anyone know where I can read more about the VM and its human-readable syntax? I'm not immediately spotting it in the repo.

KenoFischer 7y ago
It's not really documented, but human readable, may also not really mean what you think it means. For example, here's a snippet from the printed bytecode of the default system image: #fn("8000r1e0~|[316>0\x7fM~|[i2i343;];" [closure?])] find-in-f) #fn(";000r2c0~|}q3c1tg66I0c2e3c4c5e6g63132c73241;c8;" [#fn("8000r0c0c1~\x7fq2i2322^;" [#fn(for-each) #fn("8000r1~M|\x7f_43;" [])]) #fn("6000r1|F16B02|Mc0<16802|\x84c1<680e2|41;c3|41;" [thrown-value It's human readable in the sense that all the operations have single character ascii opcodes and strings are embedded as is and there's no raw pointers, etc, so you won't get mojibake, but it's not human readable in the sense of say a pretty-printed IR.
kmill 7y ago
It looks like it's done here in the print routine: https://github.com/JeffBezanson/femtolisp/blob/master/print.c#L423 https://github.com/JeffBezanson/femtolisp/blob/master/print.... It adds 48 to each byte being printed, which is ASCII '0'.
uryga 7y ago
(edit: clarity) i couldn't really find any docs about it either, but compiler.scm is pretty readable and has an instruction listing – their arguments aren't documented explicitly, but you can infer most of it from the code for `compiler::disassemble`, which is quite readable too. the instructions remind me of CPython, pretty standard stack-machine stuff: slots for locals (`loadv 0` where 0 is an index to func_values), loading globals by name (`loadg 0`, same as with values but the value is a symbol to be looked up), relative jumps, things like that. for no reason in particular i spent an evening[0] reverse-engineering enough of the code to be able to parse/display bytecode strings :) here's the python code [1] if you want to try it, though it'd probably be easier to just install femtolisp and use its `disassemble`... as others have mentioned, the serialized form is kind-of readable, and with some practice you could probably even read it directly! e.g "c0" is `loadv 0`, ";" is `ret`, functions always have a header like `r3` indicating 3 arguments, etc. reading it like that would be very tedious but doable in a pinch, and at the very least you can see patterns like the ones i mentioned i've only looked at the bytecode and vm, but if you were more serious about using the language, the `compiler` module seems to have a nice API for creating bytecode. (they just directly expose all the functions the compiler uses!) --- [0] would've gone much faster if i'd known they shift each byte by 48 when serializing... [1] https://gist.github.com/lubieowoce/148406b1dd61d91b1584339ffefbdcc6 https://gist.github.com/lubieowoce/148406b1dd61d91b1584339ff...

KenoFischer 7y ago

It's not really documented, but human readable, may also not really mean what you think it means. For example, here's a snippet from the printed bytecode of the default system image: #fn("8000r1e0~|[316>0\x7fM~|[i2i343;];" [closure?])] find-in-f) #fn(";000r2c0~|}q3c1tg66I0c2e3c4c5e6g63132c73241;c8;" [#fn("8000r0c0c1~\x7fq2i2322^;" [#fn(for-each) #fn("8000r1~M|\x7f_43;" [])]) #fn("6000r1|F16B02|Mc0<16802|\x84c1<680e2|41;c3|41;" [thrown-value It's human readable in the sense that all the operations have single character ascii opcodes and strings are embedded as is and there's no raw pointers, etc, so you won't get mojibake, but it's not human readable in the sense of say a pretty-printed IR.

kmill 7y ago

It looks like it's done here in the print routine: https://github.com/JeffBezanson/femtolisp/blob/master/print.c#L423 https://github.com/JeffBezanson/femtolisp/blob/master/print.... It adds 48 to each byte being printed, which is ASCII '0'.

uryga 7y ago

(edit: clarity) i couldn't really find any docs about it either, but compiler.scm is pretty readable and has an instruction listing – their arguments aren't documented explicitly, but you can infer most of it from the code for `compiler::disassemble`, which is quite readable too. the instructions remind me of CPython, pretty standard stack-machine stuff: slots for locals (`loadv 0` where 0 is an index to func_values), loading globals by name (`loadg 0`, same as with values but the value is a symbol to be looked up), relative jumps, things like that. for no reason in particular i spent an evening[0] reverse-engineering enough of the code to be able to parse/display bytecode strings :) here's the python code [1] if you want to try it, though it'd probably be easier to just install femtolisp and use its `disassemble`... as others have mentioned, the serialized form is kind-of readable, and with some practice you could probably even read it directly! e.g "c0" is `loadv 0`, ";" is `ret`, functions always have a header like `r3` indicating 3 arguments, etc. reading it like that would be very tedious but doable in a pinch, and at the very least you can see patterns like the ones i mentioned i've only looked at the bytecode and vm, but if you were more serious about using the language, the `compiler` module seems to have a nice API for creating bytecode. (they just directly expose all the functions the compiler uses!) --- [0] would've gone much faster if i'd known they shift each byte by 48 when serializing... [1] https://gist.github.com/lubieowoce/148406b1dd61d91b1584339ffefbdcc6 https://gist.github.com/lubieowoce/148406b1dd61d91b1584339ff...