Macro bug: x = MACRO(x)

[GoogleCodeExporter]

What steps will reproduce the problem?

starting picoc v2.2 beta r589
picoc> #define MIN(a,b) ((a) < (b) ? (a) : (b))
picoc> int x = 3;
picoc> x = MIN(x, 2);
picoc> printf("%d\n", x)
0

What is the expected output?
2

What version of the product are you using? On what operating system?

Tried v2.1 and v2.2 beta r589.

Please provide any additional information below.

This works:
int tmp = MIN(x, 2);
x = tmp;

Original issue reported on code.google.com by broscuta...@gmail.com on 2 Mar 2013 at 9:10

[GoogleCodeExporter]

Another test case suggests it's not related to arguments, but to the lvalue:

int y = MIN(1,2);
printf("%d\n", y);
=> 1 (OK)

int y = 0;
y = MIN(1,2);
printf("%d\n", y);
=> 0 (bad)

Original comment by broscuta...@gmail.com on 2 Mar 2013 at 10:19

[GoogleCodeExporter]

By tracing the calls to ExpressionParseMacroCall and ExpressionAssign, the 
macro is evalued correctly, but the result is not assigned to its destination 
(ExpressionAssign is not called, when it probably should be).

Original comment by broscuta...@gmail.com on 2 Mar 2013 at 10:27

[GoogleCodeExporter]

When compiling with NO_FP, it works fine.

Original comment by broscuta...@gmail.com on 2 Mar 2013 at 12:21

[GoogleCodeExporter]

Possible fix, with test case. Not sure if it's 100% correct, but at least it 
doesn't break existing tests.

Original comment by broscuta...@gmail.com on 2 Mar 2013 at 1:18

Attachments:

• macro_fix.patch

[GoogleCodeExporter]

Patches applied with love in r597. Thanks.

Original comment by zik.sale...@gmail.com on 16 Mar 2013 at 6:10

• Changed state: Verified

[GoogleCodeExporter]

Yay!

I'm currently running picoc under valgrind, so I'll have some more fixes soon.

Next, I'd like to speed up expression evaluation a bit, as it seems to take 90% 
of time in my benchmarks (maybe evaluate from some AST tree instead of parsing 
on the fly?)

Original comment by broscuta...@gmail.com on 16 Mar 2013 at 8:02

[GoogleCodeExporter]

I'm experimenting with picoc v3 using a completely different execution engine 
which will run hundreds of times faster. The only downside is that it's a much 
larger codebase. What's your opinion - is it worth making the code much larger 
to get fast execution speed?

Original comment by zik.sale...@gmail.com on 16 Mar 2013 at 8:06

[GoogleCodeExporter]

For ~150K you can consider switching to tcc, which compiles ARM natively (at 
least for my application). I wasn't able to get it working yet (need some 
external symbols like standard file i/o), but seems very promising.

So... the main reason I went for picoc was binary size and familiar language. I 
use it for scripting on DSLR cameras ( 
http://www.magiclantern.fm/forum/index.php?topic=4362.0 ), where the memory is 
quite limited. Works for pretty much anything except image processing.

Current implementation takes around 70K, and this includes GUI, floating point 
in single precision, and my custom library. Picoc is compiled as thumb, the 
rest is arm.

Even so, there are some cameras for which the memory usage is quite high - 30K 
more and it would no longer boot. I'm considering converting the entire code 
base to thumb, which will save some more RAM.

Lua is quite fast (40x faster than picoc, but 30x slower than C), but is also a 
bit large (150K bare-bones, without float, without gui, without library).

Original comment by broscuta...@gmail.com on 16 Mar 2013 at 8:19

[GoogleCodeExporter]

Update: just compiled TCC - the compiler takes 150K as ARM and 115K as Thumb. 
Tried a small image processing sample - it was almost instant, whereas picoc 
took 1 minute.

short * buf = get_image_buffer();

for (int i = 0; i < 480; i++)
{
    for (int j = 0; j < 720; j++)
    {
        // for each pixel, keep chroma, set luma to 0x80
        buf[i*720+j] = (buf[i*720+j] & 0x00FF) | 0x8000;
    }
}

Original comment by broscuta...@gmail.com on 18 Mar 2013 at 8:56