Хочу щоб код на С++ працював.
Хоча вiн працювати може (g++ ворк), але без видiлення пам'ятi.

Ну керувати розподiлом пам'ятi i без нього ?

ну звісно, що не можна впяти, то можна зпрограмувати, програмісти іноді пишуть і свої аналоги free, malloc.

Читав вже... Але не зрозумiло як воно може отримати вмiсть пам'ятi, якщо вона разкидана не по порядку.
Як я зрозумiв:
------Вiльно 1 ------ ||||||||Зайнято 1 |||||||| ||||||||Зайнято 2|||||||| ------Вiльно 2------ ||||||||Зайнято 3 ||||||||
Потрiбно в malloc знайти такi вiльнi дiлянки i в них записувати.
Але як зробити це....
malloc поверне "Вiльно 1", а треба щоб при виходi з нього наступний елемент масиву був на дiлянцi "Вiльно 2".
Але як таке зробити ?
Теж саме з читанням пам'ятi.
Чи я не так зрозумiв ?

А оце почитали? https://wiki.osdev.org/Memory_Allocation

ос, яка сама б писала драйвери? ліл

Тут є одна велика біда — поцесори різні. Команди, коди команд. Тобто ця ОС просто не завжди зможе стартувати, бо мають виконатися конкретні команди її початку, а вони можуть не підійти до конкретного процесора.

Менші біди — апаратура. Навіть при однакових процесорних ядрах є різна апаратура, наприклад, контролер пам'яті. Який потрібно проініціалізувати для того, щоб взагалі ОС кудись потрапила.
На те є різні біоси та ROM code в SoC, вони це ініціалізують, і лізуть беруть вже початковий завантажувач від ОС (той же GRUB, він вже завантажувач останнього етапу, перед ним декілька могло бути в ланцюжку), записують його в проініціалізовану пам'ять і запускають.
Але ж — див вище — завантажувач повинен бути правильного коду. І повинен знати про пристрій, з якого завантажують, хай навіть той пристрій проініціалізований BIOS/ROM code.
То що — мати на носії десятки завантажувачів ОС під різні архітектури і навчити ROM-код знаходити потрібний по якихось індексах?
А потім вся купа драйверів іншої апаратури та іншого коду ОС — це все там мати так само у тих десятикратних кількостях?

Ну спосіб є, і він якраз не з даного етапу, а з попередніх.
Open Firmware від Sun — у них у одних було декілька різних архітектур процесорів, то на периферійних картах в ROM окрім деякого опису пристрою у стандартизованому форматі (попередник device tree в Linux, а функції ядра для роботи з ним досі мабть префікс of) був початковий код роботи — ініціалізація плати, те-се — написаний на Forth, ну тобто відповідний байт-код.
Тобто десь на рівні мабуть ROM-завантажувачів материнських плат був інтерпретатор Forth, який вичитував з усіх карт їхні ініціалізатори, виконував, складав у дерево пристроїв, знаходив серед них контролер диска і з вантажив систему.
От вона вже була на рідному коді від того процесора, що стоїть, її ж таку інсталювали. І вона вже чи в собі шукала потрібний драйвер, чи перекомпільовувала байт-код форта в ріжний код процесора — не знаю, глибоко ні ліз читати.

Тобто рішення — байт код (Forth, Java, ... ?) драйверів в усій периферії.
Сам завантажувач від ОС і початок ОС на тому ж байт-коді.
Інтерпретатор в ROM материнської плати.
В інтерпретаторі інформація про архітектуру процесора, частково намертво в коді (він же в ROM плати, він щось знає), частково потім розбирає на ходу (нюанси x86<->x86-64, наприклад).
Ну а нормальні JIT-компілятори що байт-коду з периферійних плат, що самої ОС — на носії в тілі ОС, і множити на десятки архітектур треба лише ці компілятори. Тоді є шанс запхати все на носій якогось притомного обсягу.

Тільки от завантажуватиметься воно повільніше, та й працюватиме теж не так швидко.
Тому простіше інсталювати на конкретний комп'ютер збірку ОС під конкретну архітектуру центрального процесора, покриваючи варіації пристроїв інформацією з BIOS/ROM code (device tree/acpi/etc)

Все ніби можна. Але корпорації. Згадаємо як доказали що амд робило так що не бачило відеокарти від конкурентів

Краще писати ОС на фасм асемблері.