On 2007-11-14, Oleg Verych <[email protected]> wrote:
>> For the Nth time, I'm once again stuck because mspgcc and/or
>> binutils doesn't know about the device type I'm using (this
>> time it happens to be the MSP430F2330).
>>
>> Why does the compiler have to be aware of the exact part I'm
>> using?
>
> Maybe this is because of the ``usual'' application for IA-32
> or AMD64 types of *CPUs*.
No, it isn't. There are ports of mspgcc to other architectures
(e.g. H8, SH, 6812, 68K, ARM etc), that all have scores and
scores of different models, and none of them have the problems
with CPU model support like mspgcc does.
However, most of those ports don't include header files for the
peripherals at all like the MSP430 does. That requires you to
know enough about embedded systems development to be able to
choose and modify an include file or a linker script. mspgcc
tries to hide everything beneath the covers. The problem with
that is that it limits the usage to the cases that have been
previously set up.
But, it's easier and faster to spend 30 seconds modifying a
linker script and include file than it is patching and
rebuilding an entire toolchain.
>> Shouldn't knowing which instruction set to use be enough?
>
> ... or just core version.
Same thing, isn't it?
> IMHO this is how avr-gcc works.
And gcc for the H8, SH, ARM, 6812, 68K, NIOS2, etc.
> But C compiler is just part of whole c-libc-asm-linker chain,
> of course.
True, but I don't see your point.
> It's time to make new design decisions and to invest time to
> flexible infrastructure, once
I think it would reduce support headaches if the toolchain
didn't know about every individual CPU model number. Just
provide code generation options (HW mult or not, 20-bit
addressing or not). Providing include files for the different
peripherals is great, but that doesn't need to be hooked into
the toolchain.
>> GCC ports for other processor families (e.g. Hitachi H8) don't
>> have this problem: you tell it which of the three or four
>> instruction sets to generate code for, and you're on your way.
>> The H8 port doesn't have to know about the 50-100 different
>> processor model numbers, since they all have common
>> instruction sets. Hitachi can introduce new parts until
>> they're blue in the face, and you don't have to upgrade gcc
>> since the new parts all use one of the already-supported
>> instruction sets.
>
> MSP430 itself and mspgcc are going to go up in numbers.
Which is why the close coupling between the MSP430 model
numbers and the toolchain is going to become more and more of a
problem in the future.
--
Grant Edwards grante Yow! Somewhere in Tenafly,
at New Jersey, a chiropractor
visi.com is viewing "Leave it to
Beaver"!
