Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Sujets divers - Miscellaneous » Autre, divers... » Saletés dans kernel.h (46 réponse(s))
./POST DE DEPART (post n°0)   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 7 juin 2004 à 00:24 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Ximoon :
tu arrêtes d'utiliser des arguments pourris et facilements retournables contre toi pour lancer des TROLLS ? Tu te calmes ou tu dégages Kevin.

Des "TROLLS"? Regarde ce que fait kernel.h avec _main avant de m'accuser de troller!

#undef  NO_AMS_CHECK        // Useless in Kernel mode (Kernel does the job for you).
#undef  NO_CALC_DETECT        // Useless in Kernel mode (Kernel does the job for you).
#undef  EXECUTE_IN_GHOST_SPACE      // Useless in Kernel mode 
#undef  USE_KERNEL        
#undef  USE_INTERNAL_FLINE_EMULATOR    // Useless with Preos
#undef  RETURN_VALUE        // Change the way of working

#define  NO_AMS_CHECK
#define  NO_CALC_DETECT
#define  USE_KERNEL

Surchargement des options choisies par l'utilisateur. C'est arrogant, et en plus incorrect (Il y a des kernels qui ne vérifient pas l'AMS et le modèle, sinon on ne mettrait pas le code de vérification nous-mêmes! On réfléchit avant de rajouter du code de démarrage!).

// You can't no select Exit support

Vive la (non-)flexibilité et le gaspillage de 6 octets! Et en plus sa méthode est incompatible avec TIGCC 0.95!

#undef  _main
#define _main volatile __main__(); 
  asm(  ".xdef  _mainn" 
    "  .xdef  __save__sp__n" 
    "__save__sp__:n" 
    "  .long 0n" 
    "_main:  lea __save__sp__(%pc),%a0n" 
    "  move.l %a7,(%a0)n" 
    "  jbra  ___mainn"); 
   void ___main

#endif

C'est du totalement foireux. S'il y a un système de code de démarrage et de point d'entrée, c'est pour qu'il soit utilisé!

Martial Demolins :
le quarante-douzième épisode du feuilleton n'a pas plus fait avancer les choses que d'habitude... :|

PpHd pourrait facilement faire avancer les choses en supprimant ces hacks comme je n'arrête pas de lui demander. (Et je lui ai aussi expliqué tout ce que j'ai marqué ci-dessus.) Il n'écoute pas, mais n'en fait qu'à sa tête.

Et au passage, la manière dont il redéfinit RETURN_VALUE est aussi foireuse et stupide. (Il n'y a vraiment pas de raison d'être gratuitement incompatible avec tigcclib.h!)
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°1   Marquer comme non lu.
Folco Ecrit le: Lundi 7 juin 2004 à 00:29 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


et pkoi sa méthode pour RETURN_VALUE est stupide?!?
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°2   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 7 juin 2004 à 00:34 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Parce qu'elle est gratuitement incompatible avec tigcclib.h et qu'il n'y avait vraiment pas de raison de changer la manière dont ça fonctionne.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°3   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 7 juin 2004 à 01:30 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Si vous voulez utiliser les librairies dynamiques, voici les porcheries à virer de kernel.h:
--- kernel.h_  Tue Dec 31 23:50:32 1996
+++ kernel.h  Mon Jun  7 01:39:34 2004
@@ -13,4 +12,0 @@
- * To return a value, just add:
- *  RETURN_VALUE;
- *   just after you have pushed the returned value in the estack.
- *  (Contrary to tigcclib, you can not return a value if you want).
@@ -24 +19,0 @@
-#define DOORS
@@ -27,0 +23 @@
+#ifndef USE_TI92P
@@ -35,0 +32 @@
+#endif
@@ -37,2 +33,0 @@
-#undef  NO_AMS_CHECK        // Useless in Kernel mode (Kernel does the job for you).
-#undef  NO_CALC_DETECT        // Useless in Kernel mode (Kernel does the job for you).
@@ -41,2 +35,0 @@
-#undef  USE_INTERNAL_FLINE_EMULATOR    // Useless with Preos
-#undef  RETURN_VALUE        // Change the way of working
@@ -44,2 +36,0 @@
-#define  NO_AMS_CHECK
-#define  NO_CALC_DETECT
@@ -48,17 +38,0 @@
-#include <default.h>
-#include <romsymb.h>
-
-// You can't no select Exit support 
-#undef  _main
-#define _main volatile __main__(); 
-  asm(  ".xdef  _mainn" 
-    "  .xdef  __save__sp__n" 
-    "__save__sp__:n" 
-    "  .long 0n" 
-    "_main:  lea __save__sp__(%pc),%a0n" 
-    "  move.l %a7,(%a0)n" 
-    "  jbra  ___mainn"); 
-   void ___main
-
-#endif
-
@@ -67,2 +41 @@
-#ifndef  KERNEL
-#define KERNEL
+#endif
@@ -70,122 +43,2 @@
-// Even if I include tigcclib above, I prefer redefining HANDLE
-#undef HANDLE
-#define HANDLE unsigned short
-
-// Kernel RAM_CALLS
-extern void
-  _RAM_CALL_0,_RAM_CALL_1,_RAM_CALL_2,_RAM_CALL_3,
-  _RAM_CALL_4,_RAM_CALL_5,_RAM_CALL_6,_RAM_CALL_7,
-  _RAM_CALL_8,_RAM_CALL_9,_RAM_CALL_A,_RAM_CALL_B,
-  _RAM_CALL_C,_RAM_CALL_D,_RAM_CALL_E,_RAM_CALL_F,
-  _RAM_CALL_10,_RAM_CALL_11,_RAM_CALL_12,_RAM_CALL_13,
-  _RAM_CALL_14,/*_RAM_CALL_15,
-  _RAM_CALL_16,_RAM_CALL_17,_RAM_CALL_18,_RAM_CALL_19,
-  _RAM_CALL_1A,_RAM_CALL_1B,_RAM_CALL_1C,_RAM_CALL_1D,
-  _RAM_CALL_1E,_RAM_CALL_1F,_RAM_CALL_20,*/_RAM_CALL_21,
-  _RAM_CALL_22,_RAM_CALL_23,_RAM_CALL_24,_RAM_CALL_25,
-  _RAM_CALL_26,_RAM_CALL_27,_RAM_CALL_28/*,_RAM_CALL_29*/;
-
-// Symbols preceed with '_' are used for the implementation
-// Do not use them.
-#define ___RAM_CALL(n,type) ((type)&_RAM_CALL_##n)
-
-#define __CALCULATOR ___RAM_CALL(0, const unsigned char*)
-#undef  CALCULATOR
-#undef  HW_VERSION
-#define CALCULATOR  (__CALCULATOR[0])
-#define HW_VERSION  (__CALCULATOR[1])
-//#define HW_DISPLAY_VERSION (__CALCULATOR[2])
-#define EMULATOR  (__CALCULATOR[3])
-
-#undef  font_medium
-#undef  font_small
-#undef  font_large
-#define font_medium  ___RAM_CALL(E, const void*)
-#define font_small  ___RAM_CALL(22, const void*)
-#define font_large  ___RAM_CALL(23, const void *)
-
-#undef  LCD_MEM
-#undef  LCD_WIDTH
-#undef  LCD_HEIGHT
-#undef  LCD_LINE_BYTES
-#define  LCD_MEM    ___RAM_CALL(21, void*)
-#define LCD_WIDTH  ___RAM_CALL (1, unsigned long)
-#define LCD_HEIGHT  ___RAM_CALL (2, unsigned long)
-#define LCD_LINE_BYTES  ___RAM_CALL (4, unsigned long)
-#define _LCD_SIZE  ___RAM_CALL (C, unsigned long)
-
-#undef  ROM_BASE
-#define  ROM_BASE  ___RAM_CALL(3, unsigned char *)
-
-#define  RETURN_VALUE  ((unsigned char *) *_RAM_CALL_F = (unsigned char *) *_ROM_CALL_109)
-
-#undef  Heap
-#undef  FOLDER_LIST_HANDLE
-#undef  MainHeandle
-#undef  ROM_VERSION
-#define Heap    ___RAM_CALL(11, void***)
-#define FOLDER_LIST_HANDLE ___RAM_CALL (12, unsigned long)
-#define MainHandle  ___RAM_CALL (13, unsigned long)
-#define ROM_VERSION  ___RAM_CALL (14, unsigned long)
-
-#undef  kb_globals
-#undef  KEY_PRESSED_FLAG
-#undef  GETKEY_CODE
-#define kb_globals  ___RAM_CALL(10, void*)
-#define KEY_PRESSED_FLAG (*(unsigned short*)(kb_globals+0x1C))
-#define GETKEY_CODE  (*(unsigned short*)(kb_globals+0x1E))
-
-#undef  KEY_LEFT
-#undef  KEY_RIGHT
-#undef  KEY_UP
-#undef  KEY_DOWN
-#undef  KEY_UPRIGHT
-#undef  KEY_DOWNLEFT
-#undef  KEY_DIAMOND
-#undef  KEY_SHIFT
-#define KEY_LEFT  ___RAM_CALL(5, unsigned long)
-#define KEY_RIGHT  ___RAM_CALL(6, unsigned long)
-#define KEY_UP    ___RAM_CALL(7, unsigned long)
-#define KEY_DOWN  ___RAM_CALL(8, unsigned long)
-#define KEY_UPRIGHT  ___RAM_CALL(9, unsigned long)
-#define KEY_DOWNLEFT  ___RAM_CALL(A, unsigned long)
-#define KEY_DIAMOND  ___RAM_CALL(B, unsigned long)
-#define KEY_SHIFT  ___RAM_CALL(D, unsigned long)
-
-#define  Idle  _RAM_CALL_15
-#define kernel_Idle Idle
-void  Idle(void);
-#define  kernel_Exec  _RAM_CALL_16
-short kernel_Exec(HANDLE hd asm("d0"));
-#define  kernel_Ptr2Hd  _RAM_CALL_17
-HANDLE kernel_Ptr2Hd(void *ptr asm("a0"));
-#define  kernel_Hd2Sym  _RAM_CALL_18
-SYM_ENTRY *kernel_Hd2Sym(HANDLE hd asm("d0"));
-typedef  struct _LibRef LibRef;
-#define  kernel_LibsBegin _RAM_CALL_19
-LibRef *kernel_LibsBegin(char *libname asm("a0"), unsigned char version asm("d1"));
-#define kernel_LibsEnd  _RAM_CALL_1A
-void kernel_LibsEnd(LibRef *lib asm("a0"));
-#define  kernel_LibsPtr  _RAM_CALL_1C
-void *kernel_LibsPtr(LibRef *lib asm("a0"), short function asm("d0"));
-#define  kernel_LibsCall  _RAM_CALL_1B
-__attribute__((__stkparm__)) unsigned long kernel_LibsCall(LibRef *lib, short function, ...);
-#define  kernel_LibsExec  _RAM_CALL_1D
-__attribute__((__stkparm__)) void kernel_LibsExec(char *name, short function, char version, ...);
-#define  kernel_HdKeep  _RAM_CALL_1E
-void  kernel_HdKeep(HANDLE hd asm("d0"));
-#define  kernel_ExtractFromPack  _RAM_CALL_1F
-HANDLE  kernel_ExtractFromPack(void *pack asm("a5"), short index asm("d0"));
-#define  kernel_ExtractFile  _RAM_CALL_20
-HANDLE  kernel_ExtractFile(const char *name asm("a2"));
-#define  kernel_ExtractFileFromPack  _RAM_CALL_29
-HANDLE  kernel_ExtractFileFromPack(HANDLE hd asm("d0"), const char *name asm("a2"));
-
-/* Sym_entry compatible with all calcs (even ti-92)
- *
- * SYM_ENTRY.name
- * SYM_ENTRY.compat
- * SYM_ENTRY.flags
- * SYM_ENTRY.hVal
- * SYM_ENTRY.sizeof
- */
+#ifndef  KERNEL_H_
+#define KERNEL_H_
@@ -194 +46,0 @@
-asm("graphlib__version02: .xdef graphlib__version02");
@@ -283 +134,0 @@
-asm("userlib__version01: .xdef userlib__version01");
@@ -301 +151,0 @@
-asm("hexlib__version01: .xdef hexlib__version01");
@@ -311 +160,0 @@
-asm("shrnklib__version01: .xdef shrnklib__version01");
@@ -322 +170,0 @@
-asm("ziplib__version01: .xdef ziplib__version01");

et voici la version nettoyée résultante:
/*
 * Warning the header file is NOT SUPPORTED BY TIGCC TEAM
 * [PpHd] think[s] it is the best file to use if you want to use 
 * Kernel format.
 *
 * How to use ?
 *  Instead of :
 *  #define USE_KERNEL
 *  #include <tigcclib.h>
 * Just do :
 *  #include <kernel.h>
 * (You can forget to define the targets).
 */

#ifdef NOSTUB
#error "kernel.h" must not be included in "nostub" mode!
#endif

#ifndef DOORS

// if no target are defined, compiled for all calcs
#ifndef USE_TI92PLUS
#ifndef USE_TI92P
#ifndef USE_TI89
#ifndef USE_V200
#define USE_TI92PLUS
#define  USE_TI89
#define USE_V200
#endif
#endif
#endif
#endif

#undef  EXECUTE_IN_GHOST_SPACE      // Useless in Kernel mode 
#undef  USE_KERNEL        

#define  USE_KERNEL

#include <tigcclib.h>

#endif

#ifndef  KERNEL_H_
#define KERNEL_H_

// graphlib

#define graphlib_fill graphlib__0000
void  graphlib_fill(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d2"), unsigned short height asm("d3"), unsigned short color asm("d4"));

#define graphlib_put_sprite graphlib__0001
void  graphlib_put_sprite(unsigned short x asm("d0"), unsigned short y asm("d1"), void *sprite asm("a0"));

#define graphlib_put_sprite2 graphlib__000C
void  graphlib_put_sprite2(unsigned short x asm("d0"), unsigned short y asm("d1"), void *sprite asm("a0"), unsigned char *mask asm("a2"));

#define graphlib_put_sprite_mask graphlib__000B
void  graphlib_put_sprite_mask(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned char mask asm("d3"), void *sprite asm("a0"));

#define graphlib_smallbox graphlib__0002
void  graphlib_smallbox(char *title asm("a0"));

#define graphlib_box graphlib__0003
void  graphlib_box(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d2"), unsigned short height asm("d3"), char *title asm("a0"));

#define graphlib_frame graphlib__0004
void  graphlib_frame(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d4"), unsigned short height asm("d5"));

#define graphlib_clrscr graphlib__0005
void  graphlib__clrscr();

#define graphlib_clrscr2 graphlib__0014
void  graphlib__clrscr2();

#define graphlib_vert graphlib__0006
void  graphlib_vert(unsigned short x asm("d0"), unsigned short y1 asm("d1"), unsigned short y2 asm("d2"));

#define graphlib_horiz graphlib__0007
void  graphlib_horiz(unsigned short x1 asm("d0"), unsigned short y asm("d1"), unsigned short x2 asm("d2"), unsigned short color asm("d3"));

#define graphlib_bigbox graphlib__0008
void  graphlib_bigbox(char *title asm("a0"));

#define _graphlib_scrtomem graphlib__0009
void  _graphlib_scrtomem(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d2"), unsigned short height asm("d3"));
#define graphlib_scrtomem(_x, _y, _height, _width) ({register unsigned short __d4 asm("d4"); _graphlib_scrtomem(_x, _y, _height, _width); __d4;})

#define graphlib_memtoscr graphlib__000A
void  graphlib_memtoscr(unsigned short x asm("d0"), unsigned short y asm("d1"), unsigned short width asm("d2"), unsigned short height asm("d3"), HANDLE hd asm("d4"));

#define graphlib_line graphlib__0017
void  graphlib_line(unsigned short x1 asm("d0"), unsigned short y1 asm("d1"), unsigned short x2 asm("d2"), unsigned short y2 asm("d3"), void *screen asm("a0"));

#define graphlib_choosescreen graphlib__000D
extern unsigned short graphlib_choosescreen;

typedef struct {
  unsigned short x1;
  unsigned short y1;
  unsigned short x2;
  unsigned short y2;
  unsigned short x;
  unsigned short y;
  char  *str;
  } dialog_struct;
#define graphlib_show_dialog graphlib__0015
void  graphlib_show_dialog(dialog_struct *d asm("a6"));

#define graphlib_clear_dialog graphlib__0016
void  graphlib_clear_dialog();

#define graphlib_erase_rect graphlib__0018
void  graphlib_erase_rect(void *r);

#define graphlib_frame_rect graphlib__0019
void  graphlib_frame_rect(void *r);

#define graphlib_gray2 graphlib__000E
void  graphlib_gray2();

#define graphlib_gray4 graphlib__000F
void  graphlib_gray4();

#define graphlib_gray7 graphlib__0010
void  graphlib_gray7();

#define graphlib_plane0 graphlib__0011
#define graphlib_plane1 graphlib__0012
#define graphlib_plane2 graphlib__0013
extern unsigned char *graphlib_plane0;
extern unsigned char *graphlib_plane1;
extern unsigned char *graphlib_plane2;

//userlib

#define  userlib_idle_loop userlib__0000
short  userlib_idle_loop();
#define userlib_random  userlib__0001
short  userlib_random(short limit asm("d0"));
#define userlib_randseed userlib__0002
extern  short  userlib__randseed;
#define userlib_exec userlib__0003
__attribute__((__stkparm__)) short  userlib_exec(HANDLE handle);
#define userlib_inputstr userlib__0006
char  *userlib_inputstr(short x asm("d1"), short y asm("d2"), short maxlen asm("d3"));
#define  userlib_smallmenu userlib__000C
short  userlib_samllmenu(short x asm("d0"), short y asm("d1"), char nbitem asm("d2"), char *str_list asm("a0"));
#define userlib_runprog userlib__0010
short  userlib_runprog(char *progname asm("a0"));

// Hexlib

#define  hexlib_put_char  hexlib__0000
void  hexlib_put_char(long x asm("d2"), long y asm("d1"), long character asm("d0"));
#define hexlib_put_bin  hexlib__0001
void  hexlib_put_bin(long x asm("d2"), long y asm("d1"), long number asm("d0"), long digits asm("d4"));
#define  hexlib_put_hex  hexlib__0002
void  hexlib_put_hex(long x asm("d2"), long y asm("d1"), long number asm("d0"), long digits asm("d4"));

// Shrnklib

#define  shrnklib_OpenArchive  shrnklib__0000
HANDLE  shrnklib_OpenArchive(void *archive asm("a0"));
#define  shrnklib_CloseArchive  shrnklib__0001
void  shrnklib_CloseArchive(HANDLE arch_hd asm("d0"));
#define  shrnklib_Extract  shrnklib__0002
void  *shrnklib_Extract(HANDLE arch_hd asm("d0"), short index asm("d1"), void *dest asm("a0"));
#define  shrnklib_Free(ptr) HeapFree(HeapPtrToHandle(ptr))

//Ziplib

#define  ziplib_check_cmem  ziplib__0000
short  ziplib_check_cmem(void *data asm("a0"), unsigned short len asm("d0"));
#define  ziplib_check_emem  ziplib__0001
short  ziplib_check_emem(void *archive asm("a0"));
#define  ziplib_eval_cmem  ziplib__0002
short  ziplib_eval_cmem(void *data asm("a0"), unsigned short len asm("d0"));
#define  ziplib_eval_emem  ziplib__0003
short  ziplib_eval_emem(void *archive asm("a0"));
#define  ziplib_compress  ziplib__0004
short  ziplib_compress(void *data asm("a0"), unsigned short len asm("d0"), void *dest asm("a1"));
#define  ziplib_extract  ziplib__0005
short  ziplib_extract(void *archive asm("a0"), void *dest asm("a1"));
#define  ziplib_zipfile  ziplib__0006
char  ziplib_zipfile(SYM_ENTRY *sym asm("a0"), char comment asm("d1"));
#define  ziplib_iscomp  ziplib__000B
short  ziplib_iscomp(SYM_ENTRY *sym asm("a0"));
#define  _ziplib_tempfile  ziplib__0007
long long _ziplib_tempfile(SYM_ENTRY *sym asm("a0"), char comment asm("d1"));
#define  ziplib_tempfile(sym, comment) ({long long result__ = _ziplib_tempfile(sym, comment); (char)(result__>>32)?-(short)(char)(result__>>32):(short)result__;})
#define ziplib_extract_string  ziplib__0008
void  ziplib_extract_string(void *archive asm("a0"), short arch_index asm("d3"), short str_index asm("d4"), void *dest asm("a1"));
#define ziplib_write_string  ziplib__0009
void  ziplib_write_string(void *archive asm("a0"), short x asm("d0"), short y asm("d1"), short arch_index asm("d3"), short str_index asm("d4"));
#define ziplib_write_string_inv  ziplib__000A
void  ziplib_write_string_inv(void *archive asm("a0"), short x asm("d0"), short y asm("d1"), short arch_index asm("d3"), short str_index asm("d4"));

#endif

-Edité le Lundi 7 juin 2004 à 01:35 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°4   Marquer comme non lu.
Folco Ecrit le: Lundi 7 juin 2004 à 08:59 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Avant que PpHd n'accepte ça...
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°5   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 7 juin 2004 à 09:25 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Pour les RAM_CALLs, il peut définir les RAM_CALLs PreOs-only s'il veut (je les ai virés dans ma version parce que je trouve que ce n'est pas une bonne idée pour des raisons de compatibilité), mais je ne veux pas qu'il redéfinisse les RAM_CALLs qui sont déjà définis dans compat.h. Quel intérêt de redéfinir KEY_LEFT, par exemple? On utilise déjà le RAM_CALL en mode kernel quand ça a un sens (quand on compile pour plus d'un modèle).
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°6   Marquer comme non lu.
Lionel Debroux Ecrit le: Lundi 7 juin 2004 à 11:35 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

Tiens, notre ami Ximoon fait encore des siennes...
PpHd est une vraie bourrique.
A mon avis, tu perds du temps avec TitaniK.
Lionel Debroux - membre de TICT.
    
./Post n°7   Marquer comme non lu.
serioussam Ecrit le: Lundi 7 juin 2004 à 11:38 Déconnecté(e)    Voir le profil de serioussam Envoyer un email à serioussam Visiter le site WEB de serioussam Envoyer un message privé à serioussam  

C'est bon avec yN, pas la peine de faire de fines allusions maintenant.
la shasse é ouvèrte poure lay maychants
    
./Post n°8   Marquer comme non lu.
Folco Ecrit le: Lundi 7 juin 2004 à 13:32 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


#crayon#
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°9   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 7 juin 2004 à 13:36 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Lionel Debroux :
Tiens, notre ami Ximoon fait encore des siennes...
PpHd est une vraie bourrique.
A mon avis, tu perds du temps avec TitaniK.

De toute façon, TitaniK ne va pas rester longtemps, le HW3Patch est en préparation.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°10   Marquer comme non lu.
Lionel Debroux Ecrit le: Lundi 7 juin 2004 à 16:05 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

Heureusement ! Un HW3Patch est bien plus utile que TitaniK, puisqu'il ne s'adresse pas qu'aux vieux trucs nécessitant déjà HW2Patch.
Lionel Debroux - membre de TICT.
    
./Post n°11   Marquer comme non lu.
Billy Charvet Ecrit le: Mardi 8 juin 2004 à 13:16 Déconnecté(e)    Voir le profil de Billy Charvet Envoyer un email à Billy Charvet Visiter le site WEB de Billy Charvet Envoyer un message privé à Billy Charvet  


Kevin >

Oué bon....
Pourquoi vous n'utilisez pas une méthode correcte pour utiliser PreOS ?

Celle que tu as montré est correcte, mais tu supprimes les RAM Calls PreOS only.

De plus bien des gens programment en Kernel. Je suis contre mais ça ne change rien.

Si la TIGCC Team n'inclut pas ce header que tu as fait (hum, avec les RAM Calls de PreOS...)
y'aura toujours des gens qui utiliseront kernel.h.

Ce que vous devriez faire c'est:

- Ne plus avoir un doors.h obsolète, mais un kernel.h permettant d'exploiter le KV5 à fond.

----> Pourquoi ? Parcequ'hélas il y aura toujours des utilisateurs de Kernel, et ne pas
fournir de header capable d'exploiter les RAM Calls de PreOS est le meilleur moyen
pour qu'ils se tournent vers le kernel.h de PpHd.

De plus, cette histoire de compatibilité est invalide car:

1-Les gens qui utilisent des RAM Calls présents depuis le KV3 sous UniOS par exemple
programmeront normalement, en ignorant les RAM Calls de PreOS.

2-Les gens qui utilisent les RAM Calls de PreOS savent qu'ils ne sont présents que sur
PreOS, car ils auront forcément lu les docs correspondantes dans l'archive de PreOS.

3-Y'a pas le choix. Apprenant qu'ils ne peuvent pas utiliser les RAM Calls PreOS only
sans kernel.h de PpHd, ils iront immédiatement utiliser kernel.h
(Même s'ils ne se servent pas des RAM Calls PreOS only d'ailleurs...)
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.
    
./Post n°12   Marquer comme non lu.
Kevin Kofler Ecrit le: Mardi 8 juin 2004 à 13:25 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Billy Charvet :
Oué bon....
Pourquoi vous n'utilisez pas une méthode correcte pour utiliser PreOS ?

Parce qu'il n'y en a pas. Tout code utilisant ces RAM_CALLs plante s'il est exécuté sous TeOS!

Celle que tu as montré est correcte, mais tu supprimes les RAM Calls PreOS only.

Je peux très bien faire une version avec les RAM_CALLs PreOs only, ce n'est pas ça qui est sale dans kernel.h. Mais c'est quand-même une mauvaise idée.

De plus bien des gens programment en Kernel. Je suis contre mais ça ne change rien.

Donc il faut tout faire pour les faire changer.

Si la TIGCC Team n'inclut pas ce header que tu as fait (hum, avec les RAM Calls de PreOS...)
y'aura toujours des gens qui utiliseront kernel.h.

Pas si PpHd remplace son kernel.h par la version propre, ce que je veux le forcer à faire. S'il ne le fait pas, et si kernel.h devient un vrai problème, je patcherai GCC et/ou tigcclib.h pour que kernel.h ne passe plus, et le problème sera règlé.

Ce que vous devriez faire c'est:

- Ne plus avoir un doors.h obsolète, mais un kernel.h permettant d'exploiter le KV5 à fond.

----> Pourquoi ? Parcequ'hélas il y aura toujours des utilisateurs de Kernel, et ne pas
fournir de header capable d'exploiter les RAM Calls de PreOS est le meilleur moyen
pour qu'ils se tournent vers le kernel.h de PpHd.

Pas si on rend impossible d'utiliser kernel.h.

De plus, cette histoire de compatibilité est invalide car:

1-Les gens qui utilisent des RAM Calls présents depuis le KV3 sous UniOS par exemple
programmeront normalement, en ignorant les RAM Calls de PreOS.

2-Les gens qui utilisent les RAM Calls de PreOS savent qu'ils ne sont présents que sur
PreOS, car ils auront forcément lu les docs correspondantes dans l'archive de PreOS.

Mais ce n'est pas acceptable pour nous: ces programmes plantent sous les autres kernels!

3-Y'a pas le choix. Apprenant qu'ils ne peuvent pas utiliser les RAM Calls PreOS only
sans kernel.h de PpHd, ils iront immédiatement utiliser kernel.h
(Même s'ils ne se servent pas des RAM Calls PreOS only d'ailleurs...)

Les RAM_CALLs PreOs-only ne seront jamais dans un header livré avec TIGCCLIB pas parce qu'ils sont PreOs-only, mais parce qu'ils sont kernel-only. Nous n'acceptons pas de features kernel-only dans TIGCCLIB. Tous ces RAM_CALLs seront acceptés si et seulement si un équivalent _nostub est programmé, et dans ces cas, on va probablement utiliser l'équivalent _nostub inconditionnellement pour la compatibilité avec les anciens kernels.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°13   Marquer comme non lu.
Kevin Kofler Ecrit le: Mardi 8 juin 2004 à 13:33 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Et de toute façon, on n'a même pas besoin de patcher TIGCC pour empêcher l'utilisation de ce header, ça échoue tout seul avec TIGCC 0.95: "unresolved reference to `__main'".

Bref, tous ceux qui utilisent le header avec succès utilisent une version obsolète de TIGCC, je vais leur gueuler dessus...
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°14   Marquer comme non lu.
Billy Charvet Ecrit le: Mardi 8 juin 2004 à 13:39 Déconnecté(e)    Voir le profil de Billy Charvet Envoyer un email à Billy Charvet Visiter le site WEB de Billy Charvet Envoyer un message privé à Billy Charvet  


Bon, pour moi, ça revient à une seule chose:

Il faut tout l'un ou tout l'autre. :D

Donc dans ce cas, il faut (c'est mon avis, mais sérieusement faites-le)
- Soit faire un kernel.h propre et KV5,
car personne n'utilise encore les autres kernels, et que PreOS peut marcher
partout, aussi bien sous les vieux AMS, que sur les V200 (important)
et puis avec Titanik/HW3Patch, sur TI-89 Titanium.

Et comme tout le monde aujourd'hui devrait être sous un AMS >= 2.07,
ça devrait être le seul kernel fonctionnel.

Ensuite si vous voulez pas l'intégrer à TIGCC, ben on devrait (donc vous ou qqun
d'autre, peut-être m^ moi) faire un petit
ensemble d'outils qui n'ont pas leur place directement dans TIGCC selon la team:

Une sorte de 2de TIGCC Tools Suite, avec les fichiers archive pour l'export TIB,
make (#love#), kernel.h, etc...

Quand à kernel.h, le mieux est que tu le fasses toi-même.
Si vraiment ça te répugnes, ne reste pas dans cette situation, tu sais bien
que PpHd ne bougeras pas le petit doigt pour programmer proprement,
alors force une détection dans les headers de tous ses hacks pour render kernel.h
incompatible.

- 2e solution: pour faire radical et obliger à programmer en _nostub,
virez carrément tout ce qui est kernel, donc doors.h, les defines de DOORS etc...
(éventuellement à part, comme l'export TIB, pour ceux qui veulent faire marcher
les anciennes sources)
Et EN PLUS, change les headers de façon à rendre kernel.h inutilisable.
Là ça donnera un sacré coup de fouet à ceux qui restent au kernel
(Ca ferait pas de mal à Pollux pour GTC IDE, ça)
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.
    
./Post n°15   Marquer comme non lu.
Kevin Kofler Ecrit le: Mardi 8 juin 2004 à 14:28 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


De toute façon, je viens d'apprendre que le prochain kernel.h sera inutilisable pour tout le monde à part PpHd (on ne peut carrément plus du tout utiliser TIGCCLIB, il remplace entièrement nos headers), donc le problème semble se règler de lui-même.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°16   Marquer comme non lu.
Lionel Debroux Ecrit le: Mardi 8 juin 2004 à 17:54 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> car personne n'utilise encore les autres kernels
Faux. Je ne sais pas si tu te rends compte de la lenteur des updates chez les utilisateurs finaux... Pour info, en 2002, j'ai trouvé DoorsOS II 0.95 et TI-Chess 2.00 sur une calculette... Personne n'avait UniversalOS (et encore moins PreOS qui n'était pas vraiment utilisable en 2002, PreOS 0.52 étant capable de crasher VTI juste à cause de l'APD...) au lycée, de moins en moins de personnes avaient des kernels car c'était trop instable. Ca n'est pas moi qui allais updater les kernels des autres, évidemment :P

> Et comme tout le monde aujourd'hui devrait être sous un AMS >= 2.07, ça devrait être le seul kernel fonctionnel.
Certainement pas ! Je n'utiliserai aucune version d'AMS ultérieure à 2.05 tant que les versions ultérieures boufferont un secteur d'archive supplémentaire alors que le compilateur et du mauvais code bouffent des kilo-octets. Surtout que les versions AMS 2.07+ n'apportent RIEN d'intéressant, comme je l'ai dit dans un autre topic sur Questions.

> Ensuite si vous voulez pas l'intégrer à TIGCC, ben on devrait (donc vous ou qqun
d'autre, peut-être m^ moi) faire un petit ensemble d'outils qui n'ont pas leur place directement dans TIGCC selon la team: Une sorte de 2de TIGCC Tools Suite, avec les fichiers archive pour l'export TIB, make (#love#), kernel.h, etc...
Réfléchis bien à ce que tu fais...

> De toute façon, je viens d'apprendre que le prochain kernel.h sera inutilisable pour tout le monde à part PpHd (on ne peut carrément plus du tout utiliser TIGCCLIB, il remplace entièrement nos headers), donc le problème semble se règler de lui-même.
Il baisse, là... Il a perdu et il le sait, il se raidit et devient extrémiste ?
Lionel Debroux - membre de TICT.
    
./Post n°17   Marquer comme non lu.
Folco Ecrit le: Mardi 8 juin 2004 à 18:58 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Kevin, t'es sure qu'une position si radicale ne détournerait pas les programmeurs de TIGCC, et non de PreOS??
(moi je m'en fout je prog en nostub, mais bon c'est pour les autres)
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°18   Marquer comme non lu.
Kevin Kofler Ecrit le: Mardi 8 juin 2004 à 19:30 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Lionel Debroux :
> Et comme tout le monde aujourd'hui devrait être sous un AMS >= 2.07, ça devrait être le seul kernel fonctionnel.
Certainement pas ! Je n'utiliserai aucune version d'AMS ultérieure à 2.05 tant que les versions ultérieures boufferont un secteur d'archive supplémentaire alors que le compilateur et du mauvais code bouffent des kilo-octets. Surtout que les versions AMS 2.07+ n'apportent RIEN d'intéressant, comme je l'ai dit dans un autre topic sur Questions.

Tu ne seras pas content alors, parce que je viens de rajouter la possibilité de mettre des MIN_AMS 208, 209 et 300 à TIGCC...
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°19   Marquer comme non lu.
Lionel Debroux Ecrit le: Mercredi 9 juin 2004 à 10:57 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

Ce qui est dommage, c'est que ces MIN_AMS soient en général bien trop élevés (les programmeurs plus ou moins débutants n'ayant à leur disposition qu'AMS 2.09 / 3.00 par exemple ne prennent pas de risque, même si leur programme est MIN_AMS 101 - ce qui rend leur programme inutilisable pour nombre d'utilisateurs, pour rien !). Voir Jude Nelson et son Pinball MIN_AMS 205 à l'origine, alors que MIN_AMS 101 suffit.
Une des rares utilisations de MIN_AMS >= 200 est le trifouillage de l'alpha-lock contre la volonté des utilisateurs. Des fonctions comme GetDataType, DataTypeNames, SmapTypeStrings sont MIN_AMS 200 - tant que les Address hacks que j'ai faits et que j'utilise pour TICT-Explorer 1.40 ne sont pas intégrés...

J'aimerais que tu mettes dans la doc un avertissement fort sur le fait que MIN_AMS >= 207 n'est que très rarement nécessaire (déjà MIN_AMS >= 200 est rare)...
Lionel Debroux - membre de TICT.
    
  :: Index » Sujets divers - Miscellaneous » Autre, divers... » Saletés dans kernel.h (46 réponse(s))
Pages : 1/3     « [1] 2 3 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 58.14ms avec 18 requetes