I converted the PropBASIC frequency counter program to C..
I also generated the assembly output, which is included in the zip file.
That's a great example. Any code-size numbers for the 3 choices ?
I also see calls to __DIVSI, but no code shows for that ?
Like in the i2c example, PropGCC this time again missed the andn, that it sometimes can see?, and instead uses a 2nd register and invert constant.
PropBASIC comes in smaller than PropGCC, but not by that much.
+19% on the inner-most Freq loop, and +70% on the serial, but PropBASIC has a native asm block it pops in for that, with a highly optimized 4 line .DJNZ shifting loop.
However some can be improved by coding, I notice
C: value = (value << 1) | 0x200;
while Basic used the more compact value = (value | 0x100) << 1;
I'm guessing C will compile the last form smaller.
PropBASIC also has the illusion of a BAUD parameter, but it actually stores a const FSys/BAUD (ie skips any run time load DIV )
PropGCC code can shrink, by doing the same.
The other gain area for PropBASIC seems to be in register allocation, & looks like PropGCC could benefit from either a user directive or some pass that keeps some vars in registers.
PropGCC will always be constrained by the code generator mapping of just a limited RegSet, but that is a core feature of GCC
Any calls to libraries like __DIVSI, also make that 'keep' decision more difficult.
I also see PropBASIC has a nice DivMod, if a little non-portable, by using an overlay access to the available __remainder.
That allows a single (in line) DivMod ASM generate, whilst PropGCC has 2 calls.
OK now that I am taking a more serious look at this I am in the progress of learning the quirks of Prop GCC. It is rather interesting and I think that it will work out quite well.
Comments
I also see calls to __DIVSI, but no code shows for that ?
Like in the i2c example, PropGCC this time again missed the andn, that it sometimes can see?, and instead uses a 2nd register and invert constant.
PropBASIC comes in smaller than PropGCC, but not by that much.
+19% on the inner-most Freq loop, and +70% on the serial, but PropBASIC has a native asm block it pops in for that, with a highly optimized 4 line .DJNZ shifting loop.
However some can be improved by coding, I notice
C: value = (value << 1) | 0x200;
while Basic used the more compact value = (value | 0x100) << 1;
I'm guessing C will compile the last form smaller.
PropBASIC also has the illusion of a BAUD parameter, but it actually stores a const FSys/BAUD (ie skips any run time load DIV )
PropGCC code can shrink, by doing the same.
The other gain area for PropBASIC seems to be in register allocation, & looks like PropGCC could benefit from either a user directive or some pass that keeps some vars in registers.
PropGCC will always be constrained by the code generator mapping of just a limited RegSet, but that is a core feature of GCC
Any calls to libraries like __DIVSI, also make that 'keep' decision more difficult.
I also see PropBASIC has a nice DivMod, if a little non-portable, by using an overlay access to the available __remainder.
That allows a single (in line) DivMod ASM generate, whilst PropGCC has 2 calls.