It confirms my suspicion that GCBASIC is primarily used by folks who use PIC. Perhaps for PIC, it produces better code, or perhaps there are no other good alternatives for PIC, I don't know.
Perhaps a starting point would be to figure out which are the most popular microcontrollers in the world of GCBASIC. I have never used a PIC. AVRs I often use tiny13/85/4313 and ATmega88/328. Once the most used ones are identified one can focus on these architectures.
From the testing I have done so far, the biggest gains would come from frequently used libraries such as the string functions or communication libraries such as I2C and SPI. BASCOM has optimized them, sometimes directly in assembler. For example, look at the ByteToString function discussion earlier. The native code produced by GCBASIC is a lot larger than what BASCOM produces. Then you wrote a custom implementation for it that was much smaller. But the average user of GCBASIC cannot or does not want...
Optimization is the result of many small gains. Of course, one can take apart any individual improvement and argue that it is too little for the effort. But with that mindset it will never improve. As I mentioned before, BASCOM produces 25%-50% smaller code for exactly the same program, almost line for line the same. I am not at the helm of GCBASIC, but if you want to make it better, then code size is an area that should be addressed because it is a real limiting factor for what GCBASIC can be u...
My asessment is certainly biased since I only use AVRs and not PICs.
Thanks for the analysis. I agree, it is a big change, and it was merely a suggestion. However, I do think you are underestimating the possible savings. Of course, it depends on the application, and I would think that some coders already do this type of optimization manually. I certainly do. I think the biggest benefit with such an optimization would be that one does not anymore have to think about doing this manually and one can create subroutines purely for structural and coding purposes to make...
Thank you!
I am merely pointing out things that would make the generated code smaller. The 25-50% more code that GCBASIC generates is currently the remaining hurdle for me to drop BASCOM and adopt GCBASIC.