Truc byzarre d'AMS. - Page 1

Voila. J'ai eu un bug report de mon kernel Preos. Bug en utilisant dispg.
Effectivement ca merdait. J'ai extrait le code critique : st.b $00 !
Strange. Ca ne devrait etre que le vecteur d'init de la pile pourtant, et avec les adresses 24 bits, rien ne devrait etre change....
Faisons une recherche si AMS accede a cette donnee (Data breakpoint : $00).
Allons dans l'ecran graph.
Pouf ! Bingo !
Y'a le code suivant :
move.w $0,d0
bsr machintruc
rts
machintruc:
... / truc qui test si d0+$???-$4000< (signe $FFFF).

Bref, ca merdait a ce niveau. Ma question est simple :
pourquoi AMS accede a cette portion de vecteur de reset de pile ?
J'ai trouve deux explications :
+ soit s'aurait du etre : move.l $0,d0 // Chargement adresse pile.
+ Soit c'est un bug, et c'est move.w #0,d0 qui aurait du etre la...

Bref, ils ont un peu abuse de les ingenieurs de chez ti
[edit]Edité par PpHd le 19-12-2001 à 16:32:13[/edit]

Bizarre. Quel qu'il en soit, c'est un bogue. Je penchais d'abord plutôt pour le # oublié, mais comme il y a des calculs après, c'est plutôt l'autre bogue. Surtout que AMS est écrit en C, et qu'un *(unsigned int *)0 avec le mauvais type de ints (probablement avec un compilateur règlé pour des ints 16-bits et un ingénieur arrivant des x86|x>=3 en 32 bits) est vite fait. Plus vite qu'un * oublié. Mais ce ne sont que des spéculations évidemment. Il faudrait voir ce que fait le code ensuite.

Et le fait d'écrire à l'adresse 0 dans PreOS n'est pas bien. Voilà pourquoi il faut toujours laissé activé la protection de la mémoire basse et ajouter $40000 quand on veut y écrire.

Ben tu sais en fait je faisais st.b $4000, mais c'etait plus clair d'epliquer avec st.b $0. Et ca revient au meme. N'empeche que c'est vraiment etrange. Et seulement pour afficher des graphs (APPS-> Graph).

Donc tu y écrivais exprès? Tu as quoi à fouiller à l'adresse 0, toi? Il y a suffisamment de vecteurs non utilisés!

Une question sur les int : on fait comment pour se servir des vecteurs de la fin ? Ceux qui necessitent l'utilisation de la patte /AVEC ?

Disons que l'interet de faire un st.b $0, et que si un jsr 0 / jmp 0 se pointe, il declenchait une exeption immediatement ! Et n'executait pas de code foireux
>Miles: Je crois qu'on peut pas.

Ah, je vois maintenant. Mais AMS se faut aussi avoir...
Mais:
1. Si les programmeurs utilisaient notre chaîne d'outils la plus récente, il n'y aurait pas de jsr 0 ni de jmp 0 qui passeraient. (C'est le résultat typique d'un bogue du linker de DoorsOS et des anciennes versions de TIGCC.)
2. J'ai maintenant une nouvelle théorie sur ce bogue. (Rappel: ce sont de pures spéculations en vue des données dont je dispose.) Il y avait dans une ancienne version d'AMS (peut-être interne à TI) une variable globale dont ce code se servait. Puis à un moment, TI s'est dit que cette variable ne sert à rien et l'a virée sans voir que ce morceau de programme s'en servait encore. Et leur chaîne d'outils de développement, au lieu de donner un message d'erreur en ce cas, met simplement l'adresse de la variable à 0. D'où ce résultat. Et comme d'habitude ça marche, personne chez TI ne s'est rendu compte de ce bogue.
[edit]Edité par Kevin Kofler le 21-12-2001 à 20:33:48[/edit]

Ils sont marrant chez ti:

----- Original Message -----
From: <ti-cares@ti.com>
To: ExtendeD <ola.e-ml@wanadoo.fr>
Sent: Monday, December 24, 2001 12:38 PM
Subject: Re: AMS des TI89/92+

Merci pour votre e-mail à Texas Instruments.

Une instruction de ce genre est effectivement présente dans l OS de la
calculatrice, mais de là
à dire que c'est un bug ; ça n'est pas pour faire plaisir à nos
programmeurs

Une lecture de pointeur de pile est toujours nécessaire, surtout pour ce
genre d' opérations;
ne fusse que pour faire appel à un autre programme; sous-programme, ou à
une autre série
d'instructions; comme c'est le cas ici.
Rassurez-vous; ça n'a aucune incidence négative sur la
calculatrice;n'influence et ne fausse
aucun calcul.
Pour ce qui est du :"we're not able to give you any support on assembly
programming",
il est vrai que nous ne sommes pas dans l'obligation d' offrir un support
de programmation, encore moins celle en Assembleur; c'est donc uniquement
par "plaisir personnel" que cette réponse vous arrive.
Merci de vous être donné la peine de nous le signaler, peut-être dans la
version 2.06 du système opérateur
des changements seront prévus ...

En plus ils ont peut-être prévu un nouvel AMS avant 2042...

on peut tjrs rever
et ils la prevoit quand cette rom 2.06 ???
ca pourrait etre interressant s'ils corrigent tous les bugs qui restent

tu parles... y en ont rien à branler des trucs ke tu leur signale... ils sont pas prêts de nous sortir une rom "parfaite" (si ça existe (me sortez pas hp! )), et ça m'étonnerait beaucoup que tous les petits bugs que l'on puisse trouver soient notés dans les trucs à corriger des programmeurs de chez Ti...

>ça m'étonnerait beaucoup que tous les petits bugs que l'on puisse trouver soient notés dans les trucs à corriger des programmeurs de chez Ti

LOL, tu ne sais pas de quoi tu parles...

pkoi? tu t'attends à ce qu'ils sortent une nvelle rom dont tous les bugs trouvés auront été corrigés?

Parce que j'ai été programmeur de chez TI (en quelque sorte) et crois moi les bugs ils en prennent soin. Je recevais des listes de bugs de mon application toutes les semaines, et j'ai même eu une extension de contrat pour les corriger. Non seulement ils ont de tres bons testeurs, mais ils sont tres strictes au niveau de leur gestion. Maintenant, si AMS n'est pas 100% bug-free, c'est parce que c'est un programme extremement complexe.

c vrai que c quelque peu coimplexe...
mais ça pourrait être mieux
(plus rapide, moins gros, ... )

eh bien écoute Nitro, si c'est comme tu dis, c'est très bien, mais apparemment ils ne se foulent plus trop... c un constat, c tt
c sur que tu es mieux placé que moi pour en parler, mais concrètement, ça va faire un bon bout de temps qu'ils n'ont plus sorti de nouvelle rom, et avec la mort de hp, ça va pas s'arranger...

>Nitro: qu'est-ce que tu faisais en gros chez TI?

ça fait depuis... heu, aout 2000, je crois que la ROM2.05 est sortie, non ?

5/7/2000

et ouais! bientot un an et demi de bugs !!

Nitro>les bugs reports qu'on te faisait, ça devait être certainement parceque tu n'étais pas un programmeur "officiel" (je suppose) je veux dire par là que tu ne faisait pas partie de l'équipe qui développe les roms (je suppose aussi )
ils doivent être bcp- exigeants avec leurs programmeurs permanents...
d'ailleurs, il n'y a qu'à lire la réponse qu'a reçue ExtendeD...

"à dire que c'est un bug ; ça n'est pas pour faire plaisir à nos programmeurs "

on s'en fout que ça leur fasse plaisir ou non, si ils le prennent de haut comme ça, c compréhensible ke les chosent n'évoluent pas vite
enfin bon, au moins ils sont sympas, ils répondent aux mails...

>qu'est-ce que tu faisais en gros chez TI

Une APPS pour TI-83 Plus (en ASM Z80).

>ils doivent être bcp- exigeants avec leurs programmeurs permanents

Je ne pense pas...

avoir une Rom ki plante Cé pas terible pour l'Image de marke
surtout sur un biniou a + de 1000 frs

enfin elle plante pas toute seule non plus non ???
c un bug qui se voit pas si on trifouille pas un peu je pense

voylà un topyc qui me playt

arrete de martiryser PpHd ( ;-) )

ahahah celui là tu peux pas le modifier ce titre de topic

Ce sera le seul :P

Au passage, je crois qu'il y un autre bug dans l'AMS (au moins le 2.05); dans un programme du type:

local k
loop
bcp_d_instructions()
getkey() -> k
if k=264
Text "esc"
bcp_d_instructions()
endloop

J'ai desfois (au bout de 5000 loops par ex) une erreur "Test can't resolve to true or false"... pour le if k=264!
Je peut pas le reproduire dans un programmes bidon, donc doit y avoir autre chose que la taille. Mais c'est toujours dans des gros programmes (il doit m'en rester qui font ça si ça interesse quelqu'un).

Au pire (si c'est bien un bug), comment je peut contacter Ti?
[edit]Edité par Brice le 12-04-2002 à 22:36:16[/edit]