Yuku free message boards

__ld_first_user_sector and __ld_first_non_os_sector are better than __ld_first_sector_after_os or my other suggestions posted in #0 indeed
first_non_os_sector is probably a bit more "neutral" about the usage of the subsequent addesses than first_user_sector (the first sector after the OS may contain user-space binaries that are not user-deletable, such as /etc/init and /bin/getty in Punix, as described in http://tichessteamhq.yuku.com/topic/4645?page=2 ), but first_user_sector is decent.

Which means "user" would implicitly have the meaning of "user-space", rather than the meaning of "usable by the user at will", like (mostly) on AMS. Why not, but I feel we need more input on that.

Here's another set of patches suitable for TIGCC, which I'm posting here because I know that some potential reviewers don't attend yAronet.
Over the past two week-ends, I double-checked, improved and extended a subset of my contributions to the TIGCC documentation, on the event of making something else with several internal data structures of AMS.
Since the previous submission of most of those things (2002 or 2003), I learnt quite a few things about SW development, one of which is making small, incremental patches, which eases both review and integration.

Details of the patches:
* documentation for 12 ROM_CALLs, moved from unknown.h to bascmd.h, basfunc.h or basop.h;
* partial documentation for the 2 tag-related structs and 3 arrays thereof. Complete documentation for those is a HUGE amount of work - count "PTO_" macros and macros using them in tiams.h from TIFS to get a glimpse of what I mean - and I don't plan on creating these >100 files. Not only we can all make better use of our scarce time by focusing on things more important than complete documentation of those complicated AMS internal data structures, but also, if someone wants to know more about these structures, many of the tag-related macros' names in tiams.h are pretty self-explanatory...
* addition of 17 AMS 3.xx *Tags, of which 2 ("exprIO" and "stDevPop") are not exported in CAT_dialog, AFAICS.

Links to the patches:
http://trac.godzil.net/gc...CALLs-that-imple.patch.gz
http://trac.godzil.net/gc...CALLs-that-imple.patch.gz (with a typo in the commit message I've noticed only after uploading the four patches...)
http://trac.godzil.net/gc...CALLs-that-imple.patch.gz
http://trac.godzil.net/gc...ve-definitions-f.patch.gz
The vast majority of the patches' size is made up by the impact of moving files around on the long "In=", "Out=" and "See Also" lines. Due to the behaviour of the current documentation toolchain, this non-functional change yields severe pollution of the diffs...

> because it is a step backwards
Don't be so one-sided when evaluating a technical solution

The fact is, it's a simple (the Perl script that does the job is a hundred SLOC, more than an order of magnitude less than rewriting the tools) and working solution to a problem that has been known for years. A way to get the job done instead of waiting for an event that we knew you had planned, but would happen only God knew when. Keep in mind that the "add explicit headers everywhere" change was done before Conrad started working on rewriting the tools.

When doing this change, we were hardly interested in rewriting the tools until a significant use case that the current tools just cannot fulfill (not even with simple modifications - remember, we got copies of Delphi, and we checked that the tools can be recompiled and produce the same output as the current time-frozen binaries) was found. AFAIK, there's still none, to date...
Sure, these tools have annoyances (so has the outdated CVS...), but in my opinion (I'm speaking on my own there, as in the GCC4TI project, I'm the person who knows best the TIGCC documentation system), a complete rewrite is probably still excessive, given that:
* the legacy tools work perfectly under Wine;
* from my experience with the tools, the "stop at first error" behaviour is hardly a problem when making small, incremental patches;
* the dependence on CRLF line endings isn't a problem either: either you use a real SCM that handles line endings correctly, or instead of calling Update* directly, you make once, and call multiple times later, very small sh scripts that call unix2dos, Update* and dos2unix;
* very long lines suck, but that's what Wrap in text editors is for.

Now, Conrad has started rewriting the tools, so the game has changed a bit. We've therefore offered our help (I posted "Although Kevin can help with the directions and design, and we don't have any test suite other than that of TIGCC, if you need help, tell us " on 20090128). AFAIK, he hasn't asked, so far.

One last note: the Perl script that adds explicit headers everywhere is publicly available at http://trac.godzil.net/gcc4ti/ticket/3 . As I already wrote you, it's easy to modify it so that instead of make headers explicit everywhere, it removes all explicit references to headers. In other words, it can (and will certainly, on the GCC4TI side) be used as a building block for removing explicit references to headers, when the new tools can handle the full absence of explicit references to headers.

> things like [...] are not supported by the standard GNU patch.
@%%!. This time, I forgot to pass --no-renames to `git format-patch`. I usually do, when sending patches to others at work, exactly because of the need to interoperate with less-capable tools...
I've updated the patches.
Of course, that won't solve the bigger problem, that you insist on refusing the patches
(you can temporarily replace the several dozens of affected TIGCC callgraphs by the GCC4TI ones, since they're equivalent. I checked the output UpdateInclude produces, and even if you don't trust me, you can check by yourself, since I made the transformation code public.)