Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical comparison of ARM compilers

m0agx.eu

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Practical comparison of ARM compilers

#11

Post by sigsev_251 »

nagisa wrote: post #6

I have not seen a compiler that incidentally ICEs (crashes) more than IAR does (experience from c. 5 yrs ago.) Early-days rustc may come close, but experience is likely skewed by my perspective as a rustc contributor too. And then we were always using IAR in a way that disabled all and every optimization; if enabling them did not lead to a compiler imploding, the compiler would produce invalid machine code even for t…

Really? I would expect more than that from an EDG based professional compiler. A friend of mine uses the STM8 version in his workplace and he swears by it (though he still prefers SDCC due to C2x support)

Re: Practical comparison of ARM compilers

#12

Post by sigsev_251 »

tiniuclx wrote: post #5

I've been using GCC & friends for a few years now, building mostly for the Cortex-M23. GDB has been a godsend, with a J-Link you basically have as much runtime debugging support as you would on a hosted system. This is especially helpful in cases where logging would slow down the operation of the system too much. We're also very successfully using CMake as our build system, as opposed to Make itself. It lets you orga…

You're lucky. I wish my vendor's proprietary toolchain was supported by CMake

Re: Practical comparison of ARM compilers

#13

Post by cozzyd »

tiniuclx wrote: post #5

I've been using GCC & friends for a few years now, building mostly for the Cortex-M23. GDB has been a godsend, with a J-Link you basically have as much runtime debugging support as you would on a hosted system. This is especially helpful in cases where logging would slow down the operation of the system too much. We're also very successfully using CMake as our build system, as opposed to Make itself. It lets you orga…

gdb + J-Link is indeed a superpower. I sometimes leave in a static size buffer to provide some scratch space for abusing gdb as a repl for testing...

Re: Practical comparison of ARM compilers

#14

Post by jeffreygoesto »

I remember an ARM person stating: "We thought we're building those chips, who else could optimize for them better than us? Then we learned how little we know about C++ and the next version will be clang based.". That was back when we filed a number of RealView 4 compiler bugs...

Re: Practical comparison of ARM compilers

#15

Post by pjmlp »

cozzyd wrote: post #9
nona42 wrote: post #4

For Armv8.M and MVE, I expect that Clang and Arm Compiler for Embedded, which is Clang/LLVM based, generates much better code than GCC or IAR. Regarding code size: the common pitfall is -Os for GCC and -Oz for Clang based compilers to optimise for minimum code size.

Does the Arm Compiler for Embedded have significant changes to upstream clang? I'm somewhat concerned that clang not being GPL may eventually become unfortunate for embedded...

It isn't as if Sony and Nintendo are contributing all their changes to upstream.

For example any improvements that may reveal NDA stuff from their consoles never gets upstream.

Re: Practical comparison of ARM compilers

#16

Post by nona42 »

pjmlp wrote: post #15
cozzyd wrote: post #9

Earlier quoted context omitted.

Does the Arm Compiler for Embedded have significant changes to upstream clang? I'm somewhat concerned that clang not being GPL may eventually become unfortunate for embedded...

It isn't as if Sony and Nintendo are contributing all their changes to upstream. For example any improvements that may reveal NDA stuff from their consoles never gets upstream.

For games, most performance critical code probably does not run on the CPU but on the GPU. I believe they use pretty standard open source CPU compilers and Sony e.g. do contribute to LLVM.

Re: Practical comparison of ARM compilers

#17

Post by pjmlp »

nona42 wrote: post #16
pjmlp wrote: post #15

Earlier quoted context omitted.

It isn't as if Sony and Nintendo are contributing all their changes to upstream. For example any improvements that may reveal NDA stuff from their consoles never gets upstream.

For games, most performance critical code probably does not run on the CPU but on the GPU. I believe they use pretty standard open source CPU compilers and Sony e.g. do contribute to LLVM.

I didn't said they don't contribute at all, rather "any improvements that may reveal NDA stuff from their consoles never gets upstream."

How do you think shader code gets compiled into GPGPU machine code?

Post reply on HN