Poderse se puede, pero como dice JM, no tal y como tu dices.

Es posible hacerlo pero antes de programar tendrías que aprender mucho sobre la arquitectura del ordenador que estás usando y sobre sus componentes.

Resumiendo, OLVIDATE DE ESA IDEA.

El tema de cargar el ejecutable nativo sin pasar por tener un sistema operativo creo que puede hacerse simplemente instalando lilo o grub en el MBR del disco duro que esté configurado en la BIOS para que cargue el primero, y luego desde lilo o grub se especifica el archivo que debe ejecutarse, normalmente ese archivo es linux (el kernel) pero debería funcionar si pones tu propio ejecutable. Como no tendrás sistema operativo en ese HD puedes instalar lilo o grub conectando ese HD a otro ordenador e instalándolo desde alli, o usando un LiveCD sin sacar el HD de su sitio (para estas cosas el LiveCD de instalación de Gentoo es más útil que la mayoría de LiveCDs que hay por ahí).

Como dice Heli, el ejecutable no vale que sea el típico que saldría si compilas sobre otro sistema operativo porque ese ejecutable solo arrancaría sobre ESE sistema operativo sobre el que fue compilado o uno que implemente la misma API (aquí sería útil leer algo sobre POSIX...). Para que el binario pueda ejecutarse sin pasar por un kernel puedes hacerlo automáticamente con el parámetro "ffreestanding" de GCC, aunque es más que probable que tuvieses que acabar haciendo tus propios scripts de compilación y de linkado e invirtiendo un montón de tiempo para algo que en principio pretendía ser simple.

El mayor problema que yo le veo es también lo que comenta Heli de que "no podremos hacer uso de las llamadas al SO", es decir, el kernel es quien se encarga de gestionar casi todas las comunicaciones entre los procesos y el hardware, quien gestiona el mapeo de memoria, los registros... y los drivers no existen por gracia divina, sino que están ahí para que con solamente llamar a una función tengas acceso fácil a cosas como leer la entrada por teclado, o mostrar texto por consola. Sin kernel tendrás que hacer todas estas cosas a mano, y básicamente terminarías haciendo tu propio kernel de miles y miles de líneas para que el programa haga algo muy básico. Olvídate también de acceder a cosas más complicadas como el puerto paralelo, puerto USB, disco duro, lector de CD, tarjeta gráfica, ratón, red... No tendrás nada de esto, si no tienes un kernel solamente podrás sumar variables, meterlas dentro de condicionales y bucles, y poco más.

Si lo que quieres es potencia (osea un ordenador, no solamente un microcontrolador) pero solo necesitas que se ejecute un programa escrito por tí, lo mejor es que instales un linux muy muy muy capado. Linux From Scratch sería ideal, seguido por Gentoo y si quieres ahorrarte el compilar (que tampoco es algo especialmente traumático), Debian. El sistema lo preparas para que no tenga instalado nada que no sea absolutamente necesario, y mucho menos tener demonios inútiles que se ejecuten al arrancar el sistema. Compila el kernel manualmente y desde la su configuración recuerda pensarte bien el valor de "Processor type and features" => "Timer frecuency" teniendo en cuenta la cantidad de procesos que realmente se van a ejecutar y el tiempo que puedes perder haciendo otras cosas que no sean ejecutar tu programa principal. Haz que tu binario se ejecute desde /etc/conf.d/local.start o el script que corresponda según la distribución que uses. Ejecutalo como root al máximo nivel de prioridad ("nice -n -20 <aplicacion>") y piensate también el planificador de procesos más eficiente para tu caso ("Enable the block layer"=>"IO Schedulers"). Instálalo todo en una sola partición, con suficiente RAM pero sin SWAP (porque si algo se mete en la swap estás perdiendo mucho rendimiento, y es peor el remedio que la enfermedad), y que esa partición sea ext2 o cualquier otra pero que no tenga journaling, o que al menos lo tenga desactivado. Desactiva también todos los logs que puedas, incluyendo los internos gestionados por el kernel.

Con todo esto deberías tener lo suficiente para que un solo programa se ejecute CASI en tiempo real pero sin tener que dedicar el resto de tu vida a programar un kernel tú mismo, y pudiendo utilizar el API del kernel que aunque no es que te lo vaya a dar todo hecho como si fuese el framework de .NET o java, sí que te da lo suficiente para comunicarte con el hardware "fácilmente".

Por si alguien va a venir a decirlo: sí, hay parches para el kernel de linux para ejecutar procesos en tiempo real pero yo no me complicaría, si necesito un robot con mucha potencia y que solo ejecute mi programa lo haría así, como acabo de decir.

Todo esto me recuerda a un mensaje en un foro sobre desarrollo de videojuegos que vi hace un tiempo y que decía algo así como "si necesitas preguntar cómo se hace, es que no sabes lo suficiente para hacerlo, así que mejor olvídalo". Ojo, que esto no se aplica para todo, pero sí es verdad que cosas que requieren mucha planificación/diseño tienes que saber muy bien lo que vas a hacer antes de ponerte a hacerlo, y si necesitas preguntar es que aún no estás listo (si quieres hacer algo decente, claro, chapucillas las puede hacer cualquiera).

Urriellu: No, si pones otro ejecutable no va a funcionar, no es así de simple. ¿De dónde saca las librerías? ¿Qué rutinas usa el programa para IO? ¿Se las saca del sombrero? Poner un ejecutable en lugar del kernel no tiene sentido alguno.

Poder hacer un programa sin SSOO es posible, al igual que es posible ir de Burgos a Murcia pasando por Roma. Y en caso de que lo hagas no vas a sacar partido alguno a la CPU, los SSOO existen por una razón, no es algo que los ingenieros se hayan inventado por enredar.

En un microcontrolador la cosa es distinta, pero en un ordenador... olvídate de lo de no usar SSOO en un ordenador.

Si para los micros un poco 'gordos' (entiendase ARM7 de los más pequeños, o los AVR más grandes) ya se tiende a poner sistema operativo por simplicidad, mucho más para sistemas con muchos más recursos, periféricos y tareas.

He escrito algún sistema operativo para AVR's, y programas multitarea para los mismos, que lo único que hacen es gestionar la ejecución de tareas y el acceso a recursos que se deben compartir entre ellas. Creeme que se hace mucho más fácil usar un sistema operativo para hacer programas relativamente complejos o que funcionen sobre sistemas complejos.

Otro punto que no se aprecia bien al principio, es todo el tema de gestión de memoria virtual y memorias caché, junto con el tema de prioridades asociado a dicho control, el sistema de refresco de las memorias dinámicas, etc.

¿Para qué reinventar la rueda si ya esta todo hecho? No te compliques la vida a no ser que busques cosas muy concretas, tiempo real y esas cosas (me costaría creer que un compatible PC llegue a ser nunca tiempo real...)

Beamspot.

¿De dónde saca las librerías? ¿Qué rutinas usa el programa para IO?

Ni sacas las librerías de ningún sitio ni tienes manera de acceder al hardware fácilmente, porque no hay un kernel que te lo gestione, a no ser que todo eso te lo hagas tú mismo.

Quizás me entendiste mal pero no me refeía a ejecutar directamente desde lilo "un binario cualquiera", sino a los que estén preparados para ello, que básicamente son los que no acceden a ninguna otra librería, osea que no llaman a la API del sistema, y están compilados de cierta manera, etc