You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add the ability to store full objects in SimpleMemory, in a Write<T>() style (and similarly for reading). In the background this would de/serialize the object to the byte representation and use the other SimpleMemory operations as usual.
Since object sizes are known at compile-time the store and retrieve logic for an object tree can be substituted in an AST processor (i.e. a Write(index, myObject) substituted with as many Write4Bytes() calls as necessary).
An inconvenience is that such objects would most possibly use more than one memory cell, i.e. the consumer code needs to handle the necessary indexing logic to space out the next object to write to memory for example. This can be made easier if Write<T>() returns an int with the amount of cells used to store the object so you can calculate nextIndex = Write<T>(currentIndex, myObject) + currentIndex.
This brings us to one step distance of masking away SimpleMemory in hardware invocation points and handling standard method arguments behind the scenes but I consider that a low priority (as you'd need SimpleMemory for dynamic memory allocations any way, and it's just a small inconvenience).
As a follow-up to @antonfirsov's idea from here.
Add the ability to store full objects in
SimpleMemory
, in aWrite<T>()
style (and similarly for reading). In the background this would de/serialize the object to the byte representation and use the otherSimpleMemory
operations as usual.Since object sizes are known at compile-time the store and retrieve logic for an object tree can be substituted in an AST processor (i.e. a
Write(index, myObject)
substituted with as manyWrite4Bytes()
calls as necessary).An inconvenience is that such objects would most possibly use more than one memory cell, i.e. the consumer code needs to handle the necessary indexing logic to space out the next object to write to memory for example. This can be made easier if
Write<T>()
returns anint
with the amount of cells used to store the object so you can calculatenextIndex = Write<T>(currentIndex, myObject) + currentIndex
.This brings us to one step distance of masking away
SimpleMemory
in hardware invocation points and handling standard method arguments behind the scenes but I consider that a low priority (as you'd needSimpleMemory
for dynamic memory allocations any way, and it's just a small inconvenience).Jira issue
The text was updated successfully, but these errors were encountered: