- Iar arm compiler vs gcc how to#
- Iar arm compiler vs gcc serial#
- Iar arm compiler vs gcc Patch#
- Iar arm compiler vs gcc full#
10) I don't remember "code quality" ever being a significant issue.
Iar arm compiler vs gcc full#
:-( Tools like eclipse that like to build and read a database of the full code base were. 9) we reached a point where our code was pretty much too big and too monolithic for other compilers to handle.
Iar arm compiler vs gcc serial#
We had gdb working over serial (or network) connections to the DUT, plus our own debugging capabilities (not so different from printf.) But it wasn't really a real-time system, either. sucks.) I don't know that we ever used much 'real time debugging.' I never did.
(or that "wasn't." Having a language standards committee make a decision counter to the way you've been doing things.
It's amazing how much stuff ends up in a large C program that isn't officially "specified" somewhere. If we had had a particular compiler vendor, we might have been able to bend them to our needs, and that might have been bad for us in the long run (dealing with Intel was "interesting." (really random things turned out to be major issues: discontinuation of multi-line string literals change in ordering of macro expansion vs string argument concatenation Weird things.
Iar arm compiler vs gcc how to#
7) Even so, gcc underwent significant and apparently random "churn" that kept us several versions behind while we figured out how to procede. 6) running on multiple platforms was a major advantage no windows PC environment was likely to work as we went from 68k workstations to solaris servers to farms of linux devices and/or personal linux systems. 5) keeping the same gcc compiler as we switched cpus was a MAJOR advantage for a very large embedded system, the toolset surrounding your compiler becomes very large, and it's probably not practical to duplicate it for multiple vendors. Also a "tools team" that did non-compiler tools. 4) We had a "compiler support team" that would apply our custom patches, interface with cygnus, carefully version-control and test new versions to see whether there were surprises, and integrate the compilers into what was eventually a rather baroque build environment.
Iar arm compiler vs gcc Patch#
3) being able to patch the compiler and associated tools was invaluable. 2) We started paying (cygnus) for stable versions of gcc. And lots of people who could argue with compiler hackers over whether various behaviors were bugs in the compiler or not.
In the beginning, we were looking at one poorly supported not-very-good free compiler (pcc, as shipped on various early 68k workstations?) with a new compiler (gcc) that created noticeably better code (more than 10% smaller over a large system.) As we added processors, architectures, people, and code, gcc pretty much kept up with us, and despite "looking", we didn't find any compelling competitors until Intel added bi-endian support for x86 (~2006) There were of course issues: 1) (in the early days) We had some compiler hackers. Starting on various 68k cpus, adding PPC, MIPS, x86, Sparc, ARM, and others as time went on. When I worked at cisco, we used gcc pretty exclusively. And there is still scaling in more ways than one. In theory, the chip vendors (Atmel, Microchip) provide similar assistance when they provide "custom" gcc-based tools. That's not a particularly good excuse avoiding gcc you can always pay more to reduce your costs :-) That *is* what the various vendors who charge for gcc are supposed to be doing providing the ease-of-use, customer-support, maintenance, and testing and "version change caution" on top of what the OSSW hackers who actually modify gcc are inclined to do.
0 kommentar(er)
