Headers - Page 1

Do you think that it could be usefull to post all the headers of ...\TIGCC\Include\ASM to the GNU as syntax ? It's a job I could do, since I can't help you on development in other languages...

Yes, I think it's useful to port to GNU as syntax the contents of some of the headers of include/ASM (I guess some of them, e.g. filelib and linelib, are outdated/deprecated).
Maybe as a single "kernel.h" file, like the C header of the same name ? Not maintaining 1:1 correspondence between A68k syntax headers and GNU as syntax headers would probably not create backwards compatibility problems: there aren't many kernel-based programs written in GNU as syntax.

I agree ; in fact I don't think someone could want to use filelib or linelib now... I don't know how to do to help you in your project

don't know how to do to help you in your project

Well, you've proposed doing something that is interesting (expanding kernel programming support to GNU as), but that was not in our todo list: I think that can be called helping us, can't it ?

I'm not an expert of "kernel" programming ( that's an understatement ), so I'll let PpHd, you and others should decide the exact extent of what should be in the "kernel.h" GNU as header (which functions and libraries are deprecated, which are not, etc.).
Definitions that are identical in "kernel.h" (both the C version and the GNU as version) and in other headers (TIGCCLIB C headers, GNU as os.h) mustn't be duplicated, duplication is only a source of problems.
I did de-duplication on the C kernel.h header, slashing its size by nearly 90%. I committed this morning my changes into the "kernelh-inclusion" branch of the repository ( you can find the individual files in http://trac.godzil.net/gcc4ti/ticket/9 ).

Folco (./3) :
I agree ; in fact I don't think someone could want to use filelib or linelib now... I don't know how to do to help you in your project

Send me your header so that I can review it.

I haven't ported them yet. I will do it soon, I just thinked it was useless. But I will send them.

BTW, do you think that include the genlib header in the include directory would be a good thing ? I'have also my own version of this header for GNU as.

Is genlib part of stdlib ?
* If it is, I think the GNU as header for Genlib should be put in both upstream Genlib and the include directory of a default GCC4TI installation;
* If it isn't, I think the GNU as header for Genlib should be put only in upstream Genlib for now. Addition to the include directory of a GCC4TI installation should come later, as part of ticket #30 (improved installers with bundled or downloadable external libraries and programs such as ExtGraph, Genlib, etc.).

What do you think ?

Lionel Debroux (./7) :
Is genlib part of stdlib ?

Ah yes, I think it's the good reason. Yes, genlib is part of stdlib. But I think also that we must have the agreement of PhHd, of course.

I was working on that, but I have seen some differences with PreOS /sdk/include/ headers :
- japlib.h is in the PreOS package
- there is huflib.h in PreOS pack, but hufflib.h in TIGCC
- some headers are different (hufflib and gray4lib) : in PreOS pack, the export are links to the ziplib and graphlib functions.

Question : what headers should I convert ? (PreOS ones I think, but I don't want to do useless job).

The PreOS ones, almost undoubtedly. PpHd, I guess the redirects were made possible by absolute compatibility, weren't they ?
If any known application is depending on the 'huflib.h' name, we can add it as a file which contains a single
.include "hufflib.h"
line.

Conversion of jplib.h is trivial, but I'm not sure it's very useful to convert it

Lionel Debroux (./10) :
Conversion of jplib.h is trivial, but I'm not sure it's very useful to convert it

But it's easy to do ^^

I've translated all headers, except tios.h, romcalls.h (I had given another file for that) and genlib.h (I have not translated macros yet). Fichier joint : headers.zip

I have some notes :

certaines libs n'ont pas de version définie

certaines libs ne vérifient pas l'existence du symbole de version

certaines libs vérifient l'existence d'un equate plutôt que du numéro de version, ça fait moins propre

util.h redéfinit ça : .set ams__FindSymEntry util__FindSymEntry
Pourquoi ?
certains éléments de userlib devraient être redéfinis pour appeler le kernel (idle_loop, exec entre autres).

Folco (./9) :
- there is huflib.h in PreOS pack, but hufflib.h in TIGCC

?? Gloups ??

Lionel Debroux (./10) :
The PreOS ones, almost undoubtedly. PpHd, I guess the redirects were made possible by absolute compatibility, weren't they ?

............... You overestimate me.

Folco (./12) :
certaines libs n'ont pas de version définie

??? Maybe because there was only one version of the library. jplib for example ?

Folco (./12) :
certaines libs ne vérifient pas l'existence du symbole de version

It is bad

Folco (./12) :
certaines libs vérifient l'existence d'un equate plutôt que du numéro de version, ça fait moins propre

Example ?

Folco (./12) :
util.h redéfinit ça : .set ams__FindSymEntry util__FindSymEntry Pourquoi ?

Could you give me a little more of context ?

Folco (./12) :
certains éléments de userlib devraient être redéfinis pour appeler le kernel (idle_loop, exec entre autres).

userlib::exec should support 'zip exec' file, which isn't supported by kernel::exec

PpHd (./13) :
It is bad

I'll modify them

PpHd (./13) :
Example ?

graphlib entre autres

PpHd (./13) :
Could you give me a little more of context ?

.set	flib__clear_dialog,		util__clear_dialog
.set	flib__clr_scr,			util__clr_scr
.set	flib__zap_screen,		util__zap_screen
.set	flib__idle_loop,		util__idle_loop
.set	flib__random,			util__random
.set	flib__rand_seed,		util__rand_seed
.set	tios__DrawCharXY,		util__DrawCharXY

.set	tios__FindSymEntry,		util__FindSymEntry

at the end of the header. It find this strange, no ?
tios::FindSymEntry -> util::FindSymEntry -> userlib::FindSymEntry

PpHd (./13) :
userlib::exec should support 'zip exec' file, which isn't supported by kernel::exec

Ok.

Folco (./14) :
graphlib entre autres

I don't see the problem. Could you explain a little bit more?

Folco (./14) :
tios::FindSymEntry -> util::FindSymEntry -> userlib::FindSymEntry

Well flib is a Ti-92 Header from fargo.
It defines the exported romcall tios::FindSymEntry. Once plusShell came out, in order to maintain Fargo compatibility, it provides an equate to this romcall (inside a library).
Once doorsos came out, it provides another library call to support this romcall.

PpHd (./15) :
I don't see the problem. Could you explain a little bit more?

There is no problem in fact, it will work very well, but I didn't understand why all headers don't check their inclusion in the same way, that's all.

BTW, I've another header for PedroM. Will have it to be included ? Fichier joint : pedrom-asm.h

./17: the answer is probably "yes, it will have to be put in GCC4TI", but I don't know when
We thought about providing tighter integration of PedroM within GCC4TI, e.g. through ticket #5, but AFAIK, we haven't done anything yet.

Regardless of the integration in GCC4TI, this header belongs to the PedroM SDK, at least.