Do we need to change how shecc evaluate expression?

[eecheng87]

The way recent shecc evaluating local expression is generating relative arithmetic instruction and calculating in run-time. I think we can change the scheme into evaluating in compile time.

Although it will increase compile time, there're still lots of benefits:

• we can do more tricks(optimization) on expression because we know the characteristic(value) of the operand before run-time. e.g. quick modulo
• no operand limit because we use stack. Also we can pass relative test bench in driver.sh(expr 210 "1 + (2 + (3 + (4 + (5 + (6 + (7 + (8 + (9 + (10 + (11 + (12 + (13 + (14 + (15 + (16 + (17 + (18 + (19 + 20))))))))))))))))))")

[jserv]

The idea is generally making sense. However, we should take the lazy evaluation way. By using eager evaluation, the cfront aggressively computes all the expressions, that would cause unexpected work. Instead, once we keep the operands (and expressions) in the stack, we can then evaluate right before code generation.

[eecheng87]

once we keep the operands (and expressions) in the stack, we can then evaluate right before code generation.

I think stack using in read_expr is for generating proper order to evaluate right expression and I don't think it now can be determined before code generation. Also, in some test case, register will run out when code is generating.

And I am curious about why eager evaluation cause unexpected work? We need to evaluate it anyway, what is difference to do it in advance?

[jserv]

And I am curious about why eager evaluation cause unexpected work? We need to evaluate it anyway, what is difference to do it in advance?

Lazy evaluation (or call-by-need) delays evaluating an expression until it is actually needed; when it is evaluated, the result is saved so repeated evaluation is not needed. This technique can make some algorithms easier to express compactly or much more efficiently, or both. The binary of shecc might be bootstrapped, which implies less efficient evaluations (and sometimes, buggy).

[jserv]

Drop this issue in favor of #84