Jonimoose (./3) :
As Lionel said You aren't the first person to suggest this, me being one of the others and I agree there would be much to gain by starting fresh with a new tool-chain.

I think there would be much more to lose than to gain! Not only would this be completely incompatible with TIGCC and all existing software for it, it would also have some additional issues:

2. Write a _start function/crt0.s and ld scripts for the calculators, for the ld script just have it target binary, the _start/crt0.s would need to be written in m68k asm by someone who is familiar with writing ASM programs for the calculators. The _start function is responsible for setting up the ram and flash data sections and making sure they are in the correct locations, with the LD script specifying where those locations are. Again you have to be familiar with how the AMS works, where programs are located in memory when ran and other such things.

Having one fixed crt0.s would lead to much larger binaries and/or much less flexibility (probably both) than ld-tigcc's configurable startup code.

It is also not possible (without very ugly hacks) to execute the code in a fixed location, so relocation is a MUST. Remember that we do not have the luxury of an MMU, nor do we have large spaces of "safe" RAM as on the Z80 OSes (which are written in assembly and thus handle memory very differently).

3. Write a tool to take the outputted binary and wrap it in an 89p or w/e format it should be. Starting with http://www.ticalc.org/archives/files/fileinfo/399/39967.html might be a good idea, and it may even be possible to use unmodified. Currently tigcc uses a custom linker that is just a mess and uses the COFF format making it totally unusable for with newer GCC's as Lionel said. It may also be worth writing a tool not based on libtifiles as to avoid the glib dependency though I'm not sure how big a deal this really is.

You cannot just "wrap" a binary, you need to actually link it. Otherwise, relocations will not work. See above. (Even the most minimalist "converter", obj2ti, at least did the most basic relocation conversion. But it was scrapped in favor of ld-tigcc which is just much more powerful than the GNU ld + obj2ti chain we used before. Yes, we actually moved away from using GNU ld plus a converter to using a custom linker.)

And as I replied to Lionel, 1. I think we can make COFF work with a newer GCC and 2. if not, then support for whatever replacement format we pick must be added to ld-tigcc. (It is made to handle more than one format, it already supports 2 of them: AmigaOS Hunks and COFF.)

4. Get the libraries in order, much of libtigcc may be reusable here such as sprite and AMS specific routines, I would avoid any that use SMC as if we want to support Applications in the future they will be unusable. Newlib may also be worth looking into for libc, libm and such, though I'm not sure what AMS provides for stdc functions.

The AMS provides several standard C functions, but not all of them. The problem is that we really want to use the functions in AMS where they exist for space reasons, but that they aren't always fully ISO compliant and that mixing newlib and AMS functions isn't going to be easy. Newlib is also quite a mess licensing-wise (a copy&paste of tons of different BSD-style licenses, all requiring that you accompany binaries with a copy of the license if they include the given function, a total mess logistically; needless to say, most programs using newlib do not comply with the licenses of the newlib functions at all ).

5. Distribute it nicely as I suggested to Lionel and he mentioned in his post DevKitPro, which is a set of GCC based cross-platform tools-chains for the NDS, WII and PSP, do this wonderfully in a manor that allows for minimal platform specific work, though toolchains on Windows are always a bit of a pain no matter how you do it.

I don't think it can be distributed any more nicely than TIGCC already is.

6. Add Flash Application support if you didn't already handle it with 2. I know nothing about the 68k calcs flash application formats and what is involved there but I'm sure Lionel and others would be of help.

That's a job for ld-tigcc (and actually wanted now that there are at least 2 ways around the signature lockout).