yasep/docs/assembly_fr.html version 2009-09-02 Retour à la page d'accueil

version anglaise :

Le langage assembleur du YASEP

Introduction

Cette page décrit l'assembleur du YASEP (c'est à dire le programme qui transforme les instructions en code binaire) ainsi que les conventions de langage (la syntaxe) permettant d'écrire un logiciel pour le YASEP. Pour obtenir des informations sur une instruction en particulier, consultez la carte des opcodes et les pages du manuel du jeu d'instruction.

Cette page couvre les points suivants :

• L'encodeur d'instruction
• Comment écrire des nombres
• Les pseudo-instructions (comme DB, DH, DW ou YASEP)
• Les mots-clés réservés
• Les alias d'instructions
• Les flags
• Les valeurs par défaut

Organisation

L'assembleur du YASEP est constitué de deux couches :

Les instructions du YASEP sont simples mais elles ne sont pas toujours pratiques, alors certains opcodes ont besoin de modifications mineures. Ce sont souvent des dérogations mineures aux règles de codage, qui sont indiquées par des flags (des propriétés de chaque opcode).

L'assembleur tient compte de ces flags pour transformer le texte en code binaire, afin de garder les instructions utilisables, lisibles et cohérentes, indépendamment de leur encodage réel, des exceptions d'encodage ou de l'architecture du processeur.

• Règle 0 : L'opcode est le premier mot de l'instruction.
• Règle 1 : L'adresse du registre destination est située après les opérandes sources, habituellement à la fin de l'instruction.
• Règle 2 : Généralement, la donnée immédiate est située juste après l'opcode, avant les autres opérandes (sauf lorsqu'il faut obéir à la règle n°1, avec les FORM_Ri et FORM_RI).
• Rule 3 : Le code de condition (si présent) est à la fin de l'instruction, après le registre de destination.

Assemblage d'une instruction

• La routine d'assemblage attend une seule ligne, c'est à dire une chaine de caractères sans code de "retour à la ligne" (comme '\n' ou '\r').
• La ligne peut se terminer par un commentaire qui commence avec ';'. A partir de ce délimiteur, tout les caractères sont éliminés.
• Les espaces de début et de fin sont supprimés, les virgules et les tabulations sont remplacées par des espaces, et les espaces consécutifs sont fusionnés. Vous êtes libres d'ecrire add 234 d2 r3, add 234, d2 r3 ou même add  234, d2,    , r3
• L'ensemble de la ligne est convertie en majuscules. Donc peu importe si vous écrivez adD 234h D2 r3 ou ADd 234h d2 R3 parce qu'en interne ce sera transformé en ADD 234H D2 R3.
• Le premier mot doit être l'opcode (règle n°0) donc celui-ci est analysé. Ses propriétés (flags et formes permises) sont obtenues en consultant les tables internes en JavaScript.
• Selon l'instruction, l'opcode est suivi par des noms de registres, des mots-clés et/ou des constantes. L'ordre de ces paramètres est comparé avec les "formes" permises, puis les opérande sont encodées dans les champs spécifiés par les flags.

Et c'est tout ce qu'il y a a dire au sujet de la "syntaxe".

• Hexadécimal ([0-9A-F]* avec un 'h' final), par exemple dw 1234h (les préfixes 0x ou $ ne sont jamais utilisés).
• Décimal ([0-9]* sans préfixe ni suffixe) : dw 1234. C'est le seul format qui accepte un signe moins comme préfixe : dw -1234
• Binaire ([01]* avec un 'b' terminal) : dw 01101101b

Les nombres sont souvent utilisés dans des contextes où le nombre de bits significatifs est limité par la taille du conteneur (habituellement, le champ immédiat). Quand tropo de bits sont écrits, l'assembleur conserve seulement le nombre desiré de bits de poid faible, et efface les bits de poids forts. L'exemple suivant montre comment le nombre est tronqué : db 1234h.

Note : le désassembleur écrit toujours les valeurs en hexadécimal.

• DB : "Data Byte"
      génère 8 bits : db 12h
• DH : "Data Half-word"
      génère 16 bits : dh 1234h
• DW : "Data Word"
      génère 32 bits : dw 12345678h

Un nombre ilimité de nombre litéraux est accepté (depuis le 4/04/2007 et la limite dépend du moteur JavaScript, pas du codage de l'assembleur). La fenêtre flottante de l'assembleur n'affichera pas tout les chiffres quand plus de 32 bits seront donnés mais ils seront disponibles dans d'autres logiciels, en definissant la fonction emit_bin() :

Exemple : db 12h 34h 56h 78h 9Ah BCh DEFh
Le résultat est envoyé à emit_bin() :

Il n'est pas encore possible d'écrire des chaînes ASCII à l'heure actuelle.

Since 2008-08, YASEP exists in 16-bit and 32-bit variants. The opcodes don't change but a few of them are pointless in 16-bit mode or 32-bit mode. The source code can specify that a certain width is used so a warning is issued when a pointless instruction (probably invalid for the given CPU) is assembled.

YASEP16 specifies that the targetted CPU has a 16-bit datapath. All 32-bit only instructions generate a warning.

YASEP32 specifies that the targetted CPU has a 32-bit datapath. All 16-bit only instructions generate a warning.

YASEP resets the target CPU to generic/undefined.

These pseudo-instructions don't generate any code and can be used in any order, as they simply control an internal flag. This flag is compared with each instruction's flag (see YASEP32_ONLY and YASEP16_ONLY below).

• Register names (NPC R0 R1 R2 R3 R4 A0 D0 A1 D1 A2 D2 A3 D3 A4 D4)
• Pseudo-instructions (DB DH DW YASEP16 YASEP32 YASEP)
• The condition codes (LSB0 LSB1 MSB0 MSB1 ZERO NZ)
• The instruction opcodes and the opcode aliases ()

There are two types of aliases : form aliases (see ALIAS_RR) and instruction aliases (they are listed under the opcode map). This section is about instruction aliases.

Internally, they can be used like normal instructions, but they provide different forms and/or different semantics. However, they use real opcodes of other instructions. The substitution is handled at the assembly level and the disassembly probably won't infer the originally assembled alias. So don't be surprised if instructions like NOT or NEG assemble correctly, but the disassembly returns a different opcode.

The various instructions forms are described in the instructions_fr.html page.

The flags have their own page too.

However, when certain instruction fields are not used (by FORM_ALONE or FORM_R...), these fields could be set to values chosen by the assembler, for the purpose of power reduction.

Toggle minimization and toggle spacing could help reduce the power consumption and EMI emissions. The YASEP assembler will be able to compute proper values rather easily. Padding Imm16s and NOPs can be enhanced this way, too. The possible reduction is quite low, but maybe could reach 5% when fetching instructions from external SDRAM ? Gotta try with and without, and even when EMI/toggles are maximized, just for testing it.