freenode/#clasp - IRC Chatlog
Search
15:48:14
drmeister
In llvm9 - this is what the layout of a Code_O object would look like by default...
15:49:36
drmeister
It starts with a big chunk of code followed by the __bss section <<-- this contains the literal table.
15:50:17
drmeister
The last line cc_initialize_gcroots_in_module shows where the roots are - they start at 0x125cf3040 and there are 5 roots.
15:50:35
karlosz
Bike: you were right to suspect negative handling is the issue. currently i got the dumping and loading code working for positives but negatives are all loaded back as 0
15:50:54
drmeister
The maintainer for boehm got back to me. It looks like I understand the tags and boehm header word.
15:51:09
Bike
the trick is that bignums are represented as sign-magnitude instead of two's complement. the sign is indicated as the sign of the length
15:51:55
drmeister
There is one that describes a length in bytes, which can be smaller than the size of the objects. It describes the amount of memory that needs to be scanned at the beginning of the object.
15:52:34
karlosz
Bike: this is how i'm setting the bytes of a 0 bignum to initialize it: https://paste.gnome.org/p4li5jv9t
15:53:14
drmeister
I'm going to generate a "boehm header" for every class that the static analyzer handles.
15:53:37
Bike
shouldn't you be able to work with the mp_limb_t directly? like write out limbs to the file instead of bytes? I'm pretty sure we write and read other multi byte integers okay
15:54:13
drmeister
I'll use boehm-bitmaps for regular objects, boehm-lengths for vectors of gc managed pointers and a marking procedure for code objects.
15:56:53
drmeister
They use bitmaps where the most significant bit represents the first word and they shift left, treat the word like a signed int64 and if the value is negative they mark the corresponding word.
15:59:06
drmeister
Precise mode will work with Boehm. Then I'll well on my way to implementing image save/load
16:08:41
karlosz
Bike: it doesn't seem like we dump out any other integers besides fixnums, which aren't handled the same way as mp_limbs. is there a way to get at the limbs directly in lisp? the dumping code is in cmpliteral
16:33:57
karlosz
drmeister: yeah, they are dumped as strings, which actually has a measurable performance impact
16:35:20
drmeister
We can write ltvc_xxx functions to read and write vectors of limbs - then everything is done in C++.
16:35:47
karlosz
some numeric libraries have lots of (signed-byte 64) and (unsigned-byte 64) declarations, which causes +/-2^64 to be dumped a lot
16:37:50
drmeister
The literal runtime uses C++ functions to read and write objects for the literal bytecode interpreter.
16:38:58
drmeister
We could add a reader/writer for vectors of limbs. I think we could code them in the bytecode stream as a size followed by size number of 64bit words.
16:40:02
drmeister
https://github.com/clasp-developers/clasp/blob/dispatch/src/core/byte-code-interpreter.cc#L114
16:41:23
drmeister
It reads a tag - I think this tells the GCRootsInModule what to do with the object that we are about to create.
16:41:45
drmeister
Objects can be put in the literal vector at a particular index, or they can be put in a scratch vector at a particular index.
16:42:10
drmeister
The literal vector is the final product. The scratch vector is used to store temporatry values.
16:43:23
drmeister
I think this is reading and creating the lisp string that will be converted to the bignum.
16:43:50
drmeister
Right - and the next line creates the bignum and puts it where it's supposed to go.
16:45:20
drmeister
This is where the functions that read and write things out of the literal bytecode are defined... It's all C++
16:45:32
drmeister
https://github.com/clasp-developers/clasp/blob/dispatch/src/core/compiler.cc#L1466
16:47:08
drmeister
They way it's currently set up the cmpliteral.lsp file generates C++ code that works with these C++ functions.
16:47:56
karlosz
https://github.com/clasp-developers/clasp/blob/d9b83576506a9156a3fa2a83d4967f60938cdc9f/src/lisp/kernel/cmp/cmpliteral.lsp#L339
16:48:01
karlosz
that's where we convert the bignum to a string and then construct the bytecode call to ltvc
16:58:03
karlosz
oh, maybe we can just add a clause for bignums here: https://github.com/clasp-developers/clasp/blob/d9b83576506a9156a3fa2a83d4967f60938cdc9f/src/lisp/kernel/cmp/cmpliteral.lsp#L558
16:59:54
drmeister
We want a C++ function that will write out a vector of limbs and then read it back.
17:01:33
drmeister
Alternatively you could write it out as a string as a string of bytes. I _think_ you can have any length string containing any characters.
17:02:43
drmeister
Note - I have a facility in there so that size_t are written out in a sort of compressed format
17:04:09
drmeister
I don't think the limbs will be able to use this - they should just write out the full word.
17:07:57
drmeister
the compact_xxx_size_t functions are to take advantage of the fact that we often write out small numbers like 1 and 3 and 9. So why write out 0x0000000000000001 When you can write out '1' followed by the byte 0x01
17:08:41
drmeister
So - in the worst case it looks like: '8' followed by 8 bytes - so nine bytes total.
17:13:41
karlosz
like when you have things like (signed-byte 64) and (unsigned-byte 64) declarations from numeric libraries
17:14:25
karlosz
so quicklips libraries which do a lot of number crunching with word size arithmetic will have those declarations