AgDev
v3.1.0
L'Agon Light et les autres révisions de la plate-forme Agon sont basées sur le processeur Zilog eZ80. L'eZ80 dispose d'un espace d'adressage de 24 bits prenant en charge 16 mégaoctets de mémoire, contre 64 kilo-octets du Z80 d'origine. L'eZ80 dispose de deux modes de fonctionnement : le mode standard Z80, qui dispose de registres 16 bits permettant d'adresser facilement 64 ko de mémoire, mais nécessitant le recours au « banking » pour accéder à plus de 64 ko de mémoire ; et le mode de fonctionnement ADL (address data long), qui étend les registres à 24 bits, rendant ainsi l'ensemble de l'espace d'adressage facilement accessible.
Lorsque nous considérons les langages de programmation de haut niveau, il en existe un certain nombre pour le Z80, mais ils sont limités à 64 Ko de mémoire ou disposent de méthodes de changement de banque peu pratiques pour accéder à une plus grande mémoire.
Compte tenu des langages de programmation C, il existe un certain nombre de compilateurs C Z80 disponibles. À ce jour, la communauté Agon s’est concentrée sur deux :
Environnement de développement Zilog ZDS II capable de produire du code eZ80 ADL. Il s'agit de l'ensemble d'outils d'origine utilisé par les développeurs d'Agon, mais il est fermé, fonctionne uniquement sous Windows et ne prend en charge que la norme de données C89.
SDCC (compilateur C pour petits appareils) , un choix populaire pour les ordinateurs 8 bits, et son adaptation pour Agon a été une priorité pour un certain nombre de personnes dans l'ordinateur Agon. C'est un bon compilateur pour le Z80, mais il ne prend en charge que le Z80 et non le mode ADL.
Comme alternative, la chaîne d'outils CEdev C/C++ est un compilateur open source qui peut produire du code ADL. Il cible la calculatrice TI-84 Plus CE (basée sur le processeur eZ80) et dispose d'une communauté de taille raisonnable. CEdev est basé sur les versions eZ80 du compilateur LLVM et de l'assembleur fasmg. Il produit du code ADL avec des pointeurs de 24 bits, des entiers de 24 bits, des longs de 32 bits, des courts-circuits de 16 bits et des flottants de 32 bits. Il existe également une bibliothèque assez complète pour les programmes C et C++ (même si elle n'est pas encore conforme à la norme ISO...).
AgDev est le résultat d'un effort visant à modifier CEdev pour s'adapter à l'ensemble des fonctionnalités et à la conception matérielle de la plate-forme Agon. Le résultat est une chaîne d’outils plus puissante et compatible C++, par rapport aux autres options pour l’Agon.
Téléchargez vous-même une version de version ou une version à partir des sources. Placez la build dans un répertoire de votre choix.
Ensuite, assurez-vous que le dossier /bin se trouve dans PATH ; si vous êtes sous Windows, suivez ce guide, ou vous pouvez exécuter cedev.bat et exécuter des commandes à partir de là. Sous Linux, exécutez export PATH=/<insert path here>/bin:$PATH dans une fenêtre de terminal.
Cela suit la même approche que la chaîne d'outils CE d'origine (voir en bas de la page de démarrage de CEdev). Le processus de build avait été modifié pour s'arrêter à la génération du fichier .bin . Il s'agit de l'exécutable Agon Light.
Je recommande d'utiliser :
rendre propre faire V=1
La commande make clean peut être utilisée pour supprimer les résultats des compilations précédentes et ainsi forcer une recompilation.
Le processus de construction passe par les étapes suivantes :
Compilation de fichiers source .c en bitcode LLVM (.bc) à l'aide de ez80-clang
Liaison du bitcode LLVM à l'aide de ez80-link . Cela inclut l'optimisation du temps de liaison
Génération du code assembleur eZ80 (.src) pour les programmes sources à l'aide de ez80-clang
Assemblage et liaison du code assembleur généré (à partir de l'étape 3) avec les bibliothèques et le runtime du compilateur à l'aide de fasmg - cela inclut la construction de l'exécutable ciblé sur un emplacement mémoire spécifique. C'est la partie principale du processus de construction qui doit être ajustée.
Voir la note d'application Zilog "Appel de C depuis asm.pdf".
Seuls le registre et la pile IX doivent être conservés par les fonctions appelées.
Les arguments sont poussés du dernier au premier correspondant au prototype C. Dans eZ80, 3 octets sont toujours poussés vers la pile quelle que soit la taille réelle. Cependant, la fonction d'assemblage doit veiller à n'utiliser que les octets valides qui sont poussés. Par exemple, si un type court est utilisé, l'octet supérieur de la valeur placée sur la pile contiendra des données arbitraires. Ce tableau répertorie les emplacements relatifs à sp à partir de la fonction appelée. Notez que sp + [0,2] contient l'adresse de retour.
| Type C/C++ | Taille | Emplacement de la pile |
|---|---|---|
| carboniser | 1 octet | sp + [3] |
| court | 2 octets | sp + [3,4] |
| int | 3 octets | sp + [3,5] |
| long | 4 octets | sp + [3,6] |
| très longtemps | 8 octets | sp + [3,10] |
| flotter | 4 octets | sp + [3,6] |
| double | 4 octets | sp + [3,6] |
| aiguille | 3 octets | sp + [3,5] |
Notez que eZ80 est Little Endian - c'est-à-dire que l'octet de poids faible est stocké en premier.
Ce tableau répertorie les registres utilisés pour les valeurs de retour d'une fonction. Le signe du type n'affecte pas les registres utilisés, mais peut affecter la valeur renvoyée. Le LSB est situé dans le registre à l'extrême droite de l'expression, par exemple E:UHL indique que le registre L stocke le LSB.
| Type C/C++ | Registre des retours |
|---|---|
| carboniser | UN |
| court | HL |
| int | UHL |
| long | E: UHL |
| très longtemps | BC:UDE:UHL |
| flotter | E: UHL |
| double | E: UHL |
| aiguille | UHL |
Non conforme ISO !
Se compose des éléments suivants :
Fichier IO :
fopen() , freopen(), fclose()
fputc() , fputs()
fgetc() , ungetc() , fgets()
feof() , ferror() , fflush()
fread() , fwrite()
fseek() , rewind() , ftell()
clearerr()
remove()
Stdin / stdout IO :
putchar() , puts()
getchar() , gets_s()
Sortie formatée
printf() (et vprintf() )
sprintf() (et vsprintf() )
snprintf() (et vsnprintf() )
Entrée formatée
scanf()
sscanf()
Il y a d'autres éléments ici - comme stdint et autres - mais ils devraient principalement correspondre aux attentes de la bibliothèque standard normale. Surtout.
stdio Peut rediriger la sortie en utilisant freopen() sur stdout ou stderr :
putchar() - sort vers outchar() sauf si la sortie est redirigée, auquel cas sort vers fputc()
puts() - appelle putchar()
printf() (et vprintf() ) - appelle npf_putc_std() , qui appelle putchar() dans nanoprintf.c
fputc() - appelle mos_fputc() à moins qu'il ne soit appelé sur stdout lors de l'appel outchar() - évite d'appeler putchar() afin d'éviter tout risque de boucles d'appel de fonction
Peut rediriger l'entrée en utilisant freopen() sur stdin :
getchar() - appelle inchar() pour obtenir le caractère et outchar() pour faire écho au caractère (même si la sortie a été redirigée). Si la sortie n’a pas été redirigée, appelle fgetc() et ne fait pas écho au caractère.
gets_s() - appelle getchar() si l'entrée n'a pas été redirigée (les lignes se terminent par CR). Les appels fgets() de l'entrée ont été redirigés (les lignes se terminent par une paire CR/LF).
scanf() - appelle getchar() dans uscan.c (n'a pas besoin de mise à jour)
fgetc() - appelle mos_fgetc() à moins qu'il ne soit appelé sur stdin lors de l'appel inchar() et fait écho avec outchar() - évite d'appeler getchar() afin d'éviter tout risque de boucle d'appel de fonction
Nécessite FILE * , qui est un pointeur vers un descripteur de fichier renvoyé par fopen et transmis aux routines IO de fichier pour indiquer le fichier sur lequel l'action doit être effectuée.
Autres fichiers associés :
stdio.h - fichiers d'en-tête normaux, qui définissent les différentes fonctions et le typedef pour FILE
files.c - instancie le stockage des descripteurs de fichiers, notamment : stdout, stderr, stdin.
Les descripteurs de fichiers standard suivants sont définis :
stdout - sortie par défaut
stderr - sortie par défaut pour le message d'erreur
stdin - entrée par défaut
MOS n'implémente pas la redirection d'entrée/sortie, donc par défaut, ils utilisent tous la console.
Deux options sont disponibles pour le traitement en ligne de commande.
Ceci est automatiquement inclus si la fonction principale est définie comme
int main( int argc, char* argv[] )
cela divise la ligne de commande en utilisant l'espace comme délimiteur. Les options de ligne de commande sont disponibles dans le tableau argv[] comme d'habitude.
Ceci est éventuellement inclus si le makefile de l'application comprend :
LDHAS_ARG_PROCESSING = 1
Cela prend en charge
Citer avec des guillemets doubles
Redirection entrée/sortie
>out_file.txt - redirige la sortie standard vers out_file.txt , créant ainsi un nouveau fichier
>>out_file.txt - redirige la sortie standard vers out_file.txt , en l'ajoutant à la fin du fichier
<in_file.txt - redirige stdin vers in_file.txt
Pour obtenir la documentation actuelle sur les commandes MOS, consultez la documentation Agon Console8.
Le MOS (système d'exploitation machine) fournit une interface avec le système de fichiers Agon et certains périphériques matériels, comme la souris. Il conserve les informations sur les variables système dans une grande structure SYSVAR accessible du côté du Z80. Généralement votre code C déclarera un pointeur vers cette structure, initialisé comme ceci :
statique volatile SYSVAR* sv ; sv = vdp_vdu_init();
Pour plus d'informations, consultez <mos_api.h> .
Pour obtenir la documentation actuelle sur les commandes VDU, consultez la documentation Agon Console8.
Le VDP (Video Display Processor) accepte un flux de texte provenant de MOS, agissant comme un terminal texte/graphique. Le flux de texte peut contenir :
Texte normal
Séquences/commandes d'échappement pour contrôler l'affichage et envoyer des commandes graphiques/son/etc.
Lorsque les résultats sont renvoyés par MOS à la suite de l'envoi d'une commande, ils sont stockés dans les SYSVAR et ne sont pas renvoyés directement en réponse à la commande. La réponse est asynchrone - pour vérifier qu'un résultat a été renvoyé :
Définir vdp_pflags dans SYSVAR sur zéro
Émettez la commande VDU
Attendez que le bit correspondant dans vdp_pflags soit défini - voir <mos_api.h> pour les masques de bits
Les commandes peuvent être envoyées par :
putch() - caractère unique (cela ne fait pas partie de la bibliothèque standard C)
mos_puts() - chaîne à plusieurs caractères
Ces deux fichiers sortent directement vers MOS/VDP - notez qu'ils ne font pas partie de la bibliothèque STDIO et ne sont pas soumis à la traduction ou à la redirection CR/LF.
Des fonctions pratiques pour de nombreuses commandes VDU sont fournies dans AgDev. Par exemple, pour changer le MODE d'écran en 3, le C appelle vdp_mode(3); enverra 22,3 sous forme d'octets simples à la sortie, équivalent à putch(22); putch(3); Pour une liste de ces fonctions, voir <vdp_vdu.h> . Des fonctions supplémentaires liées à la gestion du clavier se trouvent dans <vdp_key.h> .
