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
"yield abstraction" might not be the best name for this, but that's what I've called it for now in our IR pipeline (and it does nothing right now). Perhaps "par lift" or "par abstraction" is a better term.
But @Rewbert actually brought up this issue as it was something he thought of while working on ssm-edsl.
Say we have something like this:
par do wait x
after 1, y <- ()
do after 1, x <- ()
wait y
This expression alone already has some fairly interesting temporal behavior, and is something we do allow in our language. But codegen doesn't know how to deal with this, because it only knows how to deal with parallel function calls.
That can be achieved by lifting these into immediately applied lambdas:
par (\() -> wait x
after 1, y <- ()) ()
(\() -> wait y
after 1, x <- ()) ()
This should be done before lambda lifting (#32) to ensure that these newly introduced lambdas are lifted to the top-level so that they are compatible with Codegen's compilation scheme.
The text was updated successfully, but these errors were encountered:
Oh and I should note that for parallel expression with no temporal behavior, they should just be desugared down into sequential code for efficiency (avoids unnecessary context switches). So for instance:
Broadly, it's just desugaring par expr (|| expr)* into parallel function calls. We did something like this in the SHIM language; it's mechanical here because the expressions are totally ordered.
"yield abstraction" might not be the best name for this, but that's what I've called it for now in our IR pipeline (and it does nothing right now). Perhaps "par lift" or "par abstraction" is a better term.
But @Rewbert actually brought up this issue as it was something he thought of while working on ssm-edsl.
Say we have something like this:
This expression alone already has some fairly interesting temporal behavior, and is something we do allow in our language. But codegen doesn't know how to deal with this, because it only knows how to deal with parallel function calls.
That can be achieved by lifting these into immediately applied lambdas:
This should be done before lambda lifting (#32) to ensure that these newly introduced lambdas are lifted to the top-level so that they are compatible with Codegen's compilation scheme.
The text was updated successfully, but these errors were encountered: