Apprendre l'assembleur sur Atari ? - Page 6

bref, on se comprend pas et c'est hs, let's stop that

mov ah, 09h mov dx, offset message int 21h ret message: db "Hello world!", "$"Une fois assemblé, ça donne un fichier .com de 21 octets

#define _GNU_SOURCE /* See feature_test_macros(7) */ #include <unistd.h> #include <sys/syscall.h> int _start() { char *ptr="Hello World!"; Syscall(SYS_write, 1, ptr, 12); }
Une fois compile comme qu'il faut bien: 840 octet sur un cpu x86_64 sous linux

les include sont commentés ?

non, en C on met un # devant include, c'est pas un commentaire

Playmobil voulait sans doute parler du commentaire entre /*...*/ sur la 1ère ligne

840/21=40 !!!!

40 fois plus gros !!!!!!

Rien a rajouter.....

GT Blindé !!!

Cà fait que 8 octets de code, j'aimerais voir ;p


Edit; j'avais pas vu le message de O², j'ai cru 21 octets sur Atari.

GT: le problème c'est qu'il n'y a pas 840 octet de code, sous linux le format objet utilise (d'or) prends pas mal de place. La même chose 100% en asm fait ~600 octets

vince (./155) :
non, en C on met un # devant include, c'est pas un commentaire

Autant pour moi... J'ai rien dit donc !

Godzil (./159) :
GT: le problème c'est qu'il n'y a pas 840 octet de code, sous linux le format objet utilise (d'or) prends pas mal de place. La même chose 100% en asm fait ~600 octets

Godzil je pensais que tu étais un gars bien et pourtant tu as deux tares :


C et Linux........


GT Godzil


P.S. :

C, ça passe encore, mais Linux... beurk !

Trop de Troll tue le Troll

Et ben, priez pour que je ne rentre pas dans le troll, on est pas rendu sinon

class C 
{
   public static void main( String[] args )
   {
      System.out.println("Hello World!") ;
   }
}

332 octets (avec une string unicode)

Quel OS ?

Windows 7 — et un jdk 7 quelconque.

Le Java, ça compte pas.

C'est du racisme

Vous avez fini de pourrir le topic du GT ?

Déjà 6 pages, et le GT n'as pas réussis à insérer un seul lien de tuto ASM avec vos conneries !


Sinon, en GFA

PRINT "HELLO GT"

Ca fonctionne très bien aussi !

En GFA, ça marche, mais une fois compilé, ça fait quelle taille ?

GT Turbo (./144) :
En gros on c'est combien de temps (cycl)es prend EXACTEMENT chaque instruction, donc après on en remplace une par deux autres mais qui sont plus rapides, etc...

C'est un peu à ce genre de chose que je pensais aussi lorsque je parlais de maths et d'ASM : calculs du nombre de cycles, calculs du nombre d'octets, calculs pour l'optimisation, etc. bref, de quoi se muscler le lobe préfrontal ! Reconnaissez que ça peut paraitre intimidant au premier abord.
En revanche, l'approche qui consiste à dire que l'ASM fonctionne en grande partie sur un principe de IF/THEN/ELSE me semble beaucoup plus rassurante.

Juste comme ça, par curiosité, quel niveau fautdrait-il (+ ou -) en ASM pour concevoir un programme qui permette de compter le nombre de couleur unique par ligne (pour un écran de 320 x 200 par ex.) dans une image ?

A1WSX (./172) :
Juste comme ça, par curiosité, quel niveau fautdrait-il (+ ou -) en ASM pour concevoir un programme qui permette de compter le nombre de couleur unique par ligne (pour un écran de 320 x 200 par ex.) dans une image ?

Ça me semble être un bon exercice pour un noob.

A1WSX (./172) :
calculs du nombre de cycles

Oui enfin bon, faut s'habituer à optimiser le code critique, le reste on s'en fout un peu. À la rigueur, optimiser en taille, oué. Ne te préoccupe pas trop de ça si tu débutes.
Et le nombre de cycles théorique reste indicatif, c'est quand même nécessaire de mesurer, on n'est jamais complètement sûr de comment une routine va se comporter par rapport à une autre (mangeur de cycles)

A1WSX (./172) :
Juste comme ça, par curiosité, quel niveau fautdrait-il (+ ou -) en ASM pour concevoir un programme qui permette de compter le nombre de couleur unique par ligne (pour un écran de 320 x 200 par ex.) dans une image ?

Ça dépend de l'algorithme utilisé.

Avec un algorithme naïf, c'est un problème pas très difficile.

Avec un algorithme optimisé, ça l'est nettement plus.

Et puis compter les cycles c'est vrai sur un proco 8bit, un 68000 ca deviens tout de suite moins vrai sur un 68020, 80386, ARM etc..

'Mauvaise fois inside', c'est plus dur de calculer mais toujours possible, chapite 10 par exemple de la doc du 68040 :

http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=68K


C'est sur que c'est plus dur mais tout a fait possible.



GT En train de compter sur mes doigts.

Et puis bon avec le 68K de SC c'est pas dur, chaque instruction ne fait qu'un cycle

On ne parlera pas des SC68000


GT A un cycle !!

huggyone76 (./171) :
En GFA, ça marche, mais une fois compilé, ça fait quelle taille ?

4066 octets !

J'ai pas voulu le faire pour le GFA, car il y a un paquet d'options de compilation et j'en connais aucune, peut etre que si Cooper passe dans le coin ou Rajah.