PreOS 0.70 - Page 5

PpHd :

 lea ghost_space+42,a0  
 move.l a0,my_ghost  
 ...  
 move.l my_ghost,a1  
 lea 8(a1),a2  
 addq.l #2,(a2) 

Mais oui! Tu as raison. Ca c'est du code C genere pour ecrire dans un vecteur !

#define set_vector(n,ptr) *((volatile unsigned long *)((unsigned long) n + (unsigned long) &GHOST_SPACE)) = ((unsigned long) ptr)

Ca c'est du code C normal pour mettre a jour un vecteur.

Et alors ? Ca peut foirer pour n'importe quelle raison... (je sais pas moi, changement des interruptions) Et on ne détectera que ça foirera qu'au moment où la TI-90+++ sortira et que tous les progs auront du code de changement de vecteurs buggé (mais qui fonctionnait bien jusqu'alors).

En tout cas juste pour dire que ça serait dangereux de s'en servir en C (sauf à passer par de l'ASM inline), et que ce serait une mauvaise idée de le mettre dans kernel.h (ou alors Kevin aurait pour une fois raison de râler contre)...

PpHd :
>Niet! Il y a une méthode propre (bclr.b #2,$600001), c'est celle qu'il vaut encourager!
>Que feras-tu si le prochain modèle n'a plus du tout de ghost space?
Tu crois que je n'y ai pas pense ?
J'ai le choix entre:
+ Executer le programme entierement avec la protection ecriture desactive.
+ Mettre ghost space a une adresse impaire et intercepter les adress error.
+ Intercepter les stack overflow et les reinterpreter correctement.

Et après on nous accuse, nous (l'équipe de TIGCC), de propager ce genre de saletés! Vous voyez bien que ce sont les kernels qui diffusent ces méthodes sales! Bon sang, pourquoi rajoutes-tu ce RAM_CALL totalement inutile à PreOs au lieu d'expliquer qu'il faut utiliser bclr.b #2,0x600001 et bset.b #2,0x600001 tout simplement (comme SetIntVec de TIGCCLIB le fait désormais et le fera toujours, on ne va plus jamais remettre ce hack obsolète, avec ou sans ton RAM_CALL à la con!)???

PpHd :

 lea ghost_space+42,a0 
 move.l a0,my_ghost 
 ... 
 move.l my_ghost,a1 
 lea 8(a1),a2 
 addq.l #2,(a2)

Tu as lu la doc de kernel::GHOST_SPACE ? Non, donc tu sais pas que ce code n'est pas autorise.

Et tu crois que les programmeurs kernel vont t'écouter? Alors que tu n'écoute pas ceux qui te disent qu'il ne faut pas faire ça, toi?

PpHd :
Mais si vous voulez pas vous en servir, ne vous en servez pas ! On croirait que j'impose son utilisation.

Le simple fait que ce hack stupide est présent et encouragé est le problème.
Et tu gonfles PreOs pour rien avec ce hack!

PpHd :
Ca c'est du code C genere pour ecrire dans un vecteur !

#define set_vector(n,ptr) *((volatile unsigned long *)((unsigned long) n + (unsigned long) &GHOST_SPACE)) = ((unsigned long) ptr)

Ca c'est du code C normal pour mettre a jour un vecteur.

Même si ça marche avec la version actuelle de GCC, il n'y a aucune garantie que ce code est émis en une seule instruction! GCC peut optimiser (ou refuser d'optimiser) absolument ce qu'il veut là-dedans (à part les écritures dans les vecteurs elles-mêmes qui sont en volatile, mais ça ne comprend pas les calculs d'adresse!).

>En tout cas juste pour dire que ça serait dangereux de s'en servir en C (sauf à passer par de l'ASM inline),
>et que ce serait une mauvaise idée de le mettre dans kernel.h (ou alors Kevin aurait pour une fois raison de râler contre)...


>Et alors ? Ca peut foirer pour n'importe quelle raison... (je sais pas moi, changement des interruptions).
>Et on ne détectera que ça foirera qu'au moment où la TI-90+++ sortira et que tous les progs auront du
>code de changement de vecteurs buggé (mais qui fonctionnait bien jusqu'alors).


>Et après on nous accuse, nous (l'équipe de TIGCC), de propager ce genre de saletés!


>Vous voyez bien que ce sont les kernels qui diffusent ces méthodes sales!


>Bon sang, pourquoi rajoutes-tu ce RAM_CALL totalement inutile à PreOs


>au lieu d'expliquer qu'il faut utiliser bclr.b #2,0x600001 et bset.b #2,0x600001 tout simplement


>(comme SetIntVec de TIGCCLIB le fait désormais et le fera toujours, on ne va plus jamais remettre ce hack obsolète, avec ou sans ton RAM_CALL à la con!)???


>Et tu crois que les programmeurs kernel vont t'écouter?


>Alors que tu n'écoute pas ceux qui te disent qu'il ne faut pas faire ça, toi?


>Le simple fait que ce hack stupide est présent et encouragé est le problème.


>Et tu gonfles PreOs pour rien avec ce hack!

>Même si ça marche avec la version actuelle de GCC, il n'y a aucune garantie que ce code est émis en une seule instruction! GCC peut optimiser (ou refuser d'optimiser) absolument ce qu'il veut là-dedans (à part les écritures dans les vecteurs elles-mêmes qui sont en volatile, mais ça ne comprend pas les calculs d'adresse!).

voif func_set(int n, void *ptr)
{
set_vector(n,ptr);
}

C'est la meilleure manière d'avoir des instructions d'addition, justement.

C'est la meilleure manière d'avoir des instructions d'addition, justement.

PpHd :
>En tout cas juste pour dire que ça serait dangereux de s'en servir en C (sauf à passer par de l'ASM inline),
>et que ce serait une mauvaise idée de le mettre dans kernel.h (ou alors Kevin aurait pour une fois raison de râler contre)...


>Et alors ? Ca peut foirer pour n'importe quelle raison... (je sais pas moi, changement des interruptions).
>Et on ne détectera que ça foirera qu'au moment où la TI-90+++ sortira et que tous les progs auront du
>code de changement de vecteurs buggé (mais qui fonctionnait bien jusqu'alors).


>Et après on nous accuse, nous (l'équipe de TIGCC), de propager ce genre de saletés!


>Vous voyez bien que ce sont les kernels qui diffusent ces méthodes sales!


>Bon sang, pourquoi rajoutes-tu ce RAM_CALL totalement inutile à PreOs


>au lieu d'expliquer qu'il faut utiliser bclr.b #2,0x600001 et bset.b #2,0x600001 tout simplement


>(comme SetIntVec de TIGCCLIB le fait désormais et le fera toujours, on ne va plus jamais remettre ce hack obsolète, avec ou sans ton RAM_CALL à la con!)???


>Et tu crois que les programmeurs kernel vont t'écouter?


>Alors que tu n'écoute pas ceux qui te disent qu'il ne faut pas faire ça, toi?


>Le simple fait que ce hack stupide est présent et encouragé est le problème.


>Et tu gonfles PreOs pour rien avec ce hack!

lol
mais sérieusement évite de le foutre dans kernel.h, c'est pas parce que ça "devrait marcher" que ça marchera...

>mais sérieusement évite de le foutre dans kernel.h, c'est pas parce que ça "devrait marcher" que ça marchera...

>Et après on nous accuse, nous (l'équipe de TIGCC), de propager ce genre de saletés!

il faudrait que je retrouve un post où justement tu conseillais ce hack car il permet de gagner en taille

Je ne comprends pas ce que tu veux. Regarde bien ce que fais RegisterVector. Il enregistre un vecteur dans la copie interne de PreOS. Je me demande d'ailleurs s'il doit aussi l'activer (ie le copier dans les vecteurs reels ?).

Oublie ce que j'ai dis j'ai encore parlé trop vite sans avoir bien lu la doc

Il faut que tu revoies ta methode pour clarifier clairement ce que doit faire tsrlib.

tsrlib@0000:
input : a0.l pointeur vers le début de la fonction void tsr(EVENT * event)
a1.l pointeur vers le nom du tsr
a2.l pointeur où on mettre le TsrID (sauf si a2 = NULL)
d0.l taille de la fonction tsr

tsrlib alloue un bloc, y recopie le TSR et le code pour la liste chaînée, met à jour le EV_Hook. Il s'occupe également des relogements.

alosr bientot la RC2?

Flanker
:

Il faut que tu revoies ta methode pour clarifier clairement ce que doit faire tsrlib.

tsrlib@0000:
input : a0.l pointeur vers le début de la fonction void tsr(EVENT * event)
a1.l pointeur vers le nom du tsr
a2.l pointeur où on mettre le TsrID (sauf si a2 = NULL)
d0.l taille de la fonction tsr
tsrlib alloue un bloc, y recopie le TSR et le code pour la liste chaînée, met à jour le EV_Hook. Il s'occupe également des relogements.

Déjà évite d'appeler les hooks d'évènements "tsr" (il y a d'autres types de TSRs), et puis ce système ne ressemble même pas à un TSR conforme à ma convention...

ce système ne ressemble même pas à un TSR conforme à ma convention

Et depuis quand tout doit être conforme à tes idées ?

C'est indispensable pour l'interopérabilité correcte entre les hooks d'évènements.

Déjà évite d'appeler les hooks d'évènements "tsr" (il y a d'autres types de TSRs),

la fonction tsrlib@0000 s'occupe uniquement des hooks, c'est vrai, mais si ça peut te rassurer, il y a d'autres fonctions pour les autres tsr

C'est indispensable pour l'interopérabilité correcte entre les hooks d'évènements.

la version 2 n'est pas conforme à la version 1, et pourtant tu l'as acceptée, pourquoi n'en serait-i pas de même pour une version 3

Flanker: Est-ce que le minimum proposee (les 3 premiers ramcalls) te convient ?

Et depuis quand tout doit être conforme à tes idées ?

bah uninevhk est bien le désinstalleur officiel car unhook (40% plus petit) n'est pas prouvé, alors ...

Flanker
:

C'est indispensable pour l'interopérabilité correcte entre les hooks d'évènements.

la version 2 n'est pas conforme à la version 1, et pourtant tu l'as acceptée, pourquoi n'en serait-i pas de même pour une version 3

La version 3 sera une version compatible Titanium de la version 1. Tous les changements de la version 2 seront révoqués. Tu l'as voulu avec tes trucs kernel à la noix.

J'ai toujours été contre tes changements, c'était un compromis, mais comme de toute façon tu n'en fais qu'à ta tête, ce compromis n'est plus.

re-

Arg ca va me faire une 3ieme et une 4ieme signature de TSR dans Preos a gere. #grr#

y a aura EvHk, Evhk, un autre truc et h0oK (mais la dernière n'est pas définitive, faut que je finisse les négociations avec moi-même). J'y peux rien si Kevin fait la tête ^^

Je vais revenir à evHk tout simplement (les hooks sont entièrement compatibles avec la première convention, c'est juste l'obligation de rajouter 0x40000 qui sera supprimée et changée en une recommendation HW2-only et une interdiction pour HW >=3), donc il n'y aura pas une nouvelle signature de ma part. Il faudra s'en prendre uniquement à Flanker pour les ajouts des nouvelles signatures!

méchant Flanker, qui ne veut pas rester à la préhistoire des Hook

Flanker, c'est le moment ou jamais: la convention 2.00 te convient-elle (Dans ce cas, je pourrais la rendre rapidement compatible Titanium et on n'en reparle plus.) ou veux-tu encore des changements pour accomoder tes hooks kernel (Dans ce cas, il y aura 2 conventions concurrentes, désolé.)?

bah elle me convient pas, vu qu'elle n'autorise pas l'exportation de fonctions, ni les RAM_CALL