Priorités dans la todo/wish list... - Page 1

When I filled in the todo/wish list in the Trac, I gave them some priorities.
I think we could discuss about those priorities, and change them according to the items thought to be most important and/or the items for which there's the most manpower

Note that as long as the fork contains only changes that are invisible by a large majority of users, such as:
[ul][li]the changes to the documentation I committed make it easier (IMO) to maintain and extend, without having to rewrite the tools right now... but for the generated HTML pages, my changes are no-ops (I checked)[/li]
[li]ld-tigcc: __ld_link_time_* builtins (committed) et PpHd's patches for PedroM (not committed so far)[/li]
[li]integration of the FlashOS support archive 'flashosa', which contains only the header of a Flash OS (wonder why this was not already in TIGCC ? You're not alone.)[/li]
[li]addition of stdint.h (and maybe inttypes.h)[/li][/ul]
I don't think making public builds is worth the trouble...


The following features, for example, would be noticeable by more users:
[ul][li]#20 ld-tigcc optimization (see topics/108648-ld-tigcc-flash-os-bss-special/4 for profiling info), although the slowness of TIGCC is much less noticeable on < 64 KB programs than on PedroM + large test suite[/li]
[li]#16 standardized library for usual ADTs, and less usual things such as compression (and program launching ?). I think we already have some code (Flanker & geogeo; others ?). Maybe a bit of unification would be necessary... and I guess the doc is not in TIGCC Help System Format...
(I'm fine with Doxygen-type documentation for a couple of releases, I'm using Doxygen in the upcoming ExtGraph 2.00 Beta 6)[/li]
[li]#15 add back VTI transfer support in the Delphi IDE, in addition to the TIEmu support (but we must IMO add a dialog, or information note, 'use only if you know what you're doing: VTI has a number of known bugs and limitations, and it doesn't emulate V200 and 89T !')[/li][/ul]

I've looked into #20 (ld-tigcc optimization).
topics/108648-ld-tigcc-flash-os-bss-special/4 tells us two things:
[ul][li]The major performance offenders are the Reloc and Symbol linked lists[/li]
[li]the data structure faster than linked lists that we're going to use should be a tree structure[/li][/ul]

Finding a red-black tree library is easy: there's a GPLed one in the Linux kernel.
However:
[ul][li]mapping the InsertAfter, InsertBefore, Append, Push list operations to a colored tree structure is maybe not that trivial[/li]
[li]the list macros are used at dozen of places (most places just _read_ the lists), and each of these places must be changed...[/li][/ul]

Lionel Debroux (./1) :
ld-tigcc: __ld_link_time_* builtins (committed) et PpHd's patches for PedroM (not committed so far)

Did you commit it?

Lionel Debroux (./1) :
#20 ld-tigcc optimization (see topics/108648-ld-tigcc-flash-os-bss-special/4 for profiling info), although the slowness of TIGCC is much less noticeable on < 64 KB programs than on PedroM + large test suite

Do you know how to build PedroM with a large test suite to test performance?

Lionel Debroux (./2) :
Finding a red-black tree library is easy: there's a GPLed one in the Linux kernel.
However:
mapping the InsertAfter, InsertBefore, Append, Push list operations to a colored tree structure is maybe not that trivial the list macros are used at dozen of places (most places just _read_ the lists), and each of these places must be changed...

Writting it from crash is easy too

ld-tigcc: __ld_link_time_* builtins (committed) et PpHd's patches for PedroM (not committed so far)

Did you commit it?

No, I didn't yet.

Do you know how to build PedroM with a large test suite to test performance?

No, I don't. But anyway, PedroM + test suite is not going to be my first test target: if the modified linker doesn't produce binary-identical files for several TICT programs, it's buggy

OK, starting from this week-end, I'm going to be a bit less busy in real life

Lionel Debroux (./1) :
integration of the FlashOS support archive 'flashosa', which contains only the header of a Flash OS (wonder why this was not already in TIGCC ? You're not alone.)

Flash OS support is hidden by default in TIGCC because it is experimental and incomplete:
[ul][li]no ??u support, only outputbin (would be easy to fix if it weren't for the Delphi TIGCC IDE resp. link.dll reinventing file output - I have permission from ExtendeD to reuse and relicense the code from the converter he ships with FreeFlash - this is in ld-tigcc so it would be plain GPLv2+, no exceptions),[/li][li]no standardized startup code (hardware initialization),[/li][li]no common functions useful for all Flash OSes, such as FlashROM writing code.[/li][/ul]
Such functions would have to be rewritten from scratch for TIGCC because PpHd is not interested in relicensing the relevant code from PedroM with the TIGCCLIB exception.

Lionel Debroux (./2) :
Finding a red-black tree library is easy: there's a GPLed one in the Linux kernel.

v2+ or v2 only?
GPLv2 only code will never be accepted in upstream ld-tigcc.

As a number of other posts, ./1 was written way before we discussed the matter of Flash OS support with you.
Before this discussion, I don't remember myself reading you detailing that you had a problem with the absence of standardized startup code (if such a thing can exist) and about common functions such as Flash writing code. I might have forgotten.

Sometime, we'll bring up again the discussion about Flash OS support, in another topic.

rbtree.c / .h is GPLv2+.

[EDITed to add a note.]