* 2007-12-27, Xiaofan Chen:
> On 12/27/07, Oleg Verych <[email protected]> wrote:
>> * as it seems to me, there are almost no pure-non-Windows(R) people here
>> * 8k is quite better, than IAR's 4k
>> * without fsck-ups form compiler vendors
>> ** TI can control quality for both uCs and Ccs/asms
>> ** same for mortals uC users -- emb. developers
>>
>> - bad thing is, that generally it's not fair, if codebase was started
>> from the original msp430 GCC port and nothing goes back.
>
> I do not think the CCE C compiler is GCC based judging from
> the compiler user guide.
> http://focus.ti.com/lit/ug/slau132a/slau132a.pdf
I have this clue (in sense of overall toolchain, not only C front end),
after reading slau157d.pdf (Appendix C and D). And now, after walking
though tools/, i can say for sure (searched exe's for "gnu"), that not
only GDB has GNU origin/traces.
> Normally big MCU companies do obey GPL.
This is not the case. As for me it is support for uC without proprietary
compiler vendor's games, i.e. vendor's (who's business is compilers
only) dirty bits-trading.
I am posting the link, because history part of wikipedia's article
is very dry on more than 22 years of GCC's history.
http://www.toad.com/gnu/cygnus/index.html
The case is support, good support of the toolchain. While TI has its own
history of the toolchain development, they may just adopt relatively
maintainable part of the own compiler to the GNU flesh. Maybe it was
simply done by outsourcing third party. But TI now has a tool it supports
on official level and _big_ customers now can invest time and money
into silicon more easily.
All this already social, money and marketing stuff. Technically
MSPGCC(2001), CCE (~2004), as it seem, have no problems. Maintaining,
support and profit (financial for vendor and application for user) are.
> If it is GCC based, TI will have to publish the source code
> of the compiler.
The Sources, btw, may/can be published, if somebody asks for it (as per
GNU GPL).
If a _customer_ will ask for it, which is very improbable, i think, they
will publish sources (just for customer :).
Where GDB sources, or standard GDB tarbal has ABI compatible MSP430
support?
> Other than Atmel (AVR32), very few MCU companies directly
> support Linux and/or full GNU toolchains. Some MCU vendors
> based their compiler on GCC but that does not mean
> the compiler will be fully free since they can add proprietory
> optimizer or use a different C library.
ADI supports its DSP arch: <http://blackfin.uclinux.org/>.
[]
> So Atmel does set a good example (full toolchain, including
> support for the hardware JTAG debugger) for AVR32.
Bloated with all other archs mega-giga tarbal, which is just a waste
of the network bandwidth.
> But they do not do this for their AVR 8-bit MCU.
They didn't have must $upport base, so others and gurus were having fun.
--
Efficiency in coding and building of software is an another problem. GNU
make, autoconf, libtool and all other tools is the very good known crap.
Unfortunately, "customers" are not going to solve such fundamental
problems. Time-to-market is the only idle() and task() almost everywhere.
TI isn't going very deeply in all that Free? Open? Who-Is-Who? Source?
and software stuff. Patents on double-clicks, piracy, dot coms etc.
Making high-quality support, learning and evaluation programmes is much
better to have. And dev tool like free of charge CCE, supporting only
MSP430 is kind of natural self-supporting feature.
Maybe step-by-step support of tools, like MSPGCC, will be available, if
it will become more clear and easy (in many respects, not just
rhetoric).
> I'd like to see companies support more and more Linux but we have to
> wait. Or better, we can support project like mspgcc/avrgcc/gnuarm/etc
> buy using them.
What about "also by donating, sending patches and not asking obviously
stupid i-want-this-now-quickly questions?"
I wonder how much C source is actually shared there? I have thoughts
about whole boloney of the source reusing. Scale is from arch
(asm-optimized routines) to social (macros/function naming) issues. I'd
better to write most of the stuff in asm with a really good macro
processor, like `sed` scripts, rather than to type stupid voids, braces,
semicolons and read doxygen crap in the comments...
An agreed official MSP430(X) ABI and good linker are Questions, not C.
----
> Let's face it, most of the electronics engineer still use
> Windows at work and Windows XP SP2 is actually
> quite good in most cases.
Linus Torvalds is doing hard only one thing, unfortunately -- it is the
kernel (as whole and small parts technically). Everything else, even Free
and Open $$, is a very-very big "bad"
http://www.planetanalog.com/article/printableArticle.jhtml?articleID=202100506
_