[CM] Idea: using handles instead of pointers, s7_clone

[Christos Vagias]

Greetings all,

Just wanted to share with you an idea I had about a possible future
(and breaking!) s7 change.
Namely: using handles instead of pointers. This means every s7 api
method would return a s7_handle instead of a s7_pointer.
A s7_handle could be simply:
struct {
 uint32_t index;
};

index would point to the index in the s7 storage.
I'm a bit confused with s7 heap vs s7 stack, but let's just assume the
storage being
s7_cell heap[INITIAL_HEAP_SIZE], then, to get the (for internal use) s7_pointer:

s7_pointer s7_handle_to_pointer(s7_handle handle) {
return heap[handle.index];
}

Also any s7 structure (list/vector etc) would store references to
s7_handles instead of s7_pointers.
When the storage/heap needs to resize it's just a matter of realloc &
initializing the new allocated part.

My main drive for this change is to make something like s7_clone
possible. By using s7_handles one could copy the whole s7 instance
just by doing a memcpy of the s7's storage/heap. I'm attaching some
contrived code of how one could use this feature.

Another possible win from a change like this would be making s7
objects smaller => less cache misses.
s7_handle could encode in which storage the underlying s7_cell is
stored (eg using bit fields: 2 bits for storage group, 30 for index)
Like this, s7_cell could be split into separate groups (& underlying
storage), depending in their size.
Since the s7_cell type info is 8 bytes:
- numbers need only 16 more bytes, making them only 24 bytes in total.
- the rest (c-pointers vectors ports etc) could stay together. Right
now s7_cell is 48 bytes, but that could go lower since every
s7_pointer (8 bytes) could be replaced with s7_handle (4 bytes).

For reference, this is the article that inspired me:
https://floooh.github.io/2018/06/17/handles-vs-pointers.html
I have also used this technique for a classic tree-like data
structure, where I'm storing everything in a vector, and passing
around indexes instead of pointers. This made copying the whole tree
essentially free (memcpy instead of having to traverse down the tree).

Looking forward to your input!

Best,
Christos Vagias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s7_clone_example.c
Type: text/x-csrc
Size: 708 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220923/2e5f3852/attachment.bin>