Add -fshort-enums to compiler options

[MX682X]

while tinkering on the ptc_touch library, I wanted to write good code and tried to use enums instead of defines, but I stumbled upon an unfortunate part of the C specifications: usually, enums have to be 16-bit wide (ints), making enums effectively the worse choice for constants. Upon investigating this issue, I found the gcc switch

-fshort-enums

Allocate to an enum type only as many bytes as it needs for the declared range of possible values. Specifically, the enum type is equivalent to the smallest integer type that has enough room. This option has no effect for an enumeration type with a fixed underlying type.

Warning: the -fshort-enums switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface.

I'm kinda concerned about the binary compatibility, as this might result in breaking the support of linking against pre-compiled libraries. At least thats what I think might happen, I don't have any library that I can check. It might save some bytes with the usual code though - who knows how many people and Arduino libraries are using enums that are twice as big as neccessary....

[SpenceKonde]

I'm not super concerned, but that's because I have a chip on my shoulder here. I don't like precompiled libraries. There's only one place they're going to come from, and that's Microchip. So in that case we'd better get this into the cores asap right? Cause if Microchip drops the qtouch library for arduino and it relies on that precompiled bloated lib - if it doesn't work when it comes out, if someone complains shrug s' not my problem, it's Microchip's problem ;-) (Issue closed: Not our bug).
On the other hand, if they get the library out and it works, and then I do something that breaks it, then it's my code that would generally be considered "at fault" and thus the one that people expect to be changed to "undo the regression".

To me, the only question this raises is

"Doesn't the toolchain package have a shitload of compiled .o files? Does this apply to them too? That is, do I need to use a new toolchain version where I added -fshort_enums to the build commands in the build script to use -fshort_enums?"

That seems kinda crazy.

Other than that, the fact that this isn't the default behavior is just nasty IMO, especially considering all those enums in the IO headers.

What is typical savings like on sketch size?

Arduino in general is incredibly willing to waste 2 bytes on every single byte datatype by using ints all over the place even if the value is always between 0 and 255 inclusive, etc). You would not belive what they do with the Serial parameters on the stock ArduinoAPI files - the char size second stop bit, and parity mode, set by six bits in the hardware, were represented as TWELVE bits, most reserved or corresponding to options that only other companies parts offer. Despite the fact that they not only fit in 6 bits but could be located in the same place in the byte as on the hardware, thus saving a dozen+ words and clocks of bit shuffling.

Note: The Optimization Options menu is gone. It didn't work. You couldn't compile any sketch with Serial in it if using -O3 because it manipulated some of the inline ASM in a way that resulted in two copies of it, and they had a label of the same name (obviously), so it choked on that, and, when I finally found the part of the avr-gcc manual that talks about this, I realized the solution they have for duplicate labels fails in this case. The inline asm must not be inlined, unrolled, or otherwise stomped on by the compiler, because there are 4 labels used as entry points and jmped to from other code, and it's one of these that is getting duplicated. We can only have the label at one point and calling it different things doesn't help, because how to we get the generated name? So, being unable to make any progress, I decided that it was not worth the time I was wasting on it, proclaimed it a lost cause, and went to deal with an issue that was more critical

[MX682X]

"Typical" (one of my examples for ptc_touch, t1614) savings:
with -fshort-enums: 4046/254
without: 4212/261

about the precompiled libraries: I had no trouble, but I'm not using any avr-lib functions (I think) like division or complicated multiplication, so can't tell you right now, but I could just open a pull request and see if there will be any errors and also see for a size difference...

[SpenceKonde]

Put it into DxC with SpenceKonde/DxCore@a9966ad

Test results look like this: https://github.com/SpenceKonde/DxCore/actions/runs/6370301171/job/17291277671

No change. Nothing. Nada. Zilch. Zero. Goose egg.

I therefore conclude two things.

1. On the version of the toolchain I distribute, -fshort-enums is on by default (it's implementation defined, this is on by default on many embedded platforms) according to the internet, while looking unsuccessfully for where to look to find the list of the default options).
2. The version of the toolchain you are using does not default to -fshort-enums.

I would thus expect that Microchip would be using a compiler version that is no newer than 7.3 (and I hear it may be even older what they use). Let's face it, 90% of precompiled libraries are probably going to come from them. The rest being hardware specific drivers for sensors whose manufacturers are willing to niether build in a powerful enough controller IC to do it's own complicated math, nor reveal their algorithm in source code. Bosch has done this - I briefly looked at the BMP680's library for calculating AQI for the m2560 (they had to use that because it was pre-DX and their code is so bloated and awful that they needed the flash and ram). I think they used an "innovative" method to make the dissembly of the library less helpful: Just don't worry about binary size or nothing and then throw the whole bloated mess into a single library, so the wouldbe reverse engineer finds themselves staring at dozens of listings, it's all pre-link so the jumps and calls aren't filled in (but this can be worked around, I forget how, but that was only moderately annoying. Anyway, do you notice a pattern? * Precompiled libraries only come from companies.

• They do it out of the typical IP hoarding obsession. I know I couldn't repeat the arguments speaking to the advantages for the users of precompiled libraries and keep a straight face.
• The code in the libraries is often TERRIBLE
  • Sometimes, the code is so awful it would be an embarassment to open-source even if they wanted to
  • Bloat is ubiquitous, as can often be quickly spotted in listings.

Actually, avr-gcc 7.3 may not even give an option here! I don't think it changes anything for me even if I do -fno-short-enums to try to turn it off.

mTC release incoming very soon I think. Then I gotta get DxC working with millis disabled again (I do not know from whence the bug came), but it seems very very strange - for some reason the compiler is emitting a call to 0 in main.... but only when millis is disabled o_O

[MX682X]

I can image that the reason why there is no change is because all enums are written to 8 bit registers (from header files) and thus are optimized away. Either way, the footprint of my ptc library shrinks by about 2% (Flash) by using short enums, as I'm using an enum type as argument for the callback.
Also, I've checked, I am using indeed the correct version (I also have newer releases, but they had a register allocaton bug. Didn't manage to check 13.2 yet....).

P.S. Would be cool to integrate the library into mTC with the upcoming release, I'm a failure when it comes to search engine optimisation (and naming. I mean ptc_touch? the t in ptc already stands for touch...). Anyway only one person seems to have found and (successfully) tested it...

[SpenceKonde]

I would love to include the library, just tell me when its ready or drop a PR. It will not make it into next release as I'm doing a last check of the CI and releasing, then going back to do emerg release for DxC once I get that working (with millis disabled, the fucking compiler is emitting a call to 0 at the start of main... WTF....

SEO? I dont listen to hiphop.*

This repo ends up in the top 10 google hits for most relevant terms completely naturally. Now I've never done SEO, for the same reason that I've never mugged or murdered anyone - it's an unethical and antisocial act (in the behavioral psych meaning, not the colloquial meaning). Despoiling the world and degrading search result quality to unfairly push your site higher. I was offered once SEO help (not for free) from someone I knew IRL, saying he could improve my rank on search engines. I searched for a few relevant part numbers and the words pinout or arduino, and linked him to it and said something like "I dunno I don't think I search engine placement has been a problem without SEO..." . He reacted with awe and sorta seemed to fear me since then....

What exactly did he do? Well, you know all those junk results you sometimes find that look like someone spent 2-3 days researching something on reddit, banged out a highschool level summary that contains your search terms but never anything you didn't already know and somehow that's most of the first page of results? That's because that's exactly how those crap pages get created. That's what he did. It's an irresponsible occupation - digital pollution. Only unlike chemical pollution, where the pollution was an unintended consequence of their doing buisness recklessly (though it's hard to imagine it was unforeseen) to these digital polluters, the pollution is the product! At least they're in a business that is just irresponsible. They could be working in a call center with an autodialer targeting the elderly hoping to get someone with advanced dementia whom they can bamboozle out of their life savings. My parents get several calls like that a day. I don't know why we don't seem to be able to stop this - this seems like something the FCC could easily achieve. Some telecoms are abetting these people by letting them spoof their number; so you tell them that if they persist in carrying calls in the US

* - I dpm't know how widespread this phrase it; it's an expression of dismissal, as if you've never heard of something and think it's the name of some rapper. (it works better for that genre than others, as it also carries an implied snobbishness,