Jonathan S. Shapiro wrote:
> 1. RETURN statement
>
> We intentionally left this out. It can be simulated by a TRY/CATCH block
> wrapping the lambda body, so I don't think it introduces any new core
> semantics. How much work would it be to introduce this as a syntactic
> form and propagate it through the current compiler?
Implementing return itself is not hard. I guess the intension here is to
implement return throughout the compiler (that is, emit a return in the
C code), rather than an AST transformation into try/catch? I think
handling returns is easy enough, and a try/catch block around every
"return"ing function will be expensive.
> 2. TAIL RECURSION
>
> We chose to limit tail recursion so that we could target C code, but
> even so we were forced to do an SSA pass. The unfortunate side effect of
> the SSA pass is that the output C code is not readable at all. Given
> that we have a looping construct, I am wondering whether we should
> change the DO form into a core form and eliminate the tail recursion
> requirement entirely.
> Personally, I would much prefer to retain tail recursion. The problem
> here is the SSA pass.
Consider the following summation function:
int f(int x)
{
return (x <= 0) ? x : x + f(x-1);
}
I wrote a tail recursive version of the same function using GCC
expression syntax as below:
int
f(int x, int sum)
{
f_begins:
return ({
int ans;
if(x <= 0) {
ans = sum;
}
else {
sum = sum + x;
x = x - 1;
goto f_begins;
}
ans;
});
}
This function compiles and works fine. So, the problem is not that we
cannot perform a goto across the expression block.
My recollection is also that we switched to SSA transformation from
expression syntax because of issues with tail-recursion. There might
have been a problem with goto-jumps within expression blocks at the time
we implemented code generation. Is there a way to see the old commits
from openCM so that I can see where we switched over?
> Do inner procedures *also* cause us to run the SSA pass? If so, we can
> drop this entire issue.
I don't think inner procedures will force us to use SSA generation.
They will definitely make the code somewhat different from the original
BitC code because of hoisted functions, translation functions (code
that calls the actual function with the closure arguments), the closure
construction (make-closure()) call, etc. Letrec also introduces some
alloc-ref, copy-ref code to ensure that the space is allocated for the
letrec bound value before its initializer can be run.
> The unfortunate side effect of the SSA pass is that the output
> C code is not readable at all.
In a way, there is also an advantage to the SSA pass. It produces code
that has reasonable unambiguous C semantics. From the point debugging
the compiler (through output code), expression syntax seems better.
Do you think that the expression syntax might help the C-optimizer
as well?
> 3. Built-in Operators
>
> In the s-block syntax, BitC will parse infix and prefix arithmetic,
> boolean, and bit operators with the customary precedence rules. Since
> these symbols are actually type class methods, we have two choices:
>
> 1. Admit these symbols as identifiers in general.
>
> 2. Define these symbols to have canonical rewritings to legal
> identifiers, and do not alter the legal identifier name space.
>
> I mildly prefer the second approach. Any objections?
So, in the second approach, symbols such as + - * / will be special,
and out of the legal identifier space? I have no objection to either
approach.
Swaroop.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
