Voir le code assembleur

International Français
21

Quand s'utilise le avr-gcc pour faire la compilation du code en langage C pour le AVR au lieu
de l'IDE du Arduino est possible regarder le code generé en assembly quand on utilise le command
-S au prompt. Par example

root@pedro-Vostro-1014:/home/pedro# avr-gcc -S -Os -mmcu=atmega168 -o teste teste.c

J'ai fait ça en utilisé çe terminal du Linux en command de prompt.
Donc le text du code traduit au assembly a apparu en mon fichier.

La IDE du Arduino utilise le avr-gcc. Je ne sais pas comme tourné cette option du
compilateur a l'IDE du Arduino :frowning:

22

osaka:
Tien cette sortie console m'a permis de trouver quelque chose d'interessant -> "Compiler.java" dans le source de l'ide arduino.

Et la réponse à ma question pour make ou ant ...

  static private List getCommandCompilerS(String avrBasePath, List includePaths,

String sourceName, String objectName, Map<String, String> boardPreferences) {
   List baseCommandCompiler = new ArrayList(Arrays.asList(new String[] {
     avrBasePath + "avr-gcc",
     "-c", // compile, don't link
     "-g", // include debugging info (so errors include line numbers)
     "-assembler-with-cpp",
     "-mmcu=" + boardPreferences.get("build.mcu"),
     "-DF_CPU=" + boardPreferences.get("build.f_cpu"),
     "-DARDUINO=" + Base.REVISION,
   }));

List baseCommandCompiler = new ArrayList(Arrays.asList(new String[] {
     avrBasePath + "avr-gcc",
     "-c", // compile, don't link
     "-g", // include debugging info (so errors include line numbers)
     "-Os", // optimize for size
     Preferences.getBoolean("build.verbose") ? "-Wall" : "-w", // show warnings if verbose
     "-ffunction-sections", // place each function in its own section
     "-fdata-sections",
     "-mmcu=" + boardPreferences.get("build.mcu"),
     "-DF_CPU=" + boardPreferences.get("build.f_cpu"),
     "-MMD", // output dependancy info
     "-DARDUINO=" + Base.REVISION,
   }));

List baseCommandCompilerCPP = new ArrayList(Arrays.asList(new String[] {
     avrBasePath + "avr-g++",
     "-c", // compile, don't link
     "-g", // include debugging info (so errors include line numbers)
     "-Os", // optimize for size
     Preferences.getBoolean("build.verbose") ? "-Wall" : "-w", // show warnings if verbose
     "-fno-exceptions",
     "-ffunction-sections", // place each function in its own section
     "-fdata-sections",
     "-mmcu=" + boardPreferences.get("build.mcu"),
     "-DF_CPU=" + boardPreferences.get("build.f_cpu"),
     "-MMD", // output dependancy info
     "-DARDUINO=" + Base.REVISION,
   }));

Peut être modifier ceci et recréer l'archive core.jar (s'il est bien dans celui-ci) ?

23

Est-que utilisé l'IDE du arduino est une bonne option?

J'ai fait un programme que fais la même chose en C et a la langague du arduino.
en C j'ai 508 bytes contre 990 de l'IDE du arduino. Le .hex du programe fait en C
est tres plus petit.

24

pledoux:
Est-que utilisé l'IDE du arduino est une bonne option?

J'ai fait un programme que fais la même chose en C et a la langague du arduino.
en C j'ai 508 bytes contre 990 de l'IDE du arduino. Le .hex du programe fait en C
est tres plus petit.

L'ide arduino ajoute les tables de correspondance broches <> numéro qui font ~440 octets
508 + 440 = 948, + options d'optimisation ~= 990 ... le compte est bon.

Le core arduino, est (je le répète h24 :grin:) concu pour être facile d'utilisation, mais pas pour être optimisé !
Si on veut faire des choses optimisé il faut utiliser du c/c++ pure sans surcouche :wink:

@osaka:

Peut être modifier ceci et recréer l'archive core.jar (s'il est bien dans celui-ci) ?

Si tu compte recompiler le .jar de l'ide tu va galérer, crois moi j'ai essayé, entre la lib processing, rxtx, les trucs immondes dans le code ... et la nouvelle version de java 7 c'est une pure galère de faire un .jar identique à celui d'origine ...

Astuce: renomme avr-gcc et crée un fichier batch (.bat ou .sh sous linux) avec comme nom avr-gcc, l'ide appelera ton batch qui lui appelera ensuite le compilateur, mais tu pourra modifier les arguments au passage :wink:

25

L'IDE du Arduino et sa langague vraimment fais des choses plus facile quand on veux
utilisé autres dispositif attaché au controllateur comme le LCD, Ethernet etc.

Quand on veux faire une chose plus optimisé c'est a dire que on doit en faire en assembly.

L'architecture AVR a eté fait pour être simple pour le compilateur quand se traduire le code d'une
language de haut niveau au assembly. Donc je ne sais pas si il aura quelque grande difference
de optimisation entre ecrire en C ou Assembly.

.Le même n'est pas vrai sur le PIC. Donc le AVR n'ai pas
bensoin de beaucoup d'ajustation au compilateur comme le PIC. Donc le PIC a plusieurs compilateurs
commerciel pour optimisé ça. la vantage du PIC est que son assembly est tres simple, seulement 35
instrutions.

au fin la vantage rassemble d'etre bonne par l'AVR
http://embeddedgurus.com/stack-overflow/2009/12/hardware-costs-versus-development-costs/

26

en essayant de comprendre le bootloader, j'y ai lu ceci :

/* A bunch of if...else if... gives smaller code than switch...case ! */

ça peut être bon à savoir...

27

skywodd:
L'ide arduino ajoute les tables de correspondance broches <> numéro qui font ~440 octets
508 + 440 = 948, + options d'optimisation ~= 990 ... le compte est bon.

Je viens de faire un test en virant tout, j'ai d'abord commencé par tout ce qui était lié à cette correspondance donc pins_arduino et ses tableaux en progmem et tout ce qui en découle , rien ne change toujours 450 octets minimum (d'un côté c'est normal si aucun appel n'est fait à ceux ci :sweat_smile:).
La première chose qui m'a permis de diminué cette taille à été la méthode init() (celle appelé avant tout autre chose) dans wiring , 170 octets en moins (mais reste obligatoire au bon fonctionnement si je comprend bien ?).
Après j'ai supprimer l'intégralité même l'appel de setup et loop reste 178 octets (510 pour la mega) de je ne sais où , il n'y a plus que l'include de WProgram.h obligatoire par l'ide apparemment mais qui a été vidé intégralement également.
Enfin tout ça n'a peut être rien à voir, comme je suis pas un pro du microcontroleur. XD

skywodd:
Si tu compte recompiler le .jar de l'ide tu va galérer, crois moi j'ai essayé, entre la lib processing, rxtx, les trucs immondes dans le code ... et la nouvelle version de java 7 c'est une pure galère de faire un .jar identique à celui d'origine ...

J'ai regardé un coup dans l'archive (pde.jar) pour voir le manifet et rien de spécial il est vide, normalement juste compilé la classe concernée et reconstruire l'archive devrait suffire ?
Par contre oui le code il faut s'amuser et ce balader un peux partout pour retrouvé ses jeunes, si on veux une modif en profondeur (modifications de méthodes de classes) c'est pas gagné :~

skywodd:
Astuce: renomme avr-gcc et crée un fichier batch (.bat ou .sh sous linux) avec comme nom avr-gcc, l'ide appelera ton batch qui lui appelera ensuite le compilateur, mais tu pourra modifier les arguments au passage :wink:

Pas bête, j'y avais pas pensé, enfin le jours ou j'aurais besoin de le faire c'est que je me passerai de l'ide arduino également. :grin:

Super_Cinci:
en essayant de comprendre le bootloader, j'y ai lu ceci :

/* A bunch of if...else if... gives smaller code than switch...case ! */

ça peut être bon à savoir...

Je sais plus qui avait fais le test une fois il n'y a pas si longtemps et la différence n'était pas énorme il me semble ou c'était niveau process je sais plus ?

28

En l'occurrence il s'agit d'une série de if .. else if avec des dizaines de cas, et comme c'est le bootloader ils en sont vraiment à l'octet près en termes de taille du programme :slight_smile:

29

Mais justement, c'est plutôt étonnant qu'un...

if(){
  } else if() {
  } else if() {
  } else if() {
  } else if() {
  } else {
}

soit mieux encodé qu'un...

switch(){
  case ...:
    break;
  case ...:
    break;
  case ...:
    break;
  case ...:
    break;
  default:
    break;
}

puisqu'ils font exactement la même chose à part que dans le else if, on peut faire des tests complètement indépendants, alors que dans un switch(), on teste toujours la même variable, et pas besoin de recharger un registre avec la valeur à comparer (le switch devrait donc être plus léger. C'est un peu hors de bon sens à mon avis, d'où l'utilité de faire de l'assembleur dans un code où l'optimisation est nécessaire au plus haut point.