NO-ASM-Team

→ **MyCalcs** profile · de **kurapix** » 12 Mar 2008, 08:47

... Scorpiolivier ... arrête de dire des bêtises (quand on sait pas on se tait ou on émet un doute).

Je répète : peu importe le langage de programmation utilisé, si on code comme un pied ça favorisera les bugs et donc les plantages ... c'est pas au langage d'éviter les bugs mais au programmeur.

Kurapix

→ **MyCalcs** profile · de **scorpiolivier** » 12 Mar 2008, 23:30

Mais c'étais une blagounette dans l'ésprit de progval .

→ **MyCalcs** profile · de **ProgVal** » 13 Mar 2008, 12:26

tama a écrit:ProgVal, c'est toi qui doit mieux coder , si ça bug c'est d'ta faute, pas d'la faute de l'ASM

Je parle de programmes conçus par d'autres programmeur.
Par exemple hier, j'ai eu une fenêtre "Error: Access memory Violation", mais que je ne pouvais la quitter. Heureusement que l'ASM ne bloque pas (encore) le boîtier des piles...

→ **MyCalcs** profile · de **kurapix** » 13 Mar 2008, 13:31

Bref ... c'est pas à cause de l'ASM mais bien à cause du/des programmeurs ...

→ **MyCalcs** profile · de **kurapix** » 13 Mar 2008, 17:02

C'est pas dû au processeur .... peu importe le processeur, il y aura un ASM lui correspondant ...
Je maintiens ce que je dis, c'est à cause du/des programmeurs, il peut s'agir des programmeurs de l'OS ou des programmeurs du compilateur, .... bref partout où peut agir un programmeur il y a risque de bugs ...
Ca m'étonnerais que ce soit au niveau du processeur ... (un bug matériel ... euh ^^")

Kurapix

→ **MyCalcs** profile · de **kurapix** » 13 Mar 2008, 20:21

Bah dans tous les systèmes quel qu'il soit, un simple bug peut avoir des répercussion énorme. Un simple BOF peut faire planter le programme comme le système entier par exemple.

Il faut voir dans quel conditions les programmes plantent pour le savoir précisemment car oui certains bugs sont asser difficile à trouver ... Certains bugs se dévoilent dans certaines conditions uniquement d'où l'impression qu'on peut avoir pour certains programmes buggés qu'ils ne le sont pas.
Le problème de l'ASM est qu'il est pas évident à utiliser (encore moins que le C ...), de ce fait des bugs peuvent surgir.
Et puis un mauvais code restent un mauvais code donc de par sa définition : risque de plantage plus élevé qu'un programme "bien" coder.

Pour la saturation mémoire il y a plusieurs explications : tout d'abord la manière de l'OS de la Ti de gérer la RAM, les flashsapps bouffent de la RAM, la RAM sert de moyen de stockage (c'est possible puisque continuellement alimenté par les piles) et donc ... moins de RAM.
Un truc courant quand on programme : oublier les free suivants les malloc ... d'où memory leak.
...
La mémoire n'a pas vraiment l'air optimiser sous les Ti.

Kurapix