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
Question. How do compilers targeting Valida deal with varags in languages supporting them?
Context. PR #65 . The Valida calling convention as described in the Valida spec requires the size of each function's stack frame to be known at compile time. As a result, potentially variable sized local variables should be allocated on the heap. This is because the ISA only allows fp to be updated by adding to it a constant or a value loaded from memory at a constant offset from fp. Since function arguments are also passed on the stack, this means that the length of the arguments also must be known at compile time.
An alternative semantics for jalv would not impose this constraint. In the contemplated alternative semantics, jalv would load a value from memory into fp. Perhaps a complementary jump instruction would store fp into a location in memory contemporaneously with jumping. This would allow for the local variables and the arguments to functions to have sizes not known at compile time.
The idea we're currently going with is to let stack objects exist on the heap if they need to be variable sized. Each stack frame would then contain a constant number of scalar local variables and pointers into the heap. Each function call generates a stack frame full of arguments, and so to extend this idea to those frames, each of these arguments stack frames would contain a constant number of scalar arguments pointers into the heap. I want to confirm my understanding that this is how we would support varags in compilers targeting Valida.
The text was updated successfully, but these errors were encountered:
Question. How do compilers targeting Valida deal with varags in languages supporting them?
Context. PR #65 . The Valida calling convention as described in the Valida spec requires the size of each function's stack frame to be known at compile time. As a result, potentially variable sized local variables should be allocated on the heap. This is because the ISA only allows
fp
to be updated by adding to it a constant or a value loaded from memory at a constant offset fromfp
. Since function arguments are also passed on the stack, this means that the length of the arguments also must be known at compile time.An alternative semantics for
jalv
would not impose this constraint. In the contemplated alternative semantics,jalv
would load a value from memory intofp
. Perhaps a complementary jump instruction would storefp
into a location in memory contemporaneously with jumping. This would allow for the local variables and the arguments to functions to have sizes not known at compile time.The idea we're currently going with is to let stack objects exist on the heap if they need to be variable sized. Each stack frame would then contain a constant number of scalar local variables and pointers into the heap. Each function call generates a stack frame full of arguments, and so to extend this idea to those frames, each of these arguments stack frames would contain a constant number of scalar arguments pointers into the heap. I want to confirm my understanding that this is how we would support varags in compilers targeting Valida.
The text was updated successfully, but these errors were encountered: