[mOved] Ticket #9 "Upgrade kernel support": discussion... - Page 1

I've had a shallow look at what should be done when addressing ticket #9 of GCC4TI, "Upgrade kernel support".

The recommended kernel header, provided by PreOS, is kernel.h. I can see that:
* kernel.h is intended to be used without using any of the headers that tigcclib.h includes: kernel.h duplicates more than one thousand lines of vat.h, alloc.h, etc.. No modifications for the vast majority of the definitions, starting with the ROM_CALLs: _rom_call(...) is used in both tigcclib.h-#include'd headers and kernel.h, the change is within the definition of _rom_call(...).
* kernel.h duplicates the definitions of the tigcc.a functions.
* kernel.h has different ordering for the definitions.


I'm therefore asking myself several questions:
* why this choice of not using the tigcclib.h-#include'd headers at all ? Out of necessity maybe ?
(Maybe Kevin had threatened, like he did for the ExtGraph grayscale routine, to change something in TIGCC to make it harder to use software that he doesn't like. He never turned his threats into actions, maybe he knows that this kind of stupidities was one of the ways to trigger a fork of TIGCC.

* is kernel.h auto-generated, at least a part of it ?

* if kernel.h isn't auto-generated, would it be possible to auto-generate a significant part of it ? I'm mostly thinking of not duplicating 1:1 the definitions of vat.h, alloc.h, etc.


My goal is not to point that Patrick, when making kernel.h the way it is, was wrong. I'm just trying to understand: I'm no kernel-based programming expert ( ), and I probably am not aware of everything that led to kernel.h vs. doors.h (although I know that one of the reasons why kernel.h exists, is that Kevin refuses to upgrade the kernel support in TIGCC, arguing it would cause "lock-in". Yeah, definitely.).

Lionel Debroux (./1) :
* why this choice of not using the tigcclib.h-#include'd headers at all ? Out of necessity maybe ?

Because an update of tigcc broke an older kernel.h
So I write it so that it can't be broken anymore by any update of tigcc.

Lionel Debroux (./1) :
* is kernel.h auto-generated, at least a part of it ?

No, but it should.

Lionel Debroux (./1) :
* if kernel.h isn't auto-generated, would it be possible to auto-generate a significant part of it ? I'm mostly thinking of not duplicating 1:1 the definitions of vat.h, alloc.h, etc.

Of course!

why this choice of not using the tigcclib.h-#include'd headers at all ? Out of necessity maybe ?

Because an update of tigcc broke an older kernel.h So I write it so that it can't be broken anymore by any update of tigcc.

That explains...
Do you by chance remember what change broke an older kernel.h ? Or, do you have some factual information (release, SCM) about when this happened approximately, which would help finding out what broke kernel.h ?

Most changes of kernel.h wrt TIGCC include files seem to be located in compat.h and kbd.h.
For the vast majority of headers #include'd by tigcclib.h, surrounding the "#include <default.h>" by #ifndef __KERNEL_H__ / #endif in the non-auto-generated part of most TIGCC header most files should cut most of the copy&paste while not interfering with the kernel.h definitions - and in the process, reducing the risks of missing several definitions and not keeping up with updates.


BTW, bug report: I noticed kernel.h of PreOS 1.0.5 lacks __Folder_Del:
#define __Folder_Del _rom_call(short,(const char*,short),66)

Lionel Debroux (./3) :
That explains... Do you by chance remember what change broke an older kernel.h ? Or, do you have some factual information (release, SCM) about when this happened approximately, which would help finding out what broke kernel.h ?

I don't remember.
Probably 0.94 -> 0.95

Lionel Debroux (./3) :
Most changes of kernel.h wrt TIGCC include files seem to be located in compat.h and kbd.h. For the vast majority of headers #include'd by tigcclib.h, surrounding the "#include " by #ifndef __KERNEL_H__ / #endif in the non-auto-generated part of most TIGCC header most files should cut most of the copy&paste while not interfering with the kernel.h definitions - and in the process, reducing the risks of missing several definitions and not keeping up with updates.

Yes.
All the changes are in compat.h
All other files are copy and paste of the header files
I don't think I have modified kbd.h. What changes were done?

Lionel Debroux (./3) :
BTW, bug report: I noticed kernel.h of PreOS 1.0.5 lacks __Folder_Del: #define __Folder_Del _rom_call(short,(const char*,short),66)

Probably 0.94 -> 0.95

This was way before the import of TIGCC to the TIGCC CVS repository in December 2004...

I don't think I have modified kbd.h. What changes were done?

Um, oops. The model-dependent KEY_LEFT, etc. definitions are not in kbd.h, they're in compat.h. Silly me.

There's a change in flash.h, though:
[code]#define FL_getHardwareParmBlock() (MIN_AMS<101&&TIOS_entries<0x3CC?(const void*)"\0\x6\0\0\0\x1":_rom_call(const void*,(void),16B)())[/code]
[code]#define FL_getHardwareParmBlock() (((_ram_call(14,unsigned short)==0x1100)?(const void*)"\0\x6\0\0\0\x1":_rom_call(const void*,(void),16B)())[/code]

It is to detect TI-92+ AMS 1.00 (and not TI-89 AMS 1.00) : the kernel does alreay the job of detecting it throught a RAM CALL.
Not very important, though

Worked a bit on this. Posted a status update and a TODO list at http://trac.godzil.net/gcc4ti/ticket/9 .

All the changes are in compat.h

Actually, no
There are several other ones, I could see two in graph.h (LCD_MEM, LCD_SIZE) and one in stdlib.h (exit, possibly atexit).

Yes, I forgot.
You're right.

These differences make harder including kernel.h from tigcclib.h. This may be a desirable long-term goal for the inclusion of kernel.h in GCC4TI (?), but that would break backwards compatibility with programs that #include kernel.h.

The quick&dirty first step of the integration of kernel.h in GCC4TI will certainly work the other way round: #include'ing other headers before #undef'ing and re-#define'ing the conflicted definitions that can't easily be merged. For smoother integration of the headers together, several definitions may have to be moved from the auto-generated to the non-auto-generated portion of headers.

Je sais pas si ça peut être utile, mais j'utilise un header kernel pour GNU as, qui comporte à la fois les définitions style ROM_CALL_XXX et les équivalences en valeur hexa : .equ DrawLine, 0x par exemple. Ca intègre les romcalls AMS 2.xx.
J'ai aussi porté quelques macros d'origine mais pas toutes (genre PUSH/POP, jamais utilisées par moi), plus deux macros à 3 macros à moi pour les données/textes/fonctions qui servent à créer plusieurs sections dans un même source avec un seul mot, pour que le compilateur fasse au mieux son boulot. Beaucoup d'autres macros sont très simple à porter si il faut le faire. Si ça peut aider...
Fichier joint : kernel.h

[note] Je n'ai jamais fait de dev coopératif, et ce n'est pas mon métier contrairement à la majorité d'entre vous, je veux bien aider pour ce genre de choses (68k pur), j'ai juste besoin qu'on me dise quoi faier pour que ce soit ordonné. Dans le cas du header que je propose par exemple, si ça peut aider ou être utile, demandez-m'en un complet. Si c'est inutile, dites-le moi également. Voilà.

Folco is proposing a header suitable for GNU as, which has both ROM_CALL_xxx definitions and equates (e.g. .equ DrawLine, 0x...). This header contains AMS 2.xx ROM_CALLs.
The header also contains several macros, ported to GNU as syntax, and other macros that he added because he found them useful multiple times. Many other macros are easy to port [between GNU as and A68k syntaxes].

I especially like the FunctionSection, DataSection and StringSection macros

I do think this header is useful. Is it partially auto-generated ?

No, I did it by hand because I don't know script languages. Don't forget I'm not a real developper, like most part of you ...

(And thanx to have translated into english...)

it will be good if we avoid calling everyrthing kernel.h
except than that, I am not agains it.
On the contrary

Ok, of course the name has to be changed, I called it like that because I never used neither PreOS neither TIGCCLIB headers, so I couldn't have conflicts with them.

I can work on it to provide all macros of the standard tios.h. I have even an PedroM header (internal pseudo-lib) and Genlib header, I work on them and post them here.

Lionel Debroux (./1) :
* kernel.h is intended to be used without using any of the headers that tigcclib.h includes: kernel.h duplicates more than one thousand lines of vat.h, alloc.h, etc..

And this is one of the reasons I don't support it. (There are others.)

PpHd (./2) :
Because an update of tigcc broke an older kernel.h

Just to make it clear, the big changes to TIGCC's internals in 0.95 had as a side effect that some of the dirty, undocumented tricks in kernel.h no longer worked. This was in no way done to intentionally break kernel.h, but to improve TIGCC. (There's no such allegation in any of your posts, but I just want to avoid people coming up with them. )

So I write it so that it can't be broken anymore by any update of tigcc.

Quite the opposite, there's plenty of stuff which can break with a TIGCC update. For example, you're hardcoding the calling conventions for TIGCCLIB functions. They can change at any moment. (TIGCC never promised binary compatibility across releases, only source compatibility.)

And this is one of the reasons I don't support it.

This particular reason has become much weaker, because I removed most of the duplication

We know that you don't like "kernel"-based programming, and that you wouldn't want to use it for your own programs.
I (apriori) wouldn't want to use it for my own programs either, but I think that other programmers shouldn't have to install PreOS support to access its capabilities. With TIGCC (and currently, GCC4TI, but the GCC4TI repository contains some work towards lifting that limitation), programmers have to make an effort so as to lift the capping of TIGCC to DoorsOS/UniOS-style (i.e. 2002, at best !) "kernel"-based programming...

_flag_2:	xdef	_flag_2		; _nosavescreen
_flag_3:	xdef	_flag_3		; _readonly

_nosavescreen and _readonly are defined in tios.h, but GCC4TI doesn't know these symbols, I have to use the _flag_? symbols instead. Could it be added ?

I don't see the point of adding 2 more of the legacy linker symbols when we have the general _flag_n syntax which handles them all in a consistent way.