Bonjour à tous,
Je travaille actuellement sur un compilo capable de générer du
code pour mon 63F09 (
https://63F09.systella.fr). Par effet de bord,
le compilateur génère aussi du code pour 6809 et 6309.
Le travail avance assez bien. J'ai commencé par débugguer
complètement l'assembleur A09 qui m'a servi de référence
et qui est téléchargeable ici
ftp://newton.systella.fr/ Les binutils sont quasiment stables. Les sources du CPU ne sont
pas à jour, il a fallu modifier le processeur pour éviter de
toucher au coeur de gcc, principalement en ce qui concerne la FPU.
Il ne s'agit pas ici d'une mise à jour de la vieillerie gcc6809
qui était bugguée et que je n'ai jamais réussi à faire fonctionner
correctement, mais un port entièrement nouveau.
Ce genre de chose compile parfaitement :
.text
leax e,x
leax f,x
leax w,x
leay e,y
leau f,u
leas w,s
/* Formes indirectes -- valides sur le matériel réel pour toute
forme par accumulateur, y compris E/F/W. */
leax [e,x]
leax [f,x]
leax [w,x]
et le code généré a été comparé octet par octet au code généré par
A09 (toutes les instructions et modes d'adressage ont été validées
une par une sur le matériel, donc A09 est la référence pour valider
les binutils).
Les outils compilant actuellement sont les suivants (gcc/binutils) :
hilbert:[~/cvs/gcc/build/bin] > ls
m6809-addr2line m6809-gcc-ar m6809-gprof m6809-ranlib
m6809-ar m6809-gcc-nm m6809-gstack m6809-readelf
m6809-as m6809-gcc-ranlib m6809-ld m6809-size
m6809-c++filt m6809-gcov m6809-ld.bfd m6809-strings
m6809-cpp m6809-gcov-dump m6809-lto-dump m6809-strip
m6809-elfedit m6809-gcov-tool m6809-nm
m6809-gcc m6809-gdb m6809-objcopy
m6809-gcc-16.2.0 m6809-gdb-add-index m6809-objdump
L'éditeur de lien possède plusieurs émulations :
- 6809 Flex9
- 6309 Flex9
- 6809 UniFLEX
- 6309 UniFLEX
- 63F09 bare metal
- 63F09 SoC.
Le résultat de la compilation de gcc avec l'édition des liens a été
comparé octet par octet à la version assemblée à la main. Résultat
conforme.
Le code suivant compile parfaitement et donne un résultat cohérent :
hilbert:[~/cvs/gcc/gcc-16.2.0/test] > cat struct_oddsize.c
struct five { unsigned char a, b, c, d, e; };
struct five make5(unsigned char a, unsigned char b, unsigned char c,
unsigned char d, unsigned char e)
{
struct five f;
f.a = a;
f.b = b;
f.c = c;
f.d = d;
f.e = e;
return f;
}
unsigned char sum5(struct five f)
{
return f.a + f.b + f.c + f.d + f.e;
}
struct nine { unsigned char bytes[9]; };
struct nine make9(unsigned char fill)
{
struct nine n;
short i;
for (i = 0; i < 9; i = i + 1)
n.bytes[i] = fill;
return n;
}
unsigned char first_byte(struct nine n)
{
return n.bytes[0];
}
struct padded { unsigned char tag; short value; };
short unwrap(struct padded p)
{
return p.value;
}
struct padded wrap(unsigned char tag, short value)
{
struct padded p;
p.tag = tag;
p.value = value;
return p;
}
Je vais générer les paquets binaires pour binutils si certains
d'entre vous veulent tester. gcc attendra encore un peu, il reste du
travail à faire dessus.
J'envisage aussi de lancer en fabrication des puces avec un 63F09 en
boîtier DIP40. Le 63F09 est un CPU écrit en VHDL qui est une
extension du 6809 (il suffit d'assembler le code 6809 avec l'option
-m63f09 pour avoir un code fonctionnel) avec une ALU de 64 bits (un
registre O) et une FPU 64 bits à 16 registres. Le bus d'adresse est
de 32 bits (36 en passant par sa MMU). Il démarre en mode
6809 et tourne jusqu'à 600 MHz. À cette vitesse, il n'essaie pas
d'accéder à la mémoire directement, il possède un cache L1 synchrone
à pleine vitesse de 64 Ko.
La version complète est une version à 8 CPU en mode SMP, une FPU
partagée (ou une FPU par CPU). Les tests montrent que 4 coeurs
et une FPU consomment 0,5 W à 600 MHz dans un Artix7.
À titre d'information, une division entière 32 bits/32 bits
nécessite 50 cycles. Une division flottante (simple ou double
précision) prend 17 cycles.
JB
Haut de la page
Les messages affichés proviennent d'usenet.
NewsPortal