Concour d'optimisation ! - Page 1

-

en optimisation mémoire, Kevin est bien parti

Ca serait en optimisation vitesse, par contre...
ppHd ? où tu es

-

c clair que optimisation vitesse, c plus dur
(du moins, tant qu'un compteur de cycles ne sera pas sorti)

cela dit, optimisation mémoire, c pas forcément toujours mieux
(mais je v pas relancer le débat)

Ce qui m'énerve, c'est que j'ai dû utiliser 2 fois moins d'instructions que son code x86 pour avoir 1 octet de moins... Mais l'exemple montre quand-même que malgré tout, le code est plus petit sur 68k. Ou du moins le système d'exploitation est meilleur, vu qu'on peut faire du code plus compact.

squale92 a écrit :
c clair que optimisation vitesse, c plus dur

C'est la raison principale pour laquelle je préfère l'optimisation mémoire.

-

Moi :
include "ams"
bsr.s cont
dc.b 'Hello World !',0
cont
dc.w $f800+ST_helpMsg
dc.w $a000+1000

Le bsr.s pour pushe le message (merci JM),
Le message d'erreur qui fait office d'attente de la touche et pour pope et quitte.
Je t'ai battu de 4 octets Kevin
Et si tu me dis, oui mais il n'est pas relancable par la calc, je te dis : c'ést pas presice dans l'enonce.

dc.w $a000+1000
Ça, j'aurais pu le faire moi aussi...
Mais bravo pour l'idée du bsr.
J'ai toujours été nul en optimisation. Même en optimisation en taille.

Et le programme est relançable par la calculatrice sous AMS 2. (C'est d'ailleurs la même chose pour mon dc.w $a004.)

Sinon, si on peut utiliser n'importe quel message d'erreur, j'ai une autre solution qui donne la même taille que celle de PpHd:

 include "ams"
 pea.l string(PC)
 dc.w $f800+ST_helpMsg
 dc.b $a0
string: dc.b 'Hello World !'

-

PpHd a écrit :
Je t'ai battu de 4 octets Kevin

Non, de 3 octets. Chez toi, la chaîne est au milieu de ton code, donc tu dois la terminer par un 0. Chez moi, elle est à la fin, donc il y a déjà le 00 00 prévu par le format.

Et si un message d'erreur quelconque est admis, je peux moi aussi épargner 3 octets, cf. ci-dessus. Là aussi, le 3^ème octet gagné ne peut être gagné qu'avec la chaîne à la fin.

Orion_ a écrit :
j'assemble le prog de PpHd, et paf, ER_Throw
impossible de resseter ma calc

LOL, il a mis un numéro de message d'erreur trop grand.
Ma solution de 25 octets marche.
La sienne marcherait s'il avait utilisé un message d'erreur qui existe.

Je me suis plante sur le message d'erreur, c'est tout. choisi un message d'erreur oficiel +200 par exemple

Et moi je sors donc cela :
Moi :
include "ams"
bsr.s cont
dc.b 'Hello World !',0
cont
dc.w $f800+ST_helpMsg
dc.b $a1

Un octet en moins

-

Je n'y peux rien si as est nul

Essaye bsr.b sinon.

-

Ton concours est bateau. comment faire pour savoir si ca marche bien.
Sinon moi je fais un
dc.b$A1

Et je gagne

Orion_ a écrit :
mouarf, non, c a la compilation que sa a foiré:

PpHd, ton bsr.s marche po,
et si on met bsr
sa fait 27 octets, et pas 24

de plus le code a Kevin, fait 26 octets, mais il crash la calc

Moi, j'ai assemblé avec la dernière version de AS, et ça me donne 25 octets et pas de plantage.
Et le code de 25 octets de PpHd marche lui aussi très bien chez moi (quand je remplace le $A000+1000 par un message d'erreur existant).
Je n'ai pas essayé son code de 24 octets, mais je pense qu'il marche aussi.

-

-

-

La c'est mieux

-

Moi : 30 octets.

Orion_ a écrit :
PpHd, Vainqueur avec 24 octets
Kevin, le $a0, fait planter la calc

As-tu bien mis un dc.b?

-

C'est que ta version de AS ne marche pas. $a0,'H' est une erreur valable. Et j'ai essayé et ça a marché.

>Pas de prog kernel, parceque la restoration de l'ecran est automatique
Pkoi ? Et alors ?

-

Je repete et alors ? Le stub me semble-t-il fait un prog peut etre un peu gros, nan ?