Compound conditional generates bad code

[HPCguy]

int is defined as 32 bit here, not long long, but that is not related to the bug:

%c4 -s c4.c

73: while (*p != 0 && *p != '\n') ++p;
0xb6d4c2a4 IMM 0xb6d0b008
0xb6d4c2ac LI
0xb6d4c2b0 LC
0xb6d4c2b4 PSH
0xb6d4c2b8 IMM (nil)
0xb6d4c2c0 NE
0xb6d4c2c4 BZ 0xb6d4c2f0 <<-- This address is wrong for short ciruit op
0xb6d4c2cc IMM 0xb6d0b008
0xb6d4c2d4 LI
0xb6d4c2d8 LC
0xb6d4c2dc PSH
0xb6d4c2e0 IMM 0xa
0xb6d4c2e8 NE
0xb6d4c2ec BZ (nil)
0xb6d4c2f4 IMM 0xb6d0b008
0xb6d4c2fc PSH
0xb6d4c300 LI
0xb6d4c304 PSH
0xb6d4c308 IMM 0x1
0xb6d4c310 ADD
0xb6d4c314 SI

[andrakis]

Branch locations are a little messed up in the -s(ource) output. This is because the printing of the generated code sometimes happens before the jump location(s) are fixed up to the correct address.

It's actually a bit difficult to overcome. My approach was to generate code first, and print it out after generation is done. This requires a lot of extra housekeeping to track, and the modifications to do this are not small, really polluting the simplicity of c4.

See #30 for a little more explanation of what is going on here.

[HPCguy]

I moved the printout for sources/addresses to happen after parsing, and now get correct results:

73: while (*p != 0 && *p != '\n') ++p;
b6d99234 IMM b6d58008
b6d9923c LI
b6d99240 LC
b6d99244 PSH
b6d99248 IMM 00000000
b6d99250 NE
b6d99254 BZ b6d9927c
b6d9925c IMM b6d58008
b6d99264 LI
b6d99268 LC
b6d9926c PSH
b6d99270 IMM 0000000a
b6d99278 NE
b6d9927c BZ b6d992b0
b6d99284 IMM b6d58008
b6d9928c PSH
b6d99290 LI
b6d99294 PSH
b6d99298 IMM 00000001
b6d992a0 ADD
b6d992a4 SI
74: }
b6d992a8 JMP b6d99234

Thanks. All is indeed well.

BTW Getting the after-parse source listing only required adding 18 lines of code, and moving the existing print code from the next() routine to main().

[andrakis]

I suppose it depends on what your goal is. I complicated things because I wanted -s to generate assembly that could be assembled and run by another c4 program, and that involved things like dumping the data and determining where a pointer like b6d58008 points to (code, data, or just a literal?) then turning them into offsets like [.code + 128]. That's why mine was not a simple change.