Supporter est du jargon informatique. C'est marrant, supporter te gêne et pas CPU ...
CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.
« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».
Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.
Même si la quasi-totalité du système est écrite en C, au final c'est bien en assembleur que les instructions sont traduites et il faut donc que le CPU supporte des fonctions essentielles comme, par exemple, un équivalent de l'instruction TAS ( Test And Set ) pour pouvoir implementer des mecanismes de lock
Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.
integre un MMU et aît pas mal d'autres fonctionalités comme la possibilité d'adresser une taille mémoire suffisante pour au moins pouvoir booter le kernel.
Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.
La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.
Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.
Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.
[^] # Re: Et non ...
Posté par Obsidian . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à 2.
CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.
« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».
Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.
Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.
Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.
http://en.wikipedia.org/wiki/Memory_management_unit
La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.
Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.
Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.