Puis-je exécuter n’importe quel programme créé sans aucune plate-forme OS?

J’ai googlé à ce sujet et quelque part j’ai lu …

Oui, vous pouvez. Cela se produit dans le cas des systèmes embarqués

Je pense que non, ce n’est pas possible. Toute plate-forme doit avoir un système d’exploitation. Sinon, votre programme doit être lui-même un système d’exploitation. Soit doux ou câblé. Sans système d’exploitation, votre composant ne fonctionnerait pas.

Ai-je raison ou quelqu’un peut-il m’expliquer la réponse? (Je n’ai aucune idée des systèmes embarqués …)

Bien sûr vous pouvez. Tout ce qu’un processeur (typique) a besoin d’alimenter et d’accéder à une mémoire, il exécutera sa séquence d’amorçage codée en dur.

En règle générale, cela implique de lire une adresse prédéfinie, d’en interpréter le contenu sous forme d’instructions et de commencer à l’exécuter.

Ces instructions pourraient bien sûr provenir d’un programme C, bien qu’à ce niveau, il soit plus courant d’écrire les toutes premières étapes (appelées bootstrapping) en assembleur.

Bien entendu, cela ne signifie pas, si je lisais le titre de votre question à la lettre, que tout programme C soit exécuté de cette manière. Si le programme suppose qu’il existe un système d’exploitation, mais qu’il n’en existe pas, cela ne fonctionnera pas. Cela devrait être assez évident.

Vous pouvez exécuter un programme dans un système sans système d’exploitation … et ce programme ne doit pas nécessairement être un système d’exploitation lui-même.

Pensez à tous les ordinateurs (ou processeurs si vous préférez) à l’intérieur d’une voiture: gestion du moteur, climatisation, ABS, …, …
Tous ces systèmes ont un programme (éventuellement écrit en C) en cours d’exécution. Aucun des processeurs ne dispose d’un système d’exploitation.

La norme distingue spécifiquement les hosted implementations freestanding implementations :

     5.1.2.1 Environnement autonome
 1 Dans un environnement autonome (dans lequel l'exécution du programme C peut avoir lieu
     sans aucun avantage d’un système d’exploitation), le nom et le type de
     Les fonctions appelées au démarrage du programme sont définies par l'implémentation.  Toute bibliothèque
     installations disponibles pour un programme indépendant, autre que l'ensemble minimal
     requirejs par la clause 4, sont définis par la mise en œuvre.
 2 L’effet de la terminaison de programme dans un environnement autonome est
     défini par la mise en œuvre.

     5.1.2.2 Environnement hébergé
 1 Il n'est pas nécessaire de fournir un environnement hébergé, mais doit être conforme à la
     spécifications suivantes si présentes.
     ...

Je pense que vous auriez du plaisir à écrire des kernelx «jouets» conçus pour fonctionner sous des simulateurs tels que QEMU (ou des plates-formes de virtualisation, Xen + MiniOS est l’un de mes favoris). Avec peu de difficultés, vous pouvez installer une console de base et commencer à imprimer des éléments. C’est vraiment amusant, éducatif et satisfaisant à la fois.

Si vous travaillez sur x86 .. et que votre kernel spiffy fonctionne sous QEMU .. il y a de fortes chances qu’il fonctionne également sur du matériel réel. Vous pourriez en profiter.

Quoi qu’il en soit, la réponse à votre question est résolument oui. C’est particulièrement facile si vous utilisez un chargeur de démarrage. Par exemple, google memtest86 et récupérez le code.

Habituellement, tout programme C aura une variété d’appels système qui dépendent du système d’exploitation. Par exemple, printf effectue un appel système pour écrire dans le tampon d’écran. L’ouverture de fichiers, etc., est également un appel système.

Donc, fondamentalement, vous pouvez exécuter le code C qui est simplement compilé et assemblé en code machine sur un processeur, mais si le code appelle des appels système, il gèlera simplement le processeur lorsqu’il essaiera de sauter à un emplacement de mémoire où il se pense est le système d’exploitation. Bien entendu, cela dépendra de votre capacité à démarrer le programme, ce qui n’est pas facile sans le système d’exploitation.

Les systèmes embarqués sont des systèmes d’exploitation légitimes à part entière, ils ne sont tout simplement pas des systèmes d’exploitation à usage général . Tout programme utilisateur (c’est-à-dire un programme qui n’est pas lui-même un système d’exploitation) nécessite l’exécution d’un système d’exploitation.

Par exemple: Construire des systèmes ARM Bare-Metal avec GNU

De nombreux systèmes embarqués ne disposent pas de suffisamment de ressources pour un système d’exploitation complet, certains peuvent utiliser un kernel de planificateur ou un RTOS, d’autres sont codés «à nu». Le point d’entrée main () C est entré après la réinitialisation. Seule une petite quantité de code assembleur est nécessaire pour initialiser un microprocesseur et exécuter du code C. Tout ce que C a besoin d’exécuter est généralement une stack – en général, il s’agit simplement d’initialiser le pointeur de stack à une adresse spécifique. Certaines initialisations spécifiques au processeur de vecteurs d’interruption / exception, d’horloges système, de contrôleurs de mémoire, etc. peuvent également être nécessaires.

Sur un ordinateur de bureau, vous disposez généralement d’un BIOS qui gère l’initialisation matérielle de base, telle que la configuration et le minutage du contrôleur SDRAM, puis l’amorçage à partir d’un secteur de démarrage de disque, qui à son tour initialise un système d’exploitation. N’importe lequel de ce code pourrait être écrit en C (et certains le sont probablement), et il pourrait faire autre chose que démarrer un système d’exploitation – il pourrait tout faire – ce n’est que du code.

Les systèmes d’exploitation sont utiles pour les périphériques informatiques non dédiés dans lesquels l’utilisateur final sélectionne souvent l’un des nombreux programmes à exécuter et éventuellement plusieurs simultanément. La plupart des systèmes embarqués ne font qu’une chose: le logiciel est souvent chargé à partir de la ROM ou s’exécute directement à partir de la ROM; il n’est jamais modifié et s’exécute indéfiniment (en général, il n’est arrêté que par extinction).

Bien entendu, vous pouvez toujours implémenter des pilotes de périphérique, mais ceux-ci font souvent partie intégrante de l’application plutôt qu’une entité distincte. Même lorsque vous utilisez un système d’exploitation intégré dans un système intégré, celui-ci fait toujours partie intégrante de votre application plutôt qu’un système d’exploitation au sens où vous l’entendez. Dans ces cas, le RTOS est simplement une bibliothèque comme une autre, et est souvent initialisé et démarré avec main () plutôt que l’inverse, comme on pourrait s’y attendre.

Chaque composant matériel doit disposer d’un logiciel qui le gère, qu’il s’agisse d’un microprogramme intégré (plus petit et relativement fixe, comme vxworks) ou d’un logiciel de système d’exploitation pouvant exécuter du code arbitraire complexe (tel que Windows, Linux ou Linux). Mac).

Pensez-y comme une stack. en bas, vous avez le matériel. en plus de cela, un logiciel capable de contrôler ce matériel. en plus de cela, vous pouvez avoir toutes sortes de choses. Dans le cas d’un téléphone VoIP, vxworks contrôlera le matériel et comportera une couche qui gérera toutes les applications du téléphone.

Donc, pour en revenir à votre question, oui, vous POUVEZ exécuter n’importe quel programme c sur n’importe quoi, MAIS cela dépend de quel type de programme c il s’agit. si c est un programme c de bas niveau pouvant parler au matériel, vous n’avez besoin de rien d’autre que votre programme et le matériel. s’il s’agit d’un programme c de niveau supérieur (comme un programme de discussion en ligne), vous avez besoin de tout un tas de choses entre votre programme et le matériel.

avoir un sens?

De toute évidence, vous ne pouvez exécuter aucun programme C arbitraire sans une sorte de système d’exploitation ou un système d’exploitation équivalent. De même, je peux écrire un programme C sous Linux qui ne fonctionnera pas sous Microsoft Windows.

Cependant, vous pouvez écrire des programmes C sur presque n’importe quoi. C’est un langage populaire pour écrire des logiciels pour les systèmes embarqués, et ceux-ci n’ont souvent pas de système d’exploitation.

Beaucoup de systèmes embarqués ont juste un processeur connecté à une ROM, avec des broches sortant de la puce qui sont directement attachées aux entrées et aux sorties. Il n’y a pas d’E / S utilisateur, pas de système de fichiers, pas de planification de processus, rien pour lequel vous voudriez typiquement un système d’exploitation. Dans ces cas, un programmeur C peut écrire un programme gravé dans une ROM, qui gérera tout lui-même.

(Certains systèmes embarqués sont plus compliqués et peuvent utiliser un système d’exploitation. Linux est fréquemment utilisé, car il est gratuit, il peut être très compact et peut être modifié à tout niveau. Tous ne le sont toutefois pas.)

Vous n’avez certainement pas besoin d’un système d’exploitation pour exécuter votre code C sur un système. Vous aurez besoin de deux morceaux de code d’initialisation: un pour initialiser le matériel nécessaire (processeur, horloge, mémoire) et un autre pour configurer votre stack et votre environnement d’exécution C (c’est-à-dire l’initialisation des sections de données et BSS). Bien entendu, cela signifie que vous ne pouvez pas tirer parti des services de multithreading, de messagerie et de synchronisation fournis par un système d’exploitation. Je vais essayer de le décomposer en quelques étapes pour vous donner une idée:

  1. Ecrivez un “reset_routine” à exécuter au démarrage du tableau. Cela initialisera l’horloge et toute mémoire externe nécessaire. (Cette routine devra être exécutée à partir d’une mémoire interne ou d’une mémoire pouvant être initialisée et programmée en externe).
  2. Après les initialisations matérielles, la commande reset_routine transfère le contrôle à une routine “sw_runtime_init” qui configurera la stack et les globales définis par votre application. (Faites un saut de reset_routine à sw_runtime_init au lieu d’un appel pour éviter l’utilisation de la stack).
  3. Comstackz-la et liez-la à votre application, tout en vous assurant que la “réinitialisation_routine” est liée à l’emplacement indiqué par le vecteur de réinitialisation.
  4. Chargez ceci sur votre cible et priez.