Cette partie du forum n’est pas compatible avec les bloqueurs publicitaires
Félicitations à vous, de préférer les accès payants plutôt que la gratuité par la publicité, c’est honnorable et cohérent de votre part. Malheureusement, l’accès payant par micropaiement (qui serait d’environ 1 cent pour 20 pages consultées) n’est pour l’instant pas encore mis en place, et l’accès gratuit sans publicité, est réservé aux membres actif(ve)s du forum. En attendant, si vous souhaitez poursuivre votre visite chez nous, vous pouvez ajouter le site à votre liste blanche, ou encore mieux, désactiver le bloqueur partout. Pour ajouter le site à votre liste blanche, pour Firefox (similaire pour les autres navigateurs), rendez‑vous en bas à gauche de la fenêtre de votre navigateur, et cliquez sur le menu comme dans l’exemple de l’image ci‑dessous, puis rechargez la page, en appuyant sur F5.
Le langage C n’a pas copié les instructions du PDP‑11
|
|
|
| Auteur | Message |
|---|---|
|
Administrateur
|
Ven 7 Déc 2012 02:31
Le langage C n’a pas copié les instructions du PDP‑11
Mais c’est quoi ce titre en Chinois ?
 Les gens intéressés comprendront, c’est pas grave pour les autres.Parmi les reproche fait au C, l’un est de ne pas être si portable que prétendu, car trop proche d’un type d’architecture spécifique, qui n’a rien d’universel (et effectivement, quand les machines quantiques vont arriver, il y en a qui vont souffrir inutilement… restera le langage Ada pour les sauver de l’impasse  ). Une mauvaise preuve en est donné (mais il existe de bonnes preuves), celle que le C aurait copié ses instructions sur celles du PDP‑11, dans le but de juste en faire un assembleur de haut niveau pour cette ancienne machine (1970 à 1990 environ).Eh bien en fait, non. Les instructions de pré‑incrément et de post‑incrément qui sont mise en cause, n’ont pas été copié des instruction du PDP‑11, c’est seulement que les instructions spécifiques du PDP‑11 ont été utilisé pour efficacement implémenté ses instructions du C, dont l’existence a été décidée indépendamment. Un document historique relatant les grandes de la la genèse et de l’évolution du C à partir de ces ancêtre (B, qui est une sorte de C non‑typé, même si parler de typage en C fait sourire ironiquement, et BCPL), nous l’apprend. Note : je ne traduis pas les citations, les gens connaissant le C, étant souvent capables de lire l’Anglais. Si malgré tout une traduction en français peut être utile, il ne faut pas hésiter à la demander en réponse à ce sujet (si vous êtes visiteur/se de passage, pensez à vous inscrire sur le forum au préalable). Source : The Development of the C Language (cm.bell-labs.com). Dennis M. Ritchie. Date inconnue, probablement postérieure ou égale à 1989. Le document a écrit : Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. Cette supposition, n’est donc qu’une supposition qui a été prise pour une vérité avéré, sans que personne n’ait pensé à la vérifier. Cette croyance n’est qu’une légende. Cependant, on peut du même document, citer une preuve que le C a malgré‑tout été conçu de manière à coller à une architecture particulière, à travers son héritage des langages B et BCPL : Le même document a écrit : Because pointers in BCPL and B are merely integer indices in the memory array, arithmetic on them is meaningful: if p is the address of a cell, then p+1 is the address of the next cell. This convention is the basis for the semantics of arrays in both languages. On apprend que même la convention de marquer la fin des chaînes de caractères avec un « caractère nul », est une conséquence des architectures de l’époque : Le même document a écrit : In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled `*e'. This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, […] Cependant, ce choix est justifiable, et même Ada aurait put opté pour une convention similaire, quoique cela pose un problème dans les contexte ou le « caractère nul » est un caractère normal. La justification de cette décision, par l’architecture, est d’ailleurs pondérée aussitôt après : Le même document a écrit : […] and partly because maintaining the count seemed, in our experience, less convenient than using a terminator. Petite anecdote, dans ce document on découvre à quel point la convention d’appeler “a.out” le fichier résultant d’une compilation, est très ancienne. Elle date du tout premier Unix, sur PDP‑7 (une vieillerie de chez les vieilleries). Le même document a écrit :
Thompson's PDP-7 assembler outdid even DEC's in simplicity; it evaluated expressions and emitted the corresponding bits. There were no libraries, no loader or link editor: the entire source of a program was presented to the assembler, and the output file—with a fixed name—that emerged was directly executable. (This name, a.out, explains a bit of Unix etymology; it is the output of the assembler. Even after the system gained a linker and a means of specifying another name explicitly, it was retained as the default executable result of a compilation.)  Hibou57 « La perversion de la cité commence par la fraude des mots » [Platon] |
 
|
|
