./203 > Tu pourrais faire entièrement sans. Il me semble d'ailleurs que c'est déjà possible avec les images multiboot (utilisées par GRUB), qu'utilise déjà JNode d'après ./198 .
Actuellement sur x86 c'est la merde parce que c'est encore totalement rétro-compatible avec les CPU 16 bits, donc ton système démarre dans un état indéterminé. Tu dois éxécuter du code pour vérifier que tu te lances bien sur la machine attendue, car ton code peut s'exécuter (avant de crasher) sur une machine où il ne devrait pas pouvoir . (C'est une des choses qui m'a le plus fait fuir. Ça et la complexité incroyable du jeu d'instruction x86…)
Mais si tu utilises des abstractions de plus haut niveau comme EFI (ou GRUB, enfin bof), tu peux très bien te démerder à faire ce que tu veux. Ah certes, tu exécuteras du code natif que tu n'as pas écrit. Mais tu t'en fous, c'est un truc standard, et ton OS démarrera directement dans un état connu. Inutile de dire qu'à partir de là tu peux déjà quasiment faire ce que tu veux… Tout au moins, en C# tu pourrais (et je pense qu'en Java aussi mais j'en mettrai pas ma main à couper non plus).
Enfin, évidemment faut que tout soit bien ficelé. Mais qu'est-ce qui va t'empêcher de gérer les pages mémoire ou de gérer les différentes tâches à partir de code JITté ?
Tu as quelques instructions (LGDT par exemple) qu'il va falloir représenter par une méthode spéciale (implémentation par le runtime ^^), mais c'est le boulot du JIT/AOT de s'occuper de ces cas spéciaux. Et le JIT/AOT est déjà spécifique à la plate-forme.
Tu auras juste des contraintes particulières sur les opérations que tu peux effectuer quand tu es à l'intérieur d'un service critique du système, mais je vois pas en quoi ça t'empêche de faire ce qu'il faut.
(Typiquement: Tu ne peux pas allouer un nouvel objet dans le code qui gère les allocations mémoire.
En effet en Java qui n'a pas stackalloc et System.ValueType, ça pourrait poser problème, là encore )