== 11/13/07, Grant Edwards == > 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*. > Shouldn't knowing which instruction set to use be enough? ... or just core version. IMHO this is how avr-gcc works. But C compiler is just part of whole c-libc-asm-linker chain, of course. It's time to make new design decisions and to invest time to flexible infrastructure, once > 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. > Why is the MSP430 port so problematic? Time sponsor, i guess :) == Well, i myself is going to update linux ti_usb driver patch. While it applies as is to 2.6.22 (and later, i guess), new attempt to move it from the dead point is worth of doing. Old and going-to-be-there new info about it can be found here: http://bugs.debian.org/415904 Basically i want to take a fresh view on the code, to optimize it a bit and to apply bugfix for a bug in usb conf. change crutch with multiple usb-serial devices. This fix was forgotten back in Spring. -- -o--=O`C #oo'L O <___=E M
