Mozak
Cross program calls: examples #1324
Replies: 3 comments 4 replies
-
How things work for Parity CheckerAssume we invoke for Programs When running x != 0 && check_even(x - 1)
// resolves to true && trueensures ret at Side effect of above is that while checking for index At the end, Same kind of execution would be done by |
Beta Was this translation helpful? Give feedback.
-
Protocol extension for self-calls under Cross-Program-CallsAll of the current design of cross-program-calls have an unmentioned axiom inherent in the design. It could be described as follows:
However, in a situation where the following is expected:
an extension for self-calls can be introduced in CPC. The general idea remains the same as before, but extended enough to accomodate for self-calls. We describe the extension as a simple operation where each caller and callee instead of being identified by their In parity example above where self-call wasn't introduced, if extension is applied, the CallTape would simply change from: to: and instead of validation logic being: for &message in calltape.iter() {
if message.callee == self_prog_id {
// Process
}
}the check becomes for call_depth in 0..calltape.max_self_call_depth(self_prog_id) {
for &message in calltape.iter() {
if message.callee == self_prog_id {
// Process
}
}
}The assumption is that The extension makes us of "Whenever a program at any specific time does a CPC call to itself, (self-call), the call is registered in the CallTape with caller: This remains the general idea of the self-call extension. Further, the fibonacci solution would present more concrete example on how call-tape looks, and the additional lookup load on accessing CPC tape with such extension. |
Beta Was this translation helpful? Give feedback.
-
|
This seems like a weird ad hoc design. Let me think some more, but it 'smells' funny. |
Beta Was this translation helpful? Give feedback.
-
# How things work for FibonacciWe extend the above given fibonacci example to bring home the implications of "self-calls" extension to CPC. For this, we make of two cooperating programs defined as follows: // PROGRAM: AlfProg
fn alf(x: u32) -> u32 {
if x > 0 {
fib(x)
}
0
}and // PROGRAM: FibProg
fn fib(x: u32) -> u32 {
if x < 2 {
x + alf(0)
} else {
fib(x - 1) + fib(x - 2)
}
}Assume, we initiate the call from The calltape now looks like (space added for readability): We know that while executing So, for for call_depth in 0..calltape.max_self_call_depth(self_prog_id) { // 1
for &message in calltape.iter() {
if message.callee == self_prog_id {
// Process
}
}
}calltape is only traversed once. But what is
|
Beta Was this translation helpful? Give feedback.
-
|
In essence, prefer internal dispatch over CPC |
Beta Was this translation helpful? Give feedback.
-
|
Interesting addition by @matthiasgoergens: |
Beta Was this translation helpful? Give feedback.
-
|
@supragya What happened to this design? I thought that was what we agreed on, not this call depth counter (nor a |
Beta Was this translation helpful? Give feedback.
-
Here I am collecting some examples of patterns of call graphs we should support.
They are not necessarily meant to be practical, but prototypical of patterns that might occur in practical programs.
Parity checker
Assume we have two cooperating programs, that call each other via cross program calls:
Crucially,
check_even(andcheck_odd) typically indirectly calls themselves before returning anything.check_odd(4)would result in the following calls on the tape (in some order):Fibonacci
The obligatory Fibonacci example.
Assume that calls to
fibhappen via cross-program calls. (In a real program, there might be some intervening other programs involved, instead of direct self calls.)Beta Was this translation helpful? Give feedback.
All reactions