Lionel Debroux (./3) :
* the things that need most work, e.g. better-featured and more portable build/packaging scripts

That's completely useless for the user. And I don't see those changes as being needed or useful, my scripts work fine.

the examples,

The changes you did to the examples are only of extremely marginal use, especially to an experienced developer.

and the library;

That part is arguably useful, but how much have you really changed? AFAIK, not much.

* r1265 "Add Flash OS library." (so that people don't have to fetch it from an obscure place on Kevin's website - this kind of things, even if small, belongs to the development environment);

The reason it is not shipped with TIGCC is that it is experimental and incomplete. Nobody is interested in making it more complete. GCC4TI also hasn't done any such work.

IMHO things like the initial vector table (even if it's only composed of undefined references the OS has to fill in), common hardware initialization which any OS has to do and FlashROM unprotection/writing routines which pretty much any OS will need as well really belong into the Flash OS library, not into every single OS. Arguably even the whole contents of the 24 KB startup sector belong into the common library. But as PpHd actively refused to let me use any code from PedroM under the TIGCCLIB license, all such code will need to be rewritten.

Another part of Flash OS support in TIGCC which is also incomplete, and where GCC4TI also didn't do anything to make it more complete, is linker support for file formats: there's no support for exporting the current ??u format, only the obsolete/"outputbin" tib format which TI last used for AMS 1.05 in 1999. But as the file output code is currently duplicated in the Delphi IDE (and the Delphi tigcc.exe which uses the same code as the IDE), fixing this would involve also changing stuff in the Delphi code, or replacing the Delphi IDE entirely. (Note: ExtendeD gave me permission to reuse (under the GPL) the code from the tib2xxu executable which ships with FreeFlash, so you don't have to start from scratch if you're interested in doing that work, you can start from this code. This permission does of course not extend to any other part of FreeFlash.)

So there's a reason, or even two reasons, why flashos.a is an optional, experimental addon to TIGCC. You just added it to GCC4TI without fixing any of the actual issues.

* r1272 "Add implementation and documentation of special __ld_bss_even_end symbol, resolved to the first even address after the end of the BSS section.";

This can be done without in several ways (runtime computation, adding a char pad; variable if the length turns out odd, using __ld_bss_end+1 if the length turns out odd etc.), I really don't see how this is so urgent, or even a needed feature at all (though I don't object to it in principle).

* maybe r1325 "GCC 4.1.2-tigcc-4: Fix a 64-bit compatibility problem in the AMS float support, which triggered harmless warnings in the generated assembly code.".

"Harmless warnings" says it all. The resulting generated object code is perfectly fine. This is a very harmless bug. Not a showstopper at all.

AFAICS, none of those has been backported to TIGCC. But then, Kevin has done pretty little on TIGCC in the past 15 months since GCC4TI was publicly announced.

I'm sorry, but I consider CalcForgeLP to be more important for end users, so I'm spending most of my "TI calculator" time on getting the CalcForge software into a releasable state (which implies to do renames properly, not like you who still illegally use names such as "TIGCCLIB" or "tigcc.a").

In addition, the GCC4TI SVN has also not been touched for 9 months!

There are two development branches for ld-tigcc that are useful to you (and others), but need more work:

"Need more work" says it all: those work branches are not ready for user consumption.

* the ld-tigcc-optimization branch, which aims at making the linker faster, noticeably so for programs larger than several dozen kilobytes. The only data structures used in ld-tigcc are arrays and linked lists ( topics/108648-ld-tigcc-flash-os-bss-special/4#108 ), and as a result, ld-tigcc spends 10 minutes building PedroM, 90% of which are spent traversing linked lists ( topics/108648-ld-tigcc-flash-os-bss-special/4#111 )...

10 minutes on what hardware? Certainly not the current 32 nm Core i7 CPUs which didn't even exist in 2008 when this was measured.

And are your optimizations anywhere near done? Are they even started yet? I see nothing at all in your SVN repository! The branch hasn't been touched for 16 months (!) and these are your "tree" operations: http://trac.godzil.net/gcc4ti/browser/branches/ld-tigcc-optimization/tree.h?rev=1288. You can hardly get more fake. You haven't optimized anything at all in that branch so far. I can easily create development branches and promise the moon like you do, but it won't make this any more real for our users. At least the KTIGCC 2 HEAD which you call vaporware can actually be compiled (against KDE 4, as it promises) and run (it even compiles with cross-MinGW, though it certainly has more bugs there as there are still some unixisms in the code), it just has a couple showstopper feature regressions I didn't get around to work on because my time was spent on higher-priority projects (university projects, CalcForge renames etc.). And you didn't do any work on KTIGCC (which BTW you have to rename to KGCC4TI if you want to do releases of that codebase).

* the ld-tigcc-flashos-improvements branch (and its doc-related branch), which contain a number of improvements to the Flash OS support made by Patrick's modifications to improve Flash OS support. That's what he's been using for PedroM for a while.

This work is also extremely incomplete (and also hasn't been touched in your SVN for 16 months):

PpHd (./5) :
You'll need this for Punix. It adds one option :

--flash-os-bss-start=$(FLASH_OS_BSS_START)
(usually FLASH_OS_BSS_START=0x5B00 )which defines the start in RAM, of the BSS section allowing you to define global variable in .c files as usual.

While this is nice in theory, in practice it works quite poorly because the required work on optimization in the assemblers and the linker was not done: destination operands cannot be optimized by the linker (because the assemblers don't emit sufficient information for that into the object file), so whenever an absolute address is used as a destination operand, it will be coded in 4 bytes instead of 2 (which also slows down the code, in addition to making it larger).

The good old technique of using things like:
.equ variable1,0x5B00
.equ variable2,0x5B02
…
or:
#define variable1 *(short*)0x5B00
#define variable2 *(long*)0x5B02
…
(which PedroM had been using just fine for years) will still generate much more efficient code than your incompletely implemented syntactic sugar.

In addition, your patch also lacks IDE (and tprbuilder) support and support in the Delphi tigcc.exe for the added linker switch.

It adds also new symbols:__ld_archive_start: just after the end of the code, rounded to 64K

This can simply be hardcoded with an equate or #define.

__ld_bss_even_end: just after the end of ram BSS section, rounded to 2.

And I already elaborated on the "usefulness" of this one above, not to mention that it's only useful at all for Flash OSes in the presence of your incomplete --flash-os-bss-start feature.