Hot!XC8 8bit variable increment(++) generates extra machine instructions.

Page: < 12 Showing page 2 of 2
Author
TaanielDigi
New Member
  • Total Posts : 7
  • Reward points : 0
  • Joined: 2018/09/04 06:54:42
  • Location: Secret location near Russia
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/06 10:39:28 (permalink)
0
mark.pappin
TaanielDigi
I guess in the end it is better to have controlled known deliberate code insertion than to have some random crappy non optimized code.

Sadly for you, you have the latter not the former.
 
Microchip does not pay compiler developers to write extra code that deliberately inserts extra instructions (that manage to not change the functionality of your code) in Free mode which will then be removed by the PRO optimizer. What you get out of Free mode is the result of a table-driven code generator plus whatever optimizations/cleanups the developers have been able to convince management to allow them to give away. (If there was no Free/PRO distinction the maintenance and support loads would be significantly reduced, but this argument has not yet proven sufficient to persuade the Powers That Be.)
Free mode generates no direct revenue; PRO license sales generate direct revenue which is all the beancounters care about.
 
This baseless claim of "code bloat" has been done to death numerous times over at least the last 5 years. Please don't continue to stoke the fire.


Ok then, maybe I have to explain some more and make the current moment conclusion.
Basically what we have done is taken the compiler guts out to the table and analysed its workings. Indeed it performs generally very well. But I have reached the conclusion that in the specific case it is not relevant to analyse the compiler workings based on the free version. Can only discuss writing better code for the full version compiler in this case, since it is ridiculous to analyse workings of the thing that has clear business motivation to keep the disdinct difference in the generated machine code size. It is the base objective and the main sales argument of this part of the business. The analyse shows that this is not actually easy to induce the sustainable code size and speed difference in the case of such a simple hardware as those nice 8bit RISC PICs because the most programs written to those things can be written and are actually written so simple that really do not reguire special "optimization" just require a good basic compiler workings.
Only consistent way to induce the constant memory usage difference can then only be obtained by having some very low level deoptimizations, as in this case refusal to compile ++ directly into the INCF. So tecnically it is all legally correct. It is hardware specific optimization, as the same C command can be translated to the machine code differently ,one way is more optimal than the other. Using one of the machines 49 instructions directly is just more optimal than not using it.  It just was suprise to me at what low level this comes to play the role. Actually I was innocently hoping that if I write program with only simple commands that have clear direct translation to the machine code I would get away with using the free version and still produce the near ideal outcome. But bugger, that just did not happen...
So OPTIMIZATION issue it is.
 
#21
NorthGuy
Super Member
  • Total Posts : 5049
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/06 10:56:12 (permalink)
+1 (1)
TaanielDigi
Actually I was innocently hoping that if I write program with only simple commands that have clear direct translation to the machine code I would get away with using the free version and still produce the near ideal outcome. But bugger, that just did not happen...



Would you tell us if having two (or four) instructions instead of single INCF destroyed the functionality of your particular program in this particular case?
 
#22
du00000001
Just Some Member
  • Total Posts : 2128
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/06 11:22:30 (permalink)
+1 (1)
Honestly - I just created a SENT simulator plus a SENT decoder with the free version.
 
Both run like a charm, although the timing is quite challenging: SENT has a shortest pulse width of 36 µs - translating to 288 instructions inbetween (@ 8 MIPS on a PIC16F).
Beyond the ISR to transmit resp. receive the pulses, there's quite some code to execute to calculate/check CRCs, assemble/disassemble frame data and alike.
 
The challenge is certainly not the compiler's performance but the developer's performance: you can implement things "clever and fast" or boated and slow. At one point I even compared 2 similar algorithms to find the better performing one.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#23
JorgeF
Super Member
  • Total Posts : 3286
  • Reward points : 0
  • Joined: 2011/07/09 11:56:58
  • Location: PT/EU @ Third rock from the Sun
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/06 11:22:41 (permalink)
+3 (3)
TaanielDigi
..low level deoptimizations, as in this case refusal to compile ++ directly into the INCF...

I guess you are missing that the "++" operator is not restricted to 8 bit unsigned scalars.
How would you use plain "incf" to code the "ptr++;" statement in the example bellow?

typdef struct{
      unsigned int x;
      unsigned char *sptr;
      } mystruct, *mystruct_p;
 
mystruct_p ptr;
................
    ptr++;
...............

At a first approach the generated code must be valid for all types at which the operator can be applied.
Then the special case of it being applied to an 8 bit unsigned scalar would be detected and the generated code reduced to a simple "incf".
But this second step, handling special cases, is already in the realm of optimization.
That is why I don't see neither, bloated code nor de-optimization in the example you presented.
 
BTW, I'm not a Microchip employee, neither I'm being paid to defend it.

Best regards
Jorge
 
I'm here http://picforum.ric323.com too!
And it works better....
#24
TaanielDigi
New Member
  • Total Posts : 7
  • Reward points : 0
  • Joined: 2018/09/04 06:54:42
  • Location: Secret location near Russia
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/24 03:14:07 (permalink)
-2 (2)
NorthGuy
 

Would you tell us if having two (or four) instructions instead of single INCF destroyed the functionality of your particular program in this particular case?



Yeah I actually dropped the project for now because of this and moved on to the other things. I am particularly oriented to the shared open source projects and need other people to be able to replicate the project with minimum investments. This was a little too cutting edge project that I had originally in assembler, tried converting to C but then realized that free version is actually crippled to the point of running the processor 4x slower with added crap instructions.
It became clear that it adds instructions every time there is "=" in the code. Too bad it was not documented correctly in the manual.
 
Best Regards
Teemo
#25
NKurzman
A Guy on the Net
  • Total Posts : 16437
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/24 05:53:54 (permalink)
+1 (1)
That is you interpretation of what is happing. But you opinion is not the correct reason. Not documented? Doesn’t the compiler advertise how much better the pro version is every time you build?
In short it is not crippled, it does not add extra instructions. It Is missing the optimizer. An option you can rent for 30USD a month.
#26
NorthGuy
Super Member
  • Total Posts : 5049
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/24 07:30:10 (permalink)
+2 (2)
TaanielDigi
This was a little too cutting edge project that I had originally in assembler, tried converting to C but then realized that free version is actually crippled to the point of running the processor 4x slower with added crap instructions.



Let me guess. Someone told you that the modern C compilers are so good that the code they generate will beat the human-written assembler any time. So, you took one of those highly efficient hand-crafted assembler projects and ported it to C. Which made it slower. The correct conclusion from this experience would be that C compilers cannot be as fast as the hand-crafted assembler code. However, you didn't want to part with your compiler-supremacy idea, so you decided to blame everything to Microchip who gave you sub-standard free compiler.
 
I suggest you get a free trial of the pro version of XC8, re-compile your code with the pro compiler and compare the results with the original assembler.
 
#27
mlp
boots too small
  • Total Posts : 593
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: previously Microchip XC8 team
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/24 07:48:57 (permalink)
+8 (8)
JorgeF
BTW, I'm not a Microchip employee, neither I'm being paid to defend it.



To avoid any potential confusion, I was a Microchip employee for 5 years but escaped from that 9 months ago.
 
Now, and for free, I choose to defend the integrity of the blokes (most of the team is Australian) who produce a pretty good compiler despite the extremely compiler-unfriendly architecture. These same blokes would love to eliminate the hobbled Free mode and be able to give everybody the best compiled code, but The Company That Pays Them has decided compiler license sales revenue is more significant than whatever benefits would accrue with a free-for-all full compiler.

Mark (this opinion available for hire)
#28
mad_c
Super Member
  • Total Posts : 1107
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/24 14:29:50 (permalink)
+3 (3)
Hi,
 
It has been correctly stated on many occasions that there is no code "added" to the Free-mode output. Fully turning off the optimisers when using the PRO-mode compiler produces the same "crippled" output that you see in Free mode, which illustrates the point. To be fair, this has been a little confusing, since some optimizers were controlled by the --mode option, not the --opt option, making it seem as if there were foul deeds independent of the optimisers at play. The v2+ XC8 compilers now use a single optimization level (and a few other optimization options), which are wholly responsible for controlling the optimizations applied. Indeed, with v2.05 (coming soon*), the mode option no longer has any effect.
 
Incidentally, in v2.05, there has been a "tweak" made to how licensing works. While licenses are still purchased, those using the unlicensed compiler will be more pleased with the compiler output.
 
Jeff.
#29
NKurzman
A Guy on the Net
  • Total Posts : 16437
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/24 16:06:17 (permalink)
0
mark.pappin
JorgeF
BTW, I'm not a Microchip employee, neither I'm being paid to defend it.



To avoid any potential confusion, I was a Microchip employee for 5 years but escaped from that 9 months ago.
 
Now, and for free, I choose to defend the integrity of the blokes (most of the team is Australian) who produce a pretty good compiler despite the extremely compiler-unfriendly architecture. These same blokes would love to eliminate the hobbled Free mode and be able to give everybody the best compiled code, but The Company That Pays Them has decided compiler license sales revenue is more significant than whatever benefits would accrue with a free-for-all full compiler.




compiler-unfriendly architecture?  I remember when there were those that said it was impossible to write a compiler for a PIC16.
So The Microchip Corporation is Run By Capitalists?  Who could have Guessed.
#30
mlp
boots too small
  • Total Posts : 593
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: previously Microchip XC8 team
  • Status: offline
Re: XC8 8bit variable increment(++) generates extra machine instructions. 2018/09/25 13:15:04 (permalink)
+2 (2)
NKurzman
compiler-unfriendly architecture?

I was being generous.
 
I remember when there were those that said it was impossible to write a compiler for a PIC16.

A lecturer said that to a student who was at that time an intern (later, an employee) at HI-TECH, daily using and improving that same impossible compiler. Student says "OK", and happily submits .LST file rather than C source code for assignments.
 
So The Microchip Corporation is Run By Capitalists?  Who could have Guessed.

As a compiler developer and PIC user I was and am not pleased that the Free / PRO distinction exists; as a shareholder I'm overjoyed that there's revenue from one of them.

Mark (this opinion available for hire)
#31
Page: < 12 Showing page 2 of 2
Jump to:
© 2018 APG vNext Commercial Version 4.5