> > To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..." > > thanks. is that a 4.02 option? i can not find them on my 3.4 gcc man page.
The r8c/m16c/m32c port is new. Currently, it's only in the mainline CVS sources, and will be "officially" released in the gcc 4.1 series. > > gdb and a simulator are still in progress. > > that seem ok since i currently only need gcc. You'll need binutils also, at least, and probably newlib to get crt0 and some sample libraries and linker scripts. > and, because i am new to the field , i want to ask, what is a > 'simulator'? run target excutable on host computer? Yes. > > That's a different attempt to port gcc to m16c, and has nothing to do > > with what I did. > > sorry, are you the author of the new m16c/gcc code? i noticed your > domain name is redhat. I am one of the authors, and the current maintainer. > do you mean, the current m16c/gcc code never compiler c++ code? No, it just means I haven't tried it recently. It mostly worked back when I was working in that area, but "mostly" wasn't good enough for what I was doing, so I just skipped it, as I didn't need C++ back then. > C++). though you pointed that i could build for my self, but in fact > i can not, i know nothing about compiler writing :( Compiler building, not compiler writing. I already did the writing part. > so, i am thinking another question. if i can write the code which > can pass both the current (3.4) g++ compiler and the IAR M16C C++ > compiler, so my problem will resolved. but is it possible of the > idea? i think i can use some #ifdef statements and move any IO into > stubs. how different are these two compilers in C++ syntax? The pragmas for assigning addresses to I/O variables are different, but it's only a header change to get them working with gcc. Note that g++'s C++ is much more strict and current than most other C++ compilers; it's likely you'll have to fix your code to get it to work, but this would be due to code bugs and not g++ bugs if so.
