This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.
Date: Tue Dec 20, 2005 8:42 am
I need an environment/C-Compiler that will allow me to program the HCS12X CPU and XGate.
I am looking for alternatives that are less expensive than Code Warrior 4.1.
Up until now, we have been using Hiwave/Panta to build code for our HCS12.
Thanks
Date: Tue Dec 20, 2005 8:52 am
There is a free special edition available from Freescale:
http://www.codewarrior.com/MW/Develop/Embedded/HC12/S12X.htm
This is the successor of what you have today.
Of course there are other options/vendors.
Date: Tue Dec 20, 2005 9:04 am
I said I am looking for alternatives.
Date: Tue Dec 20, 2005 6:12 pm
> I said I am looking for alternatives.
I know how that is 
There is a small group I know, trying to make GCC work with XGate. The initial idea is that S12X can be compiled using at least macros to do extra X stuff. The problem so far is that a lot of stuff is too complex, and getting XGate to work along with S12X would take a lot of rewrite. There would be two gdb executables, one debugging the S12X and the other debugging XGate concurrently.
Since it's so much work retargeting GCC to XGate (and much overkill), one idea is to get an independent XGate assembler or simpler C compiler working with some way to link this code so GCC can use it.
The small group is trying to work off of the GCC port discussed at:
http://groups.yahoo.com/group/gnu-m68hc11/
But they are only having private discussions on the XGate version at the moment, I guess sort of brainstorming.
Comments on what direction they should be going, anybody?
Date: Wed Dec 21, 2005 5:09 am
> There is a small group I know, trying to make GCC work with XGate.
>
> [...]
>
> Comments on what direction they should be going, anybody?
My thoughts:
because gcc is not too well suited for 16-bit architectures with small number of registers, maybe it's easier to retarget another compiler, better suited for small micros, sdcc for example. Doing so, my suggestion would be to stay compatible with gcc on the output side (object and assembly files), to be able to reuse rest of the GNU toolchain and not have yet another assembler, linker, etc. In reality, I just don't know how feasible is that ...
Date: Wed Dec 21, 2005 7:14 am
> because gcc is not too well suited for 16-bit architectures with small
> number of registers, maybe it's easier to retarget another compiler,
> better suited for small micros, sdcc for example.
I heard they are looking at SDCC over gcc for this reason. But I don't have any more info than that.
Date: Wed Dec 21, 2005 9:16 am
> > because gcc is not too well suited for 16-bit architectures with small
> > number of registers, maybe it's easier to retarget another compiler,
> > better suited for small micros, sdcc for example.
>
> I heard they are looking at SDCC over gcc for this reason. But I don't
> have any more info than that.
Anybody know about TCC (TinyC)? That's the next one in the list. Turns out TinyC "supports the full complement of ISOC99", whereas SDCC does not. Also a preliminary ruling says TCC has a better back-end to make the port. One thing is that it would apparently be easier if TCC emitted asm instead of code.
