Hi Sergey, I am trying to build the new mspgcc tools. I compiled the binutils and the msp430-gcc with the sources from the repository (new branch).
My problem now is when I try to compile libc I get the following error during the compile: [...] msp430-gcc -c -I./../include -I. -Wall -O2 -g -mmcu=msp1 -c stdlib/abs.c -o msp1/abs.o cc1: error: MCU msp1 not supported Known MCU names: msp430x110 msp430x112 msp430x1101 msp430x1111 msp430x1121 msp430x1122 msp430x1132 [...] (null):0: confused by earlier errors, bailing out make: *** [msp1/abs.o] Error 1 Do you have an idea, why my new msp430-gcc doesn't accept msp1 as argument for mmcu? Thanks in advance -------- Original-Nachricht -------- > Datum: Mon, 26 Jan 2009 22:55:48 +0200 > Von: "Sergey A. Borshch" <[email protected]> > An: "\'GCC for MSP430 - http://mspgcc.sf.net\'" > <[email protected]> > Betreff: [Mspgcc-users] 430X support branch in cvs repo > Hi everyone. > > I created branch in mspgcc repository (tag MSP430X_fartext) an submitted > my additions: > > - calla/reta/bra instructions generated for 430X core > - pushm[.a]/popm[.a] instructions in prologues/epilogues for 430X > - __attribute__((__far__)) for placing data (const) and functions into > high memory. > - -mdata-64k option for disabling far data support. Now it disables > attribute((far)) for const > data, replaces pushm.a/popm.a to pushm.w/popm.w (and movx.a/mova to mov.w, > pushx.a/popx.a to > push.w/pop.w in libraries compiled from assembly), in future it should > generate all 430 data > processing instructions instead of 430X and reduce pointer size from 32 > bits to 16 bit. Code will > became faster and smaller, less stack usage in price of no far data and no > pointers to far functions. > - -mcode-64k option for disabling far code support. This option disables > __attribute__((__far__)) > for functions and generates call/ret/br instead of calla/reta/br. Faster > and smaller code in price > of no far functions. > - .farrodata section added to 430X ld scripts. > - multilib support: > * separate libraries for 430/430X cores without hwmul/with HWMUL/with > HWMUL32 (need to write > routines for HWMUL32, they are the same as for HWMUL now). > * separate lib for 430 cores and -msave-prologues option. > * separate libs for 430 cores with HWMUL/HWMUL32 and -mdisable-hwmul > option > * separate lib for 430 cores and -msave-prologues and -mdisable-hwmul > option > * separate libs for 430X cores and all combinations of > -mdisable-hwmul, -mdata-64k, -mcode-64k > options > * separate libs for 430 cores with CPU4 bug (so mcu's without CPU4 > bug should use more fast and > short library functions without CPU4 workaround). > * 36 library sets in total :) > > one disadvantage: improper option (-msave-prologues with 430X mcu or > -mdata-64k with 430 mcu) leads > to linking default library (library for 430 mcu without HWMUL). The only > workarounds I see: > 1) edit specs file - remove unmeaning options from multilib selection > lines. Need to write sed(?) > script. Who helps? > 2) or build fake default library and remove it after building. This > leads to unresolved symbols > and forces user to check options. > > ------- > todo: > - full far data support (including 32bits pointers and table jumps in > far code) - need to > rewrite almost all msp430.md file. > - full HWMUL32 support - need to add 32*16, 32*32, 32*64, 64*64 to > libgcc.S and calls to msp430.md. > > feedbacks, patches and help are welcome. > > -- > Regards, > Sergey A. Borshch mailto: [email protected] > SB ELDI ltd. Riga, Latvia > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
