[rurban]

I once tried to get a IAR C++ embedded codebase to compile with g++ and it's stdlib on a very small chip. It eventually compiled but never worked. I'll have to rewrite it in C instead.

There were many hacks, like filling the stack with sentinels to detect it at run-time. The linker script was horrible. Rewrote everything from scratch. The resulting code was many KB too large for the available space, it would have needed to slim down the stdlib. Even with the much better optimizations and LTO it was still too big.

Nice for that time, but essentially unusable. The company needed 10 years for that code, my plan is to rewrite it in 2 weeks.

[ndiddy]

If IAR was able to make the existing C++ codebase fit in the chip's flash and GCC wasn't, that seems like a win for IAR. If you're selling products in volume, the cost of the IAR license is dwarfed by the amount of money you save by using a part with less flash.

[delfinom]

Depends on what volume means. I would argue most people aren't working on projects in the million of units volume where that cost savings isn't worth it.

[RealityVoid]

Lots of people are. It's usually small systems. Think PIC or RL78, 16 bit MCU's maybe some Cortex M. But they're everywhere and sold in the millions and you never even think about it unless something goes wrong and then you cuss at them.

[RealityVoid]

Methinks you were targeting some wierd-ish ISA that had near/far addressing and a larger memory space than the but core could address directly. Those have all sorts of quirks needed to make code work properly, quirks GCC probably never bothered to implement or optimize for. It's also probably why it never worked. Oh... you have a pointer? That's nice, but this is a near pointer and the data is outside of how much it can express.

[rurban]

No, that's a company firmware we bought with sourcecode to be able to extend it.

I'm pretty sure it's the stdlib, IO probably, which is only needed for debugging anyway.

[estimator7292]

Honestly I'd be willing to blame GCC for that one. IME its output is atrocious for embedded stuff. Few optimizations for the chips I use and absolute nonsense assembly trying to emulate CPU instructions GCC doesn't know exist in hardware. Binaries are regularly 3x larger than they should be. It's so awful I had to end up writing my tight loops in straight assembly because GCC couldn't handle incrementing a damn pointer in a sane way.

[rcxdude]

I haven't found that it's that bad but I have seen that IAR is a bit better at optimising for code side, to the tune of ~10-20% or so.

[rurban]

True. Always use -Os. Knows nothing about internal crc functionality. Many things need manual assembly.

I've tried sdcc, but this was atrocious in array access for 8bit Atmel. Only solved with asm