Lettre à Monsieur Doucet

JKB a écrit :

Lorsque tu as programmé des trucs temps réel sur des 6809, tu
utilisais en _même_ temps U et S (le pendant de SSP et USP).

Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres. En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.

Sur le 68K, c'est impossible. Par ailleurs, le U du 6809 ne
deviendra jamais S.

Et pour cause : ils n'ont pas du tout le même rôle.

Sur le 68K, USP et SSP sont deux pointeurs de piles
susceptibles d'être modifiés par le processeur. Ça fait une sacrée
différence.

USP et SSP sont à tour de rôle le pointeur de pile système en fonction
de l'état du bit S du registre d'état, ce qui n'est pas le cas de U.

C'étaient des processeurs sympa tous les deux, je trouve. Le 68000
apportait un confort appréciable par le nombre et la taille des
registres disponibles par rapport au 6809 (et même par rapport au x86).
Un des trucs les plus pénibles du 68000 c'était pour moi l'alignement
obligatoire des mots et mots longs sur les adresses paires et le bus de
données sur 16 bits obligatoire. Je crois que des versions ultérieures
(68020 ?) y ont remédié.

debug this fifo a écrit :

de memoire aussi, c'est plutot qu'il y avait deux a7 en // selon le
mode user ou supervisor. mais beaucoup de compilos et/ou runtime
se reservaient l'usage exclusif de a6. c'est loin, tout ça.

Exact, le cross-compilateur C pour 68000 sur HP-UX que j'utilisais se
servait du registre d'adresse A6 comme les compilateurs C pour x86 se
servaient du pointeur de base BP, pour repérer la position dans la pile
des paramètres et variables locales de la fonction en cours d'exécution
si je ne m'abuse.

Le 29-01-2010, ? propos de
6809 et 68000 (was: swap en RAM),
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :

JKB a écrit :

Lorsque tu as programmé des trucs temps réel sur des 6809, tu
utilisais en _même_ temps U et S (le pendant de SSP et USP).

Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres.

C'est exactement ce que je dis plus loin.

En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.

On peut tout remplacer par des fonctions, c'est un fait. N'empêche
que pour faire du temps réel, c'était très pratique.

Sur le 68K, c'est impossible. Par ailleurs, le U du 6809 ne
deviendra jamais S.

Et pour cause : ils n'ont pas du tout le même rôle.

Je sais.

Sur le 68K, USP et SSP sont deux pointeurs de piles
susceptibles d'être modifiés par le processeur. Ça fait une sacrée
différence.

USP et SSP sont à tour de rôle le pointeur de pile système en fonction
de l'état du bit S du registre d'état, ce qui n'est pas le cas de U.

C'étaient des processeurs sympa tous les deux, je trouve. Le 68000
apportait un confort appréciable par le nombre et la taille des
registres disponibles par rapport au 6809 (et même par rapport au x86).
Un des trucs les plus pénibles du 68000 c'était pour moi l'alignement
obligatoire des mots et mots longs sur les adresses paires et le bus de
données sur 16 bits obligatoire. Je crois que des versions ultérieures
(68020 ?) y ont remédié.

Le truc pénible, c'était le bus 16 bits externe avec une validation
différente des octets bas et haut et toute la logique câblé qu'il
fallait mettre autour. Si encore ça permettait d'utiliser des
mémoire 8 bits, mais même pas ! La gestion du bus du 68K était une
catastrophe avec des timings assez tordus.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Pascal Hambourg écrivait dans fr.comp.os.linux.configuration :

Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres.

C'est exactement ce que je dis plus loin.

Tu noteras que j'avais écrit "comme tu le dis".

En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.

On peut tout remplacer par des fonctions, c'est un fait. N'empêche
que pour faire du temps réel, c'était très pratique.

Pas par des fonctions mais par une simple instruction de déplacement
multiple MOVEM qui fait la même chose que les instructions
d'empilage-dépilage de registres du 6809 et peut utiliser n'importe quel
registre d'adresse comme pointeur. Donc je ne vois pas ce que tu
reproches au 68000, pourrais-tu donner un exemple concret de ce que tu
faisais avec le 6809 qui était impossible avec le 68000 ?

Un des trucs les plus pénibles du 68000 c'était pour moi l'alignement
obligatoire des mots et mots longs sur les adresses paires et le bus de
données sur 16 bits obligatoire.

Le truc pénible, c'était le bus 16 bits externe avec une validation
différente des octets bas et haut et toute la logique câblé qu'il
fallait mettre autour. Si encore ça permettait d'utiliser des
mémoire 8 bits, mais même pas !

C'est ce que je disais : bus de données de largeur fixe et non dynamique
en fonction de la cible. Au point que Motorola avait dû ajouter une
instruction de déplacement particulière MOVEP pour accéder par mot ou
mot long aux mémoires et périphériques 8 bits qui n'étaient adressés
qu'à des adresses paires ou impaires selon qu'ils étaient câblés sur les
8 bits de poids fort ou de poids faible du bus de données.

La gestion du bus du 68K était une
catastrophe avec des timings assez tordus.

Je suis d'accord, autant la gestion du bus du 6809 était simple, autant
celle du 68000 était une gigantesque usine à gaz. C'est le prix à payer
pour la richesse des fonctionnalités, je suppose.

Le 30-01-2010, ? propos de
Re: 6809 et 68000,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :

JKB a écrit :

Pascal Hambourg écrivait dans fr.comp.os.linux.configuration :

Dans mon souvenir, le registre U du 6809 n'est pas le pendant du
registre USP du 68000. U est le pointeur de pile "utilisateur" au sens
où comme tu le dis l'utilisateur peut en faire ce qu'il veut, comme les
registres d'index X et Y mais avec en plus le support des instructions
PSH et PUL pour empiler/dépiler le contenu de registres.

C'est exactement ce que je dis plus loin.

Tu noteras que j'avais écrit "comme tu le dis".

En revanche USP
est le pointeur de pile utilisateur au sens où c'est le pointeur de pile
système SP (utilisé pour les appels de sous-programme, comme le registre
S du 6809) actif lorsque le processeur est en mode utilisateur, par
opposition à SSP qui est le pointeur de pile système SP actif lorsque le
processeur est en mode superviseur. Si tu as besoin de l'équivalent de U
sur 68000, tu peux utiliser un registre d'adresse An quelconque autre
que A7 et les instructions PSH et PUL du 6809 peuvent être remplacées
par l'instruction MOVEM du 68000.

On peut tout remplacer par des fonctions, c'est un fait. N'empêche
que pour faire du temps réel, c'était très pratique.

Pas par des fonctions mais par une simple instruction de déplacement
multiple MOVEM qui fait la même chose que les instructions
d'empilage-dépilage de registres du 6809 et peut utiliser n'importe quel
registre d'adresse comme pointeur. Donc je ne vois pas ce que tu
reproches au 68000, pourrais-tu donner un exemple concret de ce que tu
faisais avec le 6809 qui était impossible avec le 68000 ?

J'ai fait un module de codeur de Reed-Muller (1,6) pour une
application spatiale. Le truc tournait avec quatre tâches :
réception, codage, décodage, envoi (full duplex). Les quatre tâches
étaient symchronisées par un timer externe connecté sur une patte
d'interruption. Je dois avoir le listing du truc quelque part à la
cave si je cherche (j'ai toujours la maquette). Le développement
s'est fait avec deux maquettes (wrapping), l'une à base de 68B09P et
l'autre de 68K/16 MHz en DIL. Je me souviens que le 6809 faisait les pieds
au mur alors que le 68K était à la ramasse à chaque changement de
tâche et que le problème venait de l'absence du U qui permettait de
gérer de façon efficace et élegante ces changements de tâche. C'est
un truc que j'ai fait il y a plus de quinze et j'ai un peu oublié
les détails. L'application finale a été faite sur le 6809 entre
autre pour cette raison (mais aussi pour la rapidité de traitement
et la simplicité).

Un des trucs les plus pénibles du 68000 c'était pour moi l'alignement
obligatoire des mots et mots longs sur les adresses paires et le bus de
données sur 16 bits obligatoire.

Le truc pénible, c'était le bus 16 bits externe avec une validation
différente des octets bas et haut et toute la logique câblé qu'il
fallait mettre autour. Si encore ça permettait d'utiliser des
mémoire 8 bits, mais même pas !

C'est ce que je disais : bus de données de largeur fixe et non dynamique
en fonction de la cible. Au point que Motorola avait dû ajouter une
instruction de déplacement particulière MOVEP pour accéder par mot ou
mot long aux mémoires et périphériques 8 bits qui n'étaient adressés
qu'à des adresses paires ou impaires selon qu'ils étaient câblés sur les
8 bits de poids fort ou de poids faible du bus de données.

La gestion du bus du 68K était une
catastrophe avec des timings assez tordus.

Je suis d'accord, autant la gestion du bus du 6809 était simple, autant
celle du 68000 était une gigantesque usine à gaz. C'est le prix à payer
pour la richesse des fonctionnalités, je suppose.

Non. C'est le prix à payer pour du bricolage. Si tu as des
validations de bus haut et bas, ce n'est pas pour adresser des
périphériques 8 bits, mais parce que le design interne du processeur
faisait que tu n'avais pas les données présentes en même temps. Ce
qui foutait assez rapidement la merdre lorsque tu avais sous la main
une mémoire 16 bits.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

J'ai fait un module de codeur de Reed-Muller (1,6) pour une
application spatiale. Le truc tournait avec quatre tâches :
réception, codage, décodage, envoi (full duplex). Les quatre tâches
étaient symchronisées par un timer externe connecté sur une patte
d'interruption. Je dois avoir le listing du truc quelque part à la
cave si je cherche (j'ai toujours la maquette). Le développement
s'est fait avec deux maquettes (wrapping), l'une à base de 68B09P et
l'autre de 68K/16 MHz en DIL.

Un système à base de 68000 en wrapping ? Tu as dû sacrément t'amuser...

Je me souviens que le 6809 faisait les pieds
au mur alors que le 68K était à la ramasse à chaque changement de
tâche et que le problème venait de l'absence du U qui permettait de
gérer de façon efficace et élegante ces changements de tâche. C'est
un truc que j'ai fait il y a plus de quinze et j'ai un peu oublié
les détails.

Dommage, j'aurais aimé avoir plus de détails sur la façon dont tu avais
géré le changement de tâche sur les deux processeurs pour comprendre.
Mais je ne vais pas te faire chercher, sauf si tu n'as vraiment rien de
mieux à faire.

Non. C'est le prix à payer pour du bricolage. Si tu as des
validations de bus haut et bas, ce n'est pas pour adresser des
périphériques 8 bits, mais parce que le design interne du processeur
faisait que tu n'avais pas les données présentes en même temps. Ce
qui foutait assez rapidement la merdre lorsque tu avais sous la main
une mémoire 16 bits.

Je ne suis pas sûr de comprendre ce que tu veux dire. Avec une mémoire
ou un périphérique ne supportant que des accès entiers sur 16 bits,
l'utilisation d'instructions sur octet pouvait effectivement avoir des
conséquences aléatoires (surtout en écriture). Par contre je ne me
rappelle pas de situations où les signaux de validation haut et bas
n'étaient pas synchrones.

Le 30-01-2010, ? propos de
Re: 6809 et 68000,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :

JKB a écrit :

J'ai fait un module de codeur de Reed-Muller (1,6) pour une
application spatiale. Le truc tournait avec quatre tâches :
réception, codage, décodage, envoi (full duplex). Les quatre tâches
étaient symchronisées par un timer externe connecté sur une patte
d'interruption. Je dois avoir le listing du truc quelque part à la
cave si je cherche (j'ai toujours la maquette). Le développement
s'est fait avec deux maquettes (wrapping), l'une à base de 68B09P et
l'autre de 68K/16 MHz en DIL.

Un système à base de 68000 en wrapping ? Tu as dû sacrément t'amuser...

Ouaips. La carte était un peu plus grande qu'un format A4, avec
toute une palanquée et demi de 74xx pour gérer le bus (et de drivers
de bus parce que la puissance sortante du 68K n'était pas assez
grande pour gérer les composants de gestion du bus !).

Côté 6809, il y avait un 6809, un 6840, un 6850, une mémoire RAM de 2Ko,
une PROM de 8, un 74138 et un registre à décalage 8 bits, des
résistances, condensateurs, une horloge TTL 8MHz et c'est à peu près
tout...

Je me souviens que le 6809 faisait les pieds
au mur alors que le 68K était à la ramasse à chaque changement de
tâche et que le problème venait de l'absence du U qui permettait de
gérer de façon efficace et élegante ces changements de tâche. C'est
un truc que j'ai fait il y a plus de quinze et j'ai un peu oublié
les détails.

Dommage, j'aurais aimé avoir plus de détails sur la façon dont tu avais
géré le changement de tâche sur les deux processeurs pour comprendre.
Mais je ne vais pas te faire chercher, sauf si tu n'as vraiment rien de
mieux à faire.

Je vais mettre ça dans ma todo list. Je ne garantis rien.

Non. C'est le prix à payer pour du bricolage. Si tu as des
validations de bus haut et bas, ce n'est pas pour adresser des
périphériques 8 bits, mais parce que le design interne du processeur
faisait que tu n'avais pas les données présentes en même temps. Ce
qui foutait assez rapidement la merdre lorsque tu avais sous la main
une mémoire 16 bits.

Je ne suis pas sûr de comprendre ce que tu veux dire. Avec une mémoire
ou un périphérique ne supportant que des accès entiers sur 16 bits,
l'utilisation d'instructions sur octet pouvait effectivement avoir des
conséquences aléatoires (surtout en écriture). Par contre je ne me
rappelle pas de situations où les signaux de validation haut et bas
n'étaient pas synchrones.

Le problème est qu'on avait à l'époque (je ne sais pas si ça a
évolué depuis puisque je n'ai plus été confronté au problème) des
périphériques (incluant la mémoire) à seize bits, mais avec un
signal de validation pour tout le bus. Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique ! Bref, c'était jouable lorsque tu utilisais
des périphériques 8 bits ou deux mémoires 8 bits en parallèle, mais
c'était indémerdable dès que tu utilisais un CAN 12 bits (par
exemple).

Quant à adresser des périphériques 8 bits sur un bus de 16, ça
n'avait aucune conséquence même en écriture (sauf à écrire un entier
de 8 bits sur un périphérique de 16) puisque le bus avait le bon
goût d'être à trois états.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Message de Dellara du mercredi 20 janvier 2010 - 21:52:36
dans le groupe fr.comp.os.linux.debats:

NiKo a papoté sur Usenet le janvier 19, 2010 06:33 PM:

.... Juste des URL pigées ....

Rien n'est moins sûr !

--
A+
Jack H.
"GnuPG c'est bon, mangez-en..."

JKB a écrit :

Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :

Un système à base de 68000 en wrapping ? Tu as dû sacrément t'amuser...

Ouaips. La carte était un peu plus grande qu'un format A4, avec
toute une palanquée et demi de 74xx pour gérer le bus (et de drivers
de bus parce que la puissance sortante du 68K n'était pas assez
grande pour gérer les composants de gestion du bus !).

En fait je n'ai utilisé le 68000 que dans une version microncontrôleur
68302 qui intégrait toute la tuyauterie nécessaire et nécessitait très
peu de logique additionnelle pour s'interfacer avec des circuits
externes. Ça doit être pour ça que j'en ai gardé un assez bon
souvenir... :-)

Côté 6809, il y avait un 6809, un 6840, un 6850, une mémoire RAM de 2Ko,
une PROM de 8, un 74138 et un registre à décalage 8 bits, des
résistances, condensateurs, une horloge TTL 8MHz et c'est à peu près
tout...

Du grand classique, y compris le 74138 comme décodeur d'adresses...
Le registre à décalage, c'était pour l'émission/réception des données ?

Le problème est qu'on avait à l'époque (je ne sais pas si ça a
évolué depuis puisque je n'ai plus été confronté au problème) des
périphériques (incluant la mémoire) à seize bits, mais avec un
signal de validation pour tout le bus.

C'est effectivement une situation à problème, qui interdit notamment
l'écriture sur 8 bits puisque ça écrirait n'importe quoi sur les 8 bits
restants.

Sur le 68K, tu as deux
signaux asynchrone de validation des deux octets du bus de données
et rien ne te garantit que les deux octets du bus soient validés en
_même_ temps. J'ai passé des jours à débugguer ce genre de problème
à l'analyseur logique !

Tu veux dire _exactement_ en même temps lors d'un accès 16 bits ? Parce
que d'après tous les chronogrammes que j'ai pu avoir sous les yeux, /UDS
et /LDS bougent en même temps. Mais c'est vrai que les signaux du bus du
68000 sont asynchrones au sens où ils ne sont pas référencés par rapport
à une horloge externe (ils le sont forcément en interne par rapport à
l'horloge CLK, mais les relations de timing par rapport à cette horloge
sont tout sauf évidentes à déterminer). Manifestement c'était prévu pour
piloter directement de la mémoire 8 bits asynchrone classique de
l'époque, mais pour le reste ce n'était pas un cadeau pour faire les
choses proprement comme on m'avait apris à l'école (machines synchrones
de Moore, toussa). D'où l'ajout des signaux /VPA et E pour piloter les
circuits périphériques à bus synchrone de la famille 6800 d'ailleurs.

Bref, c'était jouable lorsque tu utilisais
des périphériques 8 bits ou deux mémoires 8 bits en parallèle, mais
c'était indémerdable dès que tu utilisais un CAN 12 bits (par
exemple).

Te rappelles-tu quel était le problème exactement ?

Quant à adresser des périphériques 8 bits sur un bus de 16, ça
n'avait aucune conséquence même en écriture

Ça faisait quand même des trous dans l'adressage puisqu'un périphérique
8 bits était accessible à des adresses paires consécutives s'il était
connecté sur l'octet de poids fort du bus de données et à des adresses
impaires s'il était connecté sur l'octet de poids faible. Et pour
accéder efficacement à un registre 16 bits d'un périphérique 8 bits, il
fallait utiliser une instruction spéciale MOVEP qui tenait compte de
cette particularité.

Pascal Hambourg :

...

Z'avez pas l'impression d'être carrément hors charte là ?

(oui je sais je suis un vieux con)