Bug du 68000 corrigé par le 68020 ? - Page 1

En discutant hier avec un cousin, il m'a appris que le 68000 souffrait d'un bug qui a été ensuite corrigé dans le 68020. Il a développé pour 68000 pour je ne sais plus quel Airbus.

De quel bug s'agit-il ? Au niveau des interruptions peut-être ? J'ai été épaté, je n'ai pas souvenir d'en avoir entendu parler ici.

Les seuls "bugs" que je connaisse sont :

- sur certaines versions du 68000, l'instruction CLR appliquée à une adresse mémoire fait un accès en lecture avant l'accès en écriture, ce qui peut poser problème pour les accès I/O mappés en mémoire (mentionné dans ce document, et aussi dans la doc de la console Atari Jaguar)

- les instructions de multiplication utiliseraient la pile comme espace de stockage temporaire (j'ai lu ça je sais plus où il y a longtemps, mais j'ai jamais testé si c'était vrai)

- j'ai vu une page (que je ne retrouve plus) qui mentionne des bugs liés au mode superviseur qui auraient été corrigés dans le 68010. Mais il est possible qu'ils parlent du fait que pour les exceptions comme "Address Error", le stack frame n'est pas complet (voir ici). Ça a changé par la suite.

Merci.

Le bug en question ça ne serait pas simplement le fait que MOVE from SR ne soit pas une instruction privilégiée ?

Tiens, effectivement, ce n'est pas privilégié sur 68000, mais ça l'est sur les processeurs suivants. Mais je ne vois pas vraiment en quoi ça peut poser problème : ça ne perturbe pas les programmes et ce n'est pas un trou de sécurité, non ?

Ici, ils mentionnent ce fait, et aussi le fait que les stack frames ne sont pas assez complets pour implémenter une mémoire virtuelle.

notre prof de système nous avait dit que ça posait problème pour les théories sur la virtualisation.

Oui, ils en parlent sur Wikipédia : http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements#Motorola_MC68000.

Mais je ne vois pas trop quel problème ça pose en pratique...

Le problème du clr est effectivement présent sur le 68000 des TIs.

Tiens, en relisant la doc de la Jaguar, ils mentionnent un autre problème pour le CLR : apparemment, pour un clr.l, l'ordre d'accès au mot bas/mot haut serait inversé par rapport aux autres instructions. Y'a des registres hardware 32 bits sur la TI ?

voila c'était popek et goldberg.

(je pense pas pour les registres 32bits)

Aucun des registres HW1 et HW2 (600000-60001F & 700000-70001F) n'est 32 bits. En revanche, il y a quelques registres 32 bits sur HW3+, voir les infos d'ExtendeD.

Zerosquare (./7) :
Oui, ils en parlent sur Wikipédia : http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements#Motorola_MC68000.

Mais je ne vois pas trop quel problème ça pose en pratique...

Je vois pas non plus car le seul truc qu'on peut faire c'est lire le SR, pas le modifier

Oui mais pouvoir le lire c'est déjà beaucoup. Tu peux certes pas modifier quoi que ce soit et altérer le fonctionnement du système (enfin dépend des libs accessibles...), mais tu peux altérer le comportement de ton programme en fonction de l'état du système extérieur. (que tu ne devrais normalement/dans la majorité des cas pas connaître)
En soit ça a rien de grave, ça empêche pas de faire des programmes corrects ou quoi que ce soit, comme dit précédemment c'est juste une histoire de virtualisation: pouvoir lire le SR, ça veut dire en gros que tu as une instruction "is_running_in_sandbox_mode" intégrée au processeur... Et ça oui, c'est une faille de sécurité. Un bug non pas dans la circuiterie du processeur mais dans le design du jeu d'instructions initial

Oui mais la c'est partir du principe que tout le monde est méchant

Mais c'est le principe de base de la sécurité informatique.

En fait, en réfléchissant, ça peut poser problème même avec un programme "gentil" (). Ça empêche d'émuler à 100% un 68000 sur le 68000, parce que ça lit l'état du SR réel, au lieu de déclencher une exception qui permettrait à l'émulateur de renvoyer la valeur du SR émulé (imaginez un prog qui utilise le mode superviseur, qu'on fait tourner en mode utilisateur, avec la couche d'émulation qui émulerait les instructions privilégiées).

Ceci dit, le fait que les stack frames soient incomplètes doit être un obstacle beaucoup plus important. (Quoi qu'apparemment c'est possible de s'en sortir : Dave Small expliquait qu'il avait réussi à le faire pour son émulateur de Mac sur Atari).

Quelques autres détails que j'ai pu obtenir :

Un jour, tu m'avais dit que le 68000 avait un bug, ce qui avait rendu
nécessaire la création du 68020. Te rappelles-tu quel était ce bug ?

Non, pas tout à fait.

Le 68000 est un processeur 16 bits sans gestion de la mémoire virtuelle (en
fait les registres sont sur 16 bits que l’on peut coupler par 2 – donc 32
bits - si mes souvenirs sont bons et l’adressage est sur 24 bits).
Le 68020 est un processeur 32 bits avec gestion de la mémoire virtuelle.

En fait, il y avait une version 68010 (souvenirs de plus de 20 ans) qui
possédait
· les possibilités du 68000,
· l’ajout de la mémoire virtuelle mais pour lequel en cas de
défaut de page, un bug empêchait dans certains cas de traiter correctement
les données résiduelles et donc ne permettait pas d’implémenter
correctement les mécanismes de mémoire virtuelle.

ð Le processeur 68012 corrigeait ce problème.

PS :
Tu dois être rentré assez dans le détail de l’usage de ce type de
processeur pour savoir que les mécanismes de mémoire virtuelle ne servent
pas qu’à des systèmes universels (Unix, M$-Windows, MacOS) mais servent
aussi en embarqué pour protéger les programmes les uns des autres (qu’ils
ne « débordent » pas les uns sur les autres). Je ne sais par contre pas du
tout si c’est utilisé ou pas sur les ACMS et si le microcontrôleur utilisé est à base de 68000, 68010 ou 68012 ou autre.

Il a tord sur au moins un truc, le 68000 n'a que des registres 32bits.

Le 68010 ne semble pas non plus apporter directement une MMU, il faut attendre le 68030 pour ça...

Le 68012 a surtout pour différence, le packaging, et le fait que le bus mémoire a été étendu (2GB addressable, contrairement au 24bits addressable du 68000/68010)

les premiers MMU étaient des coprocesseurs non? comme les fpu.

oui, et pour la gamme des 68k il faut attendre le 68030 pour avoir un MMU embarqué, et le 68040 pour le FPU embarqué

le 68451 était très répandu comme copro mmu sur les 680x0 (mais principalement avec x=1 en fait)

et x=2 aussi normalement

oui, mais je ne sais pas si elle était opérationnelle avec 68012... faut croire que oui connaissant motorola mais bon, dans le doute...

(je pensais au 68020)

Edit: ha non pardon, c'était le 68851 qui etait utilisé avec le 68020

—

Si on pouvait arrêter tout de suite le HS, j'ai fait une demande de modération... Merci.

L'histoire du stack frame incomplet a éveillé mon attention: De quoi s'agit-il en fait?

http://www.classiccmp.org/pipermail/cctech/2008-April/093414.html

On either a bus error or an address error exception, the information
the processor puts in the exception stack frame is not sufficient to
either resume or undo the faulted instruction. [*] These errors were
considered fatal, and the typical "recovery" was to kill the process
that faulted. Obviously this is not conducive to implementation of
virtual memory.