9Fermer11
JonimooseLe 03/07/2012 à 01:49
Kevin Kofler (./9) :
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:

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.
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).
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.
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.)
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. The lack of a MMU does complicate things somewhat most of that complications should be handled by the crt0.s from what I understand.

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.

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. Part of the goal is to limit the amount of code that has to be maintained and one of the worst culprits there is ld-tigcc.
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 roll).
Yes, as I found out newlib is a bit of a mess. In the case of the Casio Prizm we are slowly reimplementing the needed libc functions as we go. Its actually working quite nicely and they are close to having a working port of Python.
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.
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.
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).
[/cite]It may be possible to do with ld-tigcc, but considering that libtigcc would need complete rewrite as it is to support applications there isn't much of the existing toolchain worth using and there is little reason to hold onto ld-tigcc when you are replacing everything else.