Discussion :

[skaarj]

Bonjour,

Imaginons des experts de l’assembleur à qui on demanderait de coder de A à Z un système d’exploitation moderne du genre Windows 10, MacOS ou Linux uniquement avec ce langage et rien d’autre. Simplement pour le défi.

1. Serait-ce techniquement possible ?
2. Si oui, à quelles genres de difficultés devront faire face les développeurs ?
3. Comparé aux langages de plus haut niveau, combien de fois plus de temps il faudrait pour réaliser une telle tâche ?
4. Quel gain en réactivité/rapidité/stabilité obtiendrait ce système une fois finit ?

[Kannagi]

Tu as de drôle de curiosité dis donc

1)Oui , mais y'a beaucoup de chose possible dans ce monde, après que ça soit probable non !

2)La première difficulté (mais pas forcément lié à l'assembleur) c'est l'architecture PC et le manque de doc de la plupart des drivers propriétaires , bref tu vas te contenter du mode VGA 320x240
Sauf si tu pique du code source du kernel Linux , mais faudra réécrire les millions de ligne C en asm , 3 fois rien

3) Impossible de dire , mais sûrement plus longtemps , mais le programme assembleur a aussi son impact , j'ai pu prouver qu'on pouvait faire un petit jeu en 2 jours sans OS (c'était pas sur PC , mais ça compte quand même ).
Le souci principal est que les compilateurs C/C++/autre optimise très très bien , faire ça en asm ça prend énormément de temps.

4)Pas plus qu'un OS actuelle (si on recode un Windows 10 ).
Voir peut être moins réactive, vu qu'un programmeur va forcement faire des erreurs d'optimisation , enfin perso je vois mal un programmeur optimiser la mémoire cache pour tout un programme de millions de ligne , mais je demande à voir

Si je peux me permettre mon avis personnel , si on devrait avoir des OS optimisé (vu que c'est l'orientation de ta question je suppose ? ) , alors je pense qu'il faudrait une nouvelle architecture CPU (et donc un "nouveau" OS qui prendrait en compte ce genre de nouveauté /optimisation qu'apporterai cette machine).

Personnellement , je vois pas l’intérêt d'un OS full asm , ça serait inamaintenable au long terme et impossible de le porter ailleurs , les compilateurs sur pas mal de cas font du bon boulot , une approche C/Asm serait beaucoup plus bénéfique.
Par expérience perso , si tu fais un appel de fonction une fois pas besoin d'optimiser comme un bourrin
Je mettais de l'asm sur des cas très particulier ou le calcul se faisait des centaines de milliers voir des millions de fois par frame (donc millions/milliards par seconde) , là oui tu peux voir une différence.
Alors un OS c'est plus complexe que ça (dans le sens que le nombre de processus ne fait pas tout) , mais bon sur mon Linux jamais dépassé les 200 processus simultané , sur un ordi actuelle c'est peanut de gérer 200 processus.

PS: Mais si tu veux de la réactivité installe Linux + XFCE ça répond instantanément et avec moins de 500mo en RAM

[skaarj]

Bonjour Kannagi,

En fait oui, ma question était plus orientée vers l'optimisation des systèmes d'exploitation en particulier, mais aussi des logiciels en général.

Je ne sais pas, mais je trouve que les programmeurs d'avant, de l'époque où les machines ne contenaient que quelques Ko ou Mo de RAM, avaient plus de mérite ou de talents que ceux d'aujourd'hui. Je ne sais pas si je m'exprime correctement... En fait, j'ai l'impression qu'on a tellement de puissance processeur, tellement de mémoire RAM, que les programmeurs d'aujourd'hui sont devenus paresseux. Paresseux au sens : "pas besoin d'optimiser à mort ils ont qu'à acheter une carte vidéo plus puissante, ou changer de processeur ou ajouter des barrettes".

Avant, tout était tellement rikiki qu'il fallait se casser la tête pour que le tout fonctionne correctement, bien et vite et surtout il n'y avait pas internet pour des mises à jour. Ces possibilités de mises à jour qui ajoutent une paresse de plus aux programmeurs d'aujourd'hui puisqu'ils peuvent après coup corriger des bugs et apporter améliorations.

Alors attention, loin de moi l'idée de revenir en arrière hein, mais je serais curieux de voir comment seraient les choses si on bloquait les quantités de RAM et vitesse processeurs sur nos machines. Je pense que là on verrait des optimisations/astuces de fous de la part des programmeurs. Et aussi, d'où ma question sur l'assembleur, un intérêt moindre sur tout ces nouveaux langages de programmation qui finalement sont plus facile mais moins rapide que les langages de très bas niveau.

Bon, tout ça pour dire que j'ai ce sentiment, que quand mon jeu ou application rame, je ne peux pas m'empêcher de me dire que ceux qui ont codé le programme n'ont pas fait les choses à fond.

[bifur]

j'expliquerait le fait que les programmes sont de plus en plus gourmand parce que l'on demande aux ordinateur d'en faire de plus en plus sans que cela soit ressentit par l'utilisateur par exemple la résolution de l'écran, par rapport au temps ou les ordinateurs fonctionnait en mode texte et maintenant ou il n'est pas rare d'avoir 1920*1024 en 32 bit on est déjà passé (juste pour la carte video) de 4Ko à 7Mo minimum nécessaire. si a ça on ajoute la gestion du réseau qui était inexistante ou vraiment basique des début a l'état de mise a jour permanent on as pas les mêmes besoin

refaire win10 en assembleur donnerait pour les même fonction les même performance. si on a pour objectif d'avoir un system plus réactif on peut passer par une distribution linux allegé. refaire un système d'exploitation en assembleur, c'est sympa mais a mon avis pas besoin d'essayer de copier windows10

[Kannagi]

Bonjour Kannagi,
Je ne sais pas, mais je trouve que les programmeurs d'avant, de l'époque où les machines ne contenaient que quelques Ko ou Mo de RAM, avaient plus de mérite ou de talents que ceux d'aujourd'hui. Je ne sais pas si je m'exprime correctement... En fait, j'ai l'impression qu'on a tellement de puissance processeur, tellement de mémoire RAM, que les programmeurs d'aujourd'hui sont devenus paresseux. Paresseux au sens : "pas besoin d'optimiser à mort ils ont qu'à acheter une carte vidéo plus puissante, ou changer de processeur ou ajouter des barrettes".

Avant, tout était tellement rikiki qu'il fallait se casser la tête pour que le tout fonctionne correctement, bien et vite et surtout il n'y avait pas internet pour des mises à jour. Ces possibilités de mises à jour qui ajoutent une paresse de plus aux programmeurs d'aujourd'hui puisqu'ils peuvent après coup corriger des bugs et apporter améliorations.

Je suis d'accord , mais bon ça même avec le meilleur OS au monde n'y pourra rien y faire

Certe mais tu ne peux pas comparer comme ça un truc de quelque ko et de nos jours, je programme pour le fun sur des machines de quelque ko , ça donne quoi : des images en 16 couleurs une résolution de 256x224/320x224 , des samples ADPCM et qui dépasse pas les 8000 Hz ,un OS qui te laisse taper dans le hardware /RAM en roue libre en monotâche et mono-utilisateur.
Alors oui ça prend rien , après pas sur que beaucoup de personne veule un programme actuelle en bipbip et en 320x240

Alors attention, loin de moi l'idée de revenir en arrière hein, mais je serais curieux de voir comment seraient les choses si on bloquait les quantités de RAM et vitesse processeurs sur nos machines. Je pense que là on verrait des optimisations/astuces de fous de la part des programmeurs. Et aussi, d'où ma question sur l'assembleur, un intérêt moindre sur tout ces nouveaux langages de programmation qui finalement sont plus facile mais moins rapide que les langages de très bas niveau.

Tu te prend un vieux ordi et tu regarde
Mais ça forcera personne , tu sera sûrement un des seuls sur W10 avec 256-512 Mo de RAM et un Pentium (si'il s'installe dessus lol),a la limite un Linux passerait dessus.

Sinon c'était peut être vrai dans les années 80-90 que l'asm était plus optimisé que des langages haut niveau ,de nos jours un compilo GCC avec l'option -O3 , et tu devient un programmeur assembleur confirmé
Un bon exemple est l'embarqué , on utilise du C , pourtant les CPU ne font que quelque MHZ et quelque ko
Après bien sur tu trouvera l'asm plus efficase que du C dans un cas particulier ou un proco pas pensé pour les langages haut niveau , mais ça reste des exceptions .

Je rejoins bifur
Pour la résolution : 1920*1024 en 32 bit , ça fait 8,25Mo + double buffer ça fait fois deux donc 16,5 Mo.
Faut rajouter que chaque programme à son Double-Buffer ce qui augment énormément la taille totale demandé :p

[bifur]

bon si tu veux travailler avec des pc des années 80-90, il faut travailler pour l'industrie on en croise plein et on utilisait pas forcément l'assembleur (chez nous par exemple c'est plutôt le Pascal) le mode texte et les bipbip ça intéresse encore du moment que ça fonctionne

a propos de vieux pc, si vous avez un fournisseur sérieux pour des lecteur de disquette en excellent état (non usb) je suis preneurs

[Invité]

Bonjour,

Imaginons des experts de l’assembleur à qui on demanderait de coder de A à Z un système d’exploitation moderne du genre Windows 10, MacOS ou Linux uniquement avec ce langage et rien d’autre. Simplement pour le défi.

1. Serait-ce techniquement possible ?
2. Si oui, à quelles genres de difficultés devront faire face les développeurs ?
3. Comparé aux langages de plus haut niveau, combien de fois plus de temps il faudrait pour réaliser une telle tâche ?
4. Quel gain en réactivité/rapidité/stabilité obtiendrait ce système une fois finit ?

Oui, c'est possible. Dans le même ordre d'idées, tu peux aussi envisager de vider une baignoire pleine à ras-bord avec une cuillère à café. Autant dire que c'est sans intérêt. En assembleur, quand tu augmentes notablement le volume du code et des données, tu es obligé de te plier à un formalisme rigoureux qui gonfle le volume des modules. Tu ne pourras gagner en vitesse que sur certains process mais pas sur tout car, dans bien des cas, c'est la vitesse de fonctionnement des périphériques qui ralentit l'exécution.
En fait, le langage utilisé n'a qu'une importance moyenne. Le plus important est le niveau de maîtrise que tu en as. Ainsi, tu peux très bien développer un assembleur en C/C++, en Pascal ou en Basic.
Accessoirement, les gens qui me "vendent" le C/C++ comme une usine à rêves me font sourire.
Si tu penses au monde des jeux vidéo, note tout de même que les développeurs sont fortement contraints par la grande portabilité de leurs logiciels. Forcément, ils s'interdisent certains procédés car trop dépendants de certains périphérique.

[chrtophe]

Avec la faible puissance des anciens CPU, et les faibles quantités de RAM, il était difficile de faire un compilateur C super efficace, ce qui n'est plus le cas maintenant. Et sans parler du C++ qui rajoute une couche de complexité. Il y avait donc effectivement une différence importante entre 1 programme fait en assembleur et un autre fait en C. Les CPU étaient également beaucoup plus simple, ainsi que les périphériques (ports séries/parallèles remplacés par l'USB, pas de réseau ou très simpliste, pas de protection d'accès aux ressources).

Développer en assembleur est devenu quasi impossible sur des CPU type Intel. Cela reste possible sur des microcontrôleurs, mais peu pertinent, vu qu'on peut le faire plus vite, plus stable et plus efficace en C.

[Invité]

...
Développer en assembleur est devenu quasi impossible sur des CPU type Intel.
...

Tu parles sérieusement, là ?
Parce que, justement, je ne ressens pas tout-à-fait la même chose.
Les Intel (et AMD) se programment très bien en assembleur. Suffit de le vouloir et de trouver la bonne doc.
Faut écouter d'une oreille distraite les gourous qui crachent dans la soupe (celle des autres, pas la leur)

[chrtophe]

Tu parles sérieusement, là ?
Parce que, justement, je ne ressens pas tout-à-fait la même chose.

Je vais m'expliquer plus clairement. Je dis que c'est quasi impossible surtout par le manque de documentation pour développer des pilotes de périphériques. Le temps que tu sortes quelque chose d'un minimum viable from scratch (ce qui est la question de posée à la base), on en sera à Windows 30.

Les anciens processeurs fonctionnaient en mode réel, maintenant il faut connaitre ce qu'est le mode protégé (bien que plus utilisé en 64 bits au profit de la pagination), la pagination, la gestion des cores, maitriser les TLB, les instructions SIMD (SSE). Et je ne parle pas des instructions liées à la virtualisation, et encore moins de la gestion du bus USB, et des pilotes de périphériques.

C'est "légèrement plus compliqué" que le 8086. qui lui restait facile d'accès.

Je ne prétend pas être un gourou, mais je pense savoir de quoi je parle.

Il suffit de voir ou en sont les systèmes en pur assembleur développé from scratch comme par exemple MenuetOS, qui représente déjà un travail énorme (début du développement : 2000) et de voir le chemin restant à faire pour ressembler à Windows ou Linux. Et en plus n'étant pas Posix, il n'est compatible qu'avec lui-même. Il ne gère que le FS FAT32 et USB2 (pas d'USB3). Il y a un fork implémentant l'accès NTFS, ext2/3.

[Kannagi]

Tu aurais du préciser développer sur un CPU type Intel sur PC sans OS ^^
Et je rajouterais que c'est un processeur qui souffre des années passé niveau architecture.

[Invité]

Je crois avoir dit moi-même un peu plus haut qu'il était à peu près sans intérêt de développer un OS en assembleur. Ce faisant, je n'avais d'ailleurs pas conscience des difficultés inhérentes aux pilotes qui confortent mon opinion et rejoignent la tienne si j'ai bien compris.
Il me semblait donc évident que tu exprimais une opinion générale concernant l'usage de l'assembleur et j'ai même cru comprendre que Kannagi s'était livré à la même interprétation.
Bref, tout ceci n'est que bavardages et j'en viens à l'essentiel.
Tu as raison de souligner l'extrême complexité des processeurs Intel contemporains. Mais, c'est comme tout. Il faut lire, relire, tester, douter, faire, refaire... Certains assembleurs, comme le SDK de Steve Hutchesson, ont atteint un niveau proprement incroyable (y compris en 64 bits). L'IDE Easy Code permet, quant à lui, de programmer en "Visual Assembler" à la manière de Visual C/C++... Il reste beaucoup à faire dans ce domaine et je pense que l'IA permettra à terme de programmer en assembleur sans difficulté.
Après, il y a une question de choix. Je m'appuie sur un OS tout fait (Windows) et il m'arrive d'en court-circuiter certaines fonctionnalités dans des cas extrêmes. D'autre part, l'assembleur peut piloter Windows sans difficulté aucune. Tout comme le C et avec un nombre de lignes à peine plus important.
C'est pour ça que j'apprécie moyennement, dans un forum dédié à l'assembleur, que l'on présente ce langage comme un truc assez infâme totalement d'un autre âge. Sur ce point, j'aime à rappeler que pas mal de langages aujourd'hui disparus étaient présentés naguère comme des langages d'avenir qui allaient tout balayer sur leur passage. Et on finirait peut-être de voir fleurir encore des exercices mettant en œuvre l'INT 21h du défunt MS-DOS. Quand je pense que des enseignants en sont encore à ce point...

[chrtophe]

Pour clôturer :

Serait-ce techniquement possible ?

oui, sous réserve d'avoir toutes les documentations techniques nécessaires, notamment pour le développement des pilotes.

Si oui, à quelles genres de difficultés devront faire face les développeurs ?

cf; réponse question 1, temps plus important de temps à prévoir.

Comparé aux langages de plus haut niveau, combien de fois plus de temps il faudrait pour réaliser une telle tâche ?

Un temps très important, c'est pas pour rien qu'on a créé les langages de plus haut niveau
Quel gain en réactivité/rapidité/stabilité obtiendrait ce système une fois finit ?

Quel gain en réactivité/rapidité/stabilité obtiendrait ce système une fois finit ?

Aucun : Un compilateur optimisera mieux qu'un humain tout ce qui concerne la gestion des pipelines, optimisation de la prédiction de branchements, etc. Au niveau stabilité, il me parait plus facile d'introduire des bugs en assembleur, et plus difficile de déboguer, nous parlons ici de recréer toutes les fonctions ne serait ce que de la libc, s'agissant du postulat du codage de A à Z. C'est pas pour rien que les OS du marché ne sont pas développés en assembleur, ce qui n'empêche pas d'avoir des bouts de code en assembleur dedans, c'était d'ailleurs nécessaire avant l'UEFI pour le BIOS, UEFI qui est d'ailleurs écrit en C tandis que les BIOS étaient écrit en assembleur.

Actuellement, l'assembleur est essentiellement utilisé pour l'écriture de firmwares, l’électronique, mais ce n'est plus une obligation comme auparavant.
Par contre, en faire un peu permet de comprendre comment de simples 0 et 1 permettent de faire ce qu’est un ordinateur aujourd'hui.

[Kannagi]

C'est pour ça que j'apprécie moyennement, dans un forum dédié à l'assembleur, que l'on présente ce langage comme un truc assez infâme totalement d'un autre âge.

Pour ma part je préfère être clair que l'asm est clairement pas"fun" sur de nombreux point (et j’aurais la même critique concernant le C qui est un langage plein de faut lui aussi).

Et comme i lest souvent dit dans ce forum , faut mieux quand même privilégier des processeurs simple pour l'asm , il me semble que tu facilite grandement la vie avec des IDE outils pour l'asm , si on parle du x86/x64 , j'ai trouvé cela totalement imbuvable avec NASM

Mais si on parle de l'asm en règle général et principalement des autres processeurs moderne (parce que je ne fais pas que du x86) , oui l'asm est vraiment imbuvable pour les processeurs modernes , la gestions des caches ,de la pipeline , du superscalire , des processeur VLIW , personnellement je pense sincèrement que pour programmer/optimiser sur un proc moderne il faut des outils /langage haut niveau qui optimise tout ça vu le nombre important de paramètre que devrait avoir le programmeur.
Après c'est possible de le faire à la mano sur des processeurs complexe, c'est ce que je fais , mais tu passe une journée pour optimiser 200 lignes

Bref pour dire que notre but est aussi d'avertir et d'expliquer surtout que beaucoup ont des croyances combien de fois j'ai entendu dire "l'assembleur me permettra de faire du code rapide" ou " ça permet de faire du bas niveau" , alors que tu peux faire du code rapide sans asm , et tu peux faire du bas niveau sans écrire en asm (tu peux communiquer avec le hard en C ou C++).

[Invité]

...
Actuellement, l'assembleur est essentiellement utilisé pour l'écriture de firmwares, l’électronique, mais ce n'est plus une obligation comme auparavant.
Par contre, en faire un peu permet de comprendre comment de simples 0 et 1 permettent de faire ce qu’est un ordinateur aujourd'hui.

Bravo pour cet exercice de motivation. Nul doute que ça va susciter des vocations. Avec toi, ce forum est entre de bonnes mains.
Pour ta gouverne, j'ai pratiqué à partir des années 80 sur le seul Assembleur qui existait : celui de Microsoft. Il y avait les mêmes débats alors que les écarts de performances étaient énormes. Mais, comme il y avait différents processeurs (8088/86, 6502, 6800), on prétendait que l'assembleur risquait de poser des problèmes de... portabilité. Mais l'assembleur était tout aussi marginal à cette époque et, en tout cas, aucunement obligatoire.

[chrtophe]

Bravo pour cet exercice de motivation. Nul doute que ça va susciter des vocations.

Tu veux quoi ? que je dises : oui vas-y tu vas faire un OS équivalent à Windows en assembleur tout seul dans ton coin en 1 an ?

Ben non. L’assembleur n'est pas mort, mais en dehors d'un choix personnel, ne t'en déplaises, dans l'industrie et le développement, il est peu utilisé et pour les points déjà évoqués.

Autre point intéressants de nos jours : le FPGA qui te permet de fabriquer ton propre CPU. Pour un étudiant ou passionné : c'est génial.

Pour ta gouverne, j'ai pratiqué à partir des années 80 sur le seul Assembleur qui existait : celui de Microsoft.

La bonne blaque. Pour la tienne, à la même période, il y avait C64 Macro Assembler, les fameux K-Seka et Devpac2 sur Amiga (pas mal pratiqué), qui n'étaient pas de Microsoft.

on prétendait que l'assembleur risquait de poser des problèmes de... portabilité.

C'est tout à fait le cas, du code assembleur 6502 doit être complètement réécrit pour tourner sur du 8086, c'est le cas pour les processeurs modernes également, un code écrit pour un CPU RISC (PowerPC, processeurs utilisés par les Raspberry, par les téléphones mobiles, etc.) ne tournera pas sur un CPU Intel. Il faut tout réécrire. Et même sur les anciens Intel, du code Intel 8080 (connu pour équiper beaucoup de 8 bits avant l'avènement du PC) était incompatible avec la gamme 8086, ce qui a nécessité une réécriture de CP/M, OS ancêtre de MS-DOS et ayant équipé beaucoup de 8 bits, tels que les Commodores 64-128, les Amstrad CPC. CP/M est connu aussi pour avoir été à l'origine de la notion de BIOS.

[bifur]

je rejoint asmou sur le fait que l'assembleur n'est pas du tout encouragé, mais c'est vrais qu'il faut honnêtement avertir les gens que c'est pas un sujet facile

pour ce qui est de la programmation d'OS, on en parle toujours comme si c'était un truc fait d'un seul tenant alors que c'est un ensemble que je diviserait en 3 parties: le noyau, l'interface, et les applications. pour les applications et l'inerface je dirait que on peut avoir besoin de portabilité mais pour le noyau c'est différent, c'est toujours quelque chose d'écrit spécifiquement pour une architecture et dans ce cas l'assembleur a toute son utilité, je me demande même comment on pourrait faire ça autrement

et même pour les besoin de portabilité, si on développe un OS pour du 386 (avec un jeu d'instruction très réduit donc), je peut témoigner que ça fonctionne aussi sur du i7

[chrtophe]

Je suis d'accord, mais la question à la base concernait l'écriture d'un système d'exploitation de A à Z en assembleur.

Aucun grand éditeur n'écrit son noyau en assembleur, juste quelques parties. C'était le cas quand les noyaux étaient tout petit, que les compilateurs n'étaient pas assez puissant, qu'il n'y avait pas d'interface graphique.

Prenons l'exemple du noyau Linux, celui-ci représente plusieurs millions de lignes de code. Il fonctionne sur au moins une trentaine d'architectures CPU différentes (plus ou moins éloignées). Tu penses bien que le code du noyau n'a pas été réécrit/adapté sur toutes ces architectures et qu'il serait dans un cas comme celui-ci aberrant de le faire. La majorité du code est écrit sur un socle commun en C/C++, les structures internes permettent une abstraction concernant les architectures. Exemple la pagination sur Intel comporte deux indirections, d'autres CPU en comportent trois, Linux le gère au niveau de sa partie gestion de la mémoire virtuelle. L'étape de compilation va passer par une transformation du code C en code assembleur pour l'architecture concerné, code assembleur qui sera "assemblé" : transformé en binaire.

Une faible partie du code est écrit en assembleur, et toutes ses parties là sont spécifiques à l'architecture utilisée, et doivent être adaptées régulièrement. Des architectures ont été retirés, d'autres ajoutées.

et même pour les besoin de portabilité, si on développe un OS pour du 386 (avec un jeu d'instruction très réduit donc), je peut témoigner que ça fonctionne aussi sur du i7

Les appels systèmes ne ce font pas de la même façon sur un OS 32 bit et un OS 64 bits. Un OS 64 bits gérera les logiciels 32 bits si il a un système en interne pour le faire (schématiquement syswow pour Windows, ia32-libs pour Linux). La dernière version de MacOS qui vient de sortir ne permet plus de faire fonctionner d'applications 32 bits.

[Kannagi]

Mais l'assembleur était tout aussi marginal à cette époque et, en tout cas, aucunement obligatoire.

Je suis étonné de lire cette affirmation, quand je lis la biographie de Frédéric Raynal il disait bien que pour lui l'asm était la seule façon de programmer sérieusement en 1980-début 1990.

La plupart des jeux/programmes sur micro était en assembleur (Amstard CPC , commode64 , Atari ST , Amiga ).
Après tu avais un PC en 1980 , chapeau, mais tu devait être un des rares qui la possédait vu le prix de la bécane , la plupart des gens allait sur d'autre micro moins chère et tout aussi puissant :p
Le M68000 est clairement plus puissant qu'un 8086 (que ça soit niveau jeu d'instruction , d'architecture ou de registres le M68000 il avait deja 16 registre 8 de data/8 d’adresse, c'était presque des registres généraux en 1980 ! )
Par exemple niveau chiffre on a souvent :
M68k : 1.400 MIPS at 8.000 MHz
Intel 8088 : 0.750 MIPS at 10.00 MHz
(MIPS = million instructions per second)

La plupart des jeux sur consoles ou arcade était en full asm.

Non de ce que je vois l'asm est devenu 'obsolète' (on tout cas peu utilisé) au milieu des années 1995 , les processeurs sont devenu bien plus puissants , mais je pense aussi qu'ils sont devenu plus complexe (les mémoires caches / pipeline /superscalaire ec etc sont venu avec la gamme des Pentium sur PC et sur consoles avec le MIPS).

Sinon on peut faire du bas niveau en C (dans une moindre mesure mais c'est possible de jouer avec le hard en C) , et le compilo est suffisamment intelligent pour compiler comme je le ferais en asm par exemple :
*((volatile unsigned char *)(0x100000) = 5;
il me le met bien en une seule instruction (pour le m68000 , mais il me le compile bien aussi pour du MIPS) : move.b #5,0x100000

et même pour les besoin de portabilité, si on développe un OS pour du 386 (avec un jeu d'instruction très réduit donc), je peut témoigner que ça fonctionne aussi sur du i7

Oui enfin là on parle d'un portabilité assez faible faut avouer
On parle ici de processeur différent ARM/PowerPC/Intel , le C te permettra plus facilement d'avoir un code pour ces 3 plateformes et de façon optimisés , en asm tu devra on faire 3 différents et chaque fois optimisé pour chaque plateforme

[bifur]

ça fait une dizaine de message que celui qui as posé la question n'est plus intervenu, et comme bien d'autres arrivé ici, on ne le reverra plus. inutile de répéter 15 fois que les grand éditeurs et les professionnels n'utilise peux l'assembleur, ça on as comprit. j'imagine que quand quelqu'un pose une question dans le forum C personne ne vas dire dans tout ses message "utilise plutôt le C#" ça serait gonflant. Je viens plus trop ici, je préfère les forum de Fasm et d'osdev.org et faut pas se demander pourquoi

je crois que j'était pas claire sur ma définition du noyau et de l'interface
par noyau j'entend le truc qui gère l'allocation mémoire, les création et les commutation de tache
par interface j'entend le truc qui gère la communication entres les processus, les périphérique, et l'utilisateur (pas seulement l'interface avec l'utilisateur)

par contre je ne comprend pas, si les os32 bit et 64 bit n'ont pas de compatibilité entre leurs fonctionnement d'appel système (ce que je conteste pas j'ai jamais fait de 64bit) pourquoi? les langage de haut niveaux des noyaux modernes ne font ils pas abstraction de l'architecture du microprocesseur? une petite recompilation et zou! ça fonctionne