Jonimoose (./10) :
Compatiblity is and should not be an initial goal of a project like this. If someone wants to implement some backwards compatible features and functions that is fine, but right now making it so it is a smaller burden to maintain, package, and improve would be my goals.

A toolchain which is incompatible with all the existing programs would be of very little use, and compatibility as an afterthought is not going to work. Many existing programs depend on TIGCC features which can only be implemented if you design for them from ground up.

It doesn't have to be one singular crt0.s for all situations, but having a simple default one and then optional alternates for things such as Kernels and shells.

Have you looked at how many options the TIGCCLIB startup code has? Say hello to combinatory explosion! ld-tigcc allows the startup code to be pieced together at link time of the final executable, even with boolean logic (we have pieces of startup code for "option X and option Y and not option Z"), it would take thousands of different versions of crt0.s to handle all the combinations of options.

The linking would be handled by ld and with a proper ld script your final linking/wrapping code should be able to be done easily.

I strongly doubt that ld linker scripts can do all the things ld-tigcc can do. It might be doable by heavily patching GNU ld, but you don't want heavy patches! And I actually find ld-tigcc to be a much easier to maintain codebase than GNU ld, so I wouldn't want to start poking around in GNU ld to implement the missing features. Try reading GNU ld code and ld-tigcc code, then decide for yourself what is easier to maintain.

The lack of a MMU does complicate things somewhat most of that complications should be handled by the crt0.s from what I understand.

If you rely on the startup code to do the linker's job, the executable will be both larger and slower to start up. On a calculator, this matters! In addition, in practice, smart features (such as compressed relocation formats) require support from BOTH the startup code AND the linker, you can't just move everything to the startup code.

I get that you moved away from GNU ld and a converter in the past, but ld and friends have grown since then and it may be worth looking back down that route.

We found it to be much harder to make things work nicely if you have to work with a 3-step linking toolchain (objcopy to convert A68k AmigaOS Hunks objects to COFF ones*, ld -r to link together COFF objects, obj2ti to convert COFF to the native format) than if you have just one of them, for several reasons:
1. Every conversion step tends to lose information, but that information is needed to implement advanced features, and sometimes even to make basic things work without bugs or artificial limitations!
2. Adding a feature in a 3-step toolchain means 3 programs to modify instead of one (with GNU ld in particular being poorly maintainable). We already have to add support for most things in GCC, GNU as, A68k and ld-tigcc, having 3 linkers is not helpful! In practice, this meant that the old toolchain had nowhere near the features ld-tigcc has (see http://tigcc.ticalc.org/doc/ld.html).
3. As already mentioned, we found the GNU ld code to be very hard to work with, so we designed ld-tigcc to be much more maintainable.
4. The obj2ti converter was also subject to a licensing dispute with its original author (who in particular wasn't happy with us making changes he didn't approve of), and its code was very poorly readable (and ridiculously, the author complained about my changes to his mess of a code being "unreadable"), so seeing it gone was a nice side effect of the change.
5. ld-tigcc also made it possible to easily add debugging support (which had been planned for a long time). It produces both calculator output with all the debugging information stripped out and a ".dbg" file (actually a renamed COFF .o file) which can be loaded into Emu-TIGCC (or rather its builtin patched copy of GDB), both in a single linker run (whereas with GNU ld, you actually need to run something like eu-strip on the output to separate the debugging information from the rest). And ld-tigcc can even delete sections referenced only from the debugging sections from the calculator output, they end up in a section named ".deleted" in the .dbg file (not in .text, where only the actual program memory contents are in, in the same order as on the calculator, so the debugging information can be properly relocated by Emu-TIGCC).

* Note that we couldn't manage to get GNU ld to work directly on the A68k objects without running AmigaOS-patched objcopy on them. GNU ld is a really ugly codebase you really don't want to have to work on.

I was very sceptical at first when Sebastian started ld-tigcc, but when he showed me what even the first alpha version was able to do, I was quickly convinced that it was the way to go. We put months of work into it, adding more powerful features. Throwing it away would be a very big mistake.

I don't want to make COFF work with a newer GCC because I want to avoid patching gcc as much as possible. Any patches we do have should aim to be small and easy to port to new versions.

I think that's an unnecessary and unhelpful goal. It's a much better idea to invest the time needed to port the patch to newer versions (it used to take me 1-2 weeks for every new GCC branch). And if none of us can find the time to port the patchset, then it's much better to just stick with what's there (it's not like GCC 4.1 magically stopped working) than to throw away everything and attempt a rewrite (which IMHO would require much more resources to do properly than just porting the patchset). That said, I do think porting the GCC patchset to newer versions of GCC should be a priority and I complained many times about GCC4TI not even having it on their todo list while wasting weeks on micro-optimizations saving a couple bytes somewhere in TIGCCLIB, unnecessary build script changes etc. I think both you and the GCC4TI folks are overestimating the effort it is to port the patchset (though of course, the longer we wait, the more work it will be, because GCC is moving on!).

Part of the goal is to limit the amount of code that has to be maintained

Doing that at the expense of all the features which make TIGCC unique and at the expense of any kind of backwards compatibility would be a major disservice to our users.

and one of the worst culprits there is ld-tigcc.

It's one of the most maintainable linkers ever, we even tried to design it to be portable to other targets (though of course it would need some changes to actually achieve that). I actually think it's a big mistake of e.g. the Ndless toolchain to not have ported ld-tigcc instead of their quick linking hack and its limitations. (The Ndless toolchain also suffers from insisting on not using any GCC or GNU ld patches, instead relying on wrapper scripts and various hacks to work around GCC's and ld's limitations and inappropriate behavior for the target. IMHO, building a custom GCC with custom patches is unavoidable to build a clean, well-integrated, powerful and reliable toolchain.)

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

ROFL. The fact that you need a rather complex script to automate the build and install process even on linux tells me otherwise. DevKitPro's toolchain build script is very simple, basically patch, configure, make, install run 4 times. And the patches are mostly to add the target to GCC, the most invasive of which is the Wii patches as the CPU and binary format is customised more than others. Though the Wii is nice enough to have a proper elf loader.

You have a very strange definition of "distributed nicely"! My definition of "distributed nicely" is that it's nice for the user! The build process is complex, so what? The user just has to run setup.exe or "yum install ktigcc" and has a fully working toolchain with an IDE and everything set up. And even if they insist on building from source (that's supposed to be the packager's job, I did it for Fedora and W32), it's all scripted. DevKitPro doesn't even include an IDE!

It may be possible to do with ld-tigcc,

s/may be/is/ !

but considering that libtigcc would need complete rewrite as it is to support applications

Nonsense. It wouldn't need a complete rewrite at all. Just have non-SMC versions of the few functions which use SMC, or put the SMC in a data section (FlashApps can have BSS sections handled by AMS, data sections are easily implementable in terms of BSS sections by the linker: just store their initial contents in the text section and memcpy them to the BSS section at startup) and use the enter_ghost_space hack (which can actually be used to unprotect any 12, 28 or 68 KiB range of RAM depending on the AMS version; in conjunction with the ghost space trick, you can get at least 68 KiB of execution-unprotected RAM on all models, without dangerously messing directly with the protection mechanism) to unprotect the FlashApp's BSS section. And most of the "SMC" is not actually SMC, but only variables, those can easily be put in a data or BSS section. So what needs to be done is going through TIGCCLIB, finding the SMC and either changing it entirely or making a non-SMC version.

The startup code could need a rewrite, but I'm not sure FlashApps should even have startup code. I'd start with something very minimal or empty and port the parts of the regular TIGCCLIB startup code which make sense as I find them needed or useful.

there isn't much of the existing toolchain worth using

Nonsense. You're overestimating the changes required for FlashApp support by a lot. For TIGCCLIB, see above. For ld-tigcc, they are just a new output format, it's designed to handle multiple ones (see e.g. the Flash OS support!). For everything else, it should need little to no changes.

and there is little reason to hold onto ld-tigcc when you are replacing everything else.

But we aren't.