<=<=<=<=

4

Entre BASIC et Assembleur, le C Between BASIC and machine code: The C
Le langage C est parfois appelé "assembleur de haut niveau". En effet, grâce aux pointeurs et a sa gestion particulière des chaînes de caractère et des tableaux, le C se révèle être un langage efficace après compilation. The C language is sometime called "high level assembly language". Indeed, thanks to it's pointers, array and string handling, the C is a very efficient compiled language.
Origine du compilateur C pour Oric The Oric C Compiler: The origins
Grâce à plusieurs personnes (je pense en particulier à Alexios, Fabrice, et tous les autres qui y on contribué), il est maintenant possible d'écrire des programmes en langage C pour votre Oric. J'expliquerais un peu plus loin comment installer ce kit de développement en C, et comment l'utiliser.

Le compilateur est disponible en deux versions. Une des versions génère du code 32 bits et permet donc d'utiliser les types long et float, tandis que l'autre version, qui génère du code 16 bits ne va pas au delà du "int" 16 bits, et n'offre pas de support pour le code en virgule flottante. Je ne conseille pas la première versions pour d'évidentes raisons de performances. Si vous avez vraiment besoin d'effectuer des calculs en virgule flottante, il vaut mieux le faire soit même depuis un module assembleur en appelant les routines disponibles en ROM.
Thanks to many people (I'm think about Alexios, Fabrice and the others) it's now possible to code in C on the Oric. I will explain later how to install the Oric C development kit, and how to use it (Yes, really :).

This C is available in two versions. One is using a 32 bits library, and the other is a 16 bits only version.
My advice is to forget the 32 bits version. You really don't need long and float variables in your code. If you really need these, just copy the routines from the lib32, and call them in an 6502 module.
So, we will talk only about the 16bits version of the C-DevKit.
Le Kit de Developement Logiciel pour Oric The Oric Software Development Kit
Suite à un certain nombre de problèmes (incompatibilité entre les syntaxes des différents assembleurs, problèmes de compilation ou d'assemblage, incompatibilité avec certaines version de Windows, etc...) le kit original a été modifié.

La principale différence à été de remplacer FRASM (Frankenstein Macro Assembleur) par XA. Cet assembleur est beaucoup plus utilisé, notamment par les personnes codant sur C64. Accessoirement XA est disponible avec son code source C ce qui permet de faire des modifications quand cela s'avère nécessaire. Quand au fonctionnalités, XA offre la notion de symbole locaux, des directives de type préprocesseur, etc...
La seconde modification consiste en la suppression du programme principal chargé de lancer les différents morceaux de la compilation. Cette partie à été remplacée par un simple fichier BAT chargé de lancer les différents morceaux du kit.
Since we've got some problems with the original development kit (syntax incompatibility, code generation/assembling problems, windows incompatibilities, and so on), we've been obliged to modify the original development kit.

The main difference was to replace FRASM (Frankenstein Macro Assembler) by XA. This assembler is more often used, for instance by people working on C64. XA is also available with complete source code so it's possible to make modification when required. Finally it offers more functionalities like local symbols and pre-processing commands...
The second modification was to suppress the main driver that was responsible for launching all other part of the SDK. This part has been replaced by a simple BAT file launching each part.
Equipement nécessaire Hardware and software requirement
Pour utiliser le C, vous aurez besoin d'un PC. Pour pouvoir tester dans de bonnes conditions, il est aussi intéressant d'utiliser un émulateur.
Avec Euphoric et le compilateur C, vous pouvez faire une modification, compiler, lancer, tester et quitter le programme en moins de 5 secondes !
Avec un simple éditeur de texte et quelques scripts cela devient une opération simple, rapide et efficace.
For using the C, you will need a PC. And it's a good idea to use an emulator too.
With Euphoric and the C compiler, you can modify, build, run, test and quit in less than 5 seconds.
Just use your standard text editor, all your batch files... it's easy, fast, efficient.
Les problèmes... The troubles...
En fait, le seul problème avec le compilateur C, c'est qu'il génère une code qui est tout sauf efficace.
De ma propre expérience, on peut évaluer (selon le type de code) que le passage en assembleur donne une augmentation de performance allant de x4 à x16 par rapport au code généré par le compilateur !

Pour comprendre la raison de ce problème, il faut comprendre le processus de compilation:

  • D'abord, le code est traité par le pré-processeur du GNU C (c'est normal, rien de spécial là dedans).
  • Après, le code C résultant est compilé par CC65 qui le transforme en un nouveau fichier constitué d'instructions pour un processeur imaginaire.
  • Ce fichier est ensuite retraité par le pré-processeur qui remplacement chaque instruction par l'équivalent 6502 grâce à un ensemble de macros.

Indeed, the only real problem with this C compiler is that it generate a less than efficient code.
From personal experience, it can be evaluated (depending of the kind of code) than converting the code to pure assembly will give a speed up of between 4 to 16 times compared to the code generated by the compiler !

For understanding why, you have to understand the whole compilation process:

  • First, your C code is pre-processed with the GNU C pre-processor (it's normal, nothing special in that).
  • After that, the new C code is compiled with the C compiler that generates a new file in a special MACRO format.
  • This file is then reprocessed in order to replace each instruction in it's equivalent 6502 sequence using a set of macros.
macros.h


	#define ENTER(r,n)\  
		ldx #n ;\ 
		lda #r ;\ 
		jsr enter ;\ 

	#define RETW_A(ptr1,y1)\ 
		clc ;\ 
		lda 0+ptr1 ;\ 
		adc #y1 ;\ 
		tax ;\ 
		lda 1+ptr1 ;\ 
		adc #0 ;\ 
		rts ;\ 

Et hop ! C'est magique, vous avez maintenant du code assembleur 6502 à la place de votre code C !!!

Si vous avez plusieurs modules écrit en C, la même opération sera répété ce qui vous donnera autant de petits modules assembleurs qu'il faudra rassembler en une seule pièce.
And hop ! It's magic... now you have assembly language in place of your C code !!!

If you have many different C source code, the same operation is repeated again and again, and so you have plenty of little assembly source code that need to be put together...
La phase de link The linking phase
Le linker lui se contente de mettre bout à bout tous les morceaux de code ensemble, puis il recherche tous les symboles manquants.

Si un symbole (label, appel de fonction) n'est pas localisé dans vos sources, c'est soit une erreur, soit un appel à une fonction de la librairie.
Le linker va donc rechercher dans le fichier library.ndx qui contient la liste de tous les fichiers constituant la librairie, avec pour chaque fichier la liste de chaque fonction où symbole présent dans le fichier en question. Si le symbole recherché est localisé, le fichier librairie correspondant est alors rajouté aux autres fichiers composants le programme (ce qui ne pose pas de problème vu que la librairie est écrite directement en code source 6502).

Le linker continue cette opération pour chaque symbole manquant. Si il ne parvient pas à trouver un symbole, il signale une erreur et arrête l'opération.
Dans le cas contraire, le répertoire tmp contient un fichier linked.s prêt à être assemblé.
The linker just put all generated assembly code together... eventually add your own assembly sources, and looks for unknown symbols.

If a symbol (label, function call) is not found in your source, it's certainly a library call.
So, the linker looks in the file library.ndx that contains the list of the library source file, with the name of each public function/label. If found, it adds the corresponding source file (it's not precompiled, it's pure 6502 assembly source code, easy to modify for your own purpose) to the other files, until all labels be found.
If a label is not found, the linker sends you an error.

Now, (supposing that you have no errors in the code, and that all external references have been resolved), you have a final big assembly source code called linked.s that represents all your program stuff.
We have to assemble that source to have an executable binary file.
L'assembleur, l'étape quasi finale... Assembly, the nearly final stage...
Maintenant, c'est au tour de XA (l'assembleur) de prendre le gros fichier et de le transformer en un fichier binaire appelé FINAL.OUT qui ne contient aucune information de chargement ou relocation.

Un des principaux choix à ce stade est de déterminer l'adresse d'assemblage. Il faudra ensuite rajouter un en-tête si l'on veut un fichier cassette chargeable avec une simple commande CLOAD "OSDK.TAP". Le fichier OSDK.TAP est créé par le programme 'HEADER.EXE' à partir de 'FINAL.OUT'.

C'est fini !!!
Now, XA (our assembler) will assemble the big file into a single header less binary file called 'FINAL.OUT'.
Ok, we now reach the end of the compilation as we have a good binary code. But it's not Oric compatible for the moment ! We have to add some information (header) that will allow us to load that stuff with a good old CLOAD "OSDK.TAP" command...
This file (OSDK.TAP) is created by a program called 'HEADER.EXE' that will create the final executable code by appending a header to the 'FINAL.OUT' file.

It's finished !!!
SOS !!!Contact...Informations...