OSDev

В моём транслятора асма для арм, который я упоминал, в файле Reader.cpp -- 582 строки (ещё 154 в его заголовочном файле, но тут следует учитывать, что у меня весьма много комментариев и пустых строк); в нём сосредоточен весь код для чтения физических файлов (используются стандартные потоки це++ в лице std::basic_ifstream). Входные файлы (т.е. исходный ассемблеровский и включаемые в него файлы; поддержки макробиблиотек пока нет, хотя и планируется) считаются закодированными в UTF-8 (наличие марки UTF-8 в начале файла проверяется, но и при её отсутствии я считаю, что файл именно в этой кодировке -- ибо нефиг не поддерживать уникод ). Файл всегда считывается целиком в оперативу и остаётся там до конца трансляции -- никакой оптимизацией я даже близко не занимался, так как считаю, что сначала следует довести транслятор до полностью работоспособного состояния и реализовать всё, что нужно, причём обкатать на практике, и лишь затем думать о тотальном рефакторинге: уже будет понятно, что и как работает, что с чем связано и т.д. и т.п.

В этом же файле у меня сейчас находится запись файлов зависимостей (.d) для автоматического их формирования, чтобы сборку ассемблерных проектов можно было на обычном make сделать (я не стал -- пока, во всяком случае, -- делать их в отдельном файле, банально чтоб не плодить число файлов, ну а дальше видно будет). Для вывода там std::basic_ofstream. Мне потоки, честно говоря, не нравятся, и я предпочёл бы просто функции блочного ввода-вывода, но не нашёл, как использовать уникодовские имена файлов не зависящим от платформы способом, т.е. в полном соответствии со стандартом це++, а не всякими зависящими от винды/линуха или ещё чего способами.

Токены (лексемы -- всякие там идентификаторы, числа, спецсимволы) из исходного текста выделяет Lexer.cpp длиной 979 строк, его заголовок -- 354 строки, треть которых -- определение структуры TOKEN, которая и описывает очередной полученный токен. Есно, тоже всё написано без малейшей претензии на оптимизацию. Лехер получает у Реадера очередную строку исходного текста, причём Реадер преобразует её из UTF-8 в UTF-32 -- вся работа с текстом, внутренние имена и т.д. и т.п. у меня хранятся именно в UTF-32 для упрощения работы с символами. Понятно, что памяти на это уходит немеряно, но для черновой версии сгодится -- оптимизация усложняет, запутывает и т.д. и т.п., поэтому ну её нафиг в альфа-версии

Так что Йодовские 1000 строк на лексический анализатор выглядят вполне правдоподобными: его функции не сильно зависят от исходного языка и вряд ли могут вызвать изменение объёма потребного кода в 10 раз. А вот зачем 10К строк в Кланге, мне пока непонятно

Один из самых крупных файлов у меня -- Expr.cpp, 3034 строки в нём и 189 в заголовке. Он получает токены и разбирает выражение, сохраняет его в стеке выражения для последующего вычисления, а также выполняет его вычисление -- т.е., по сути, реализует две связанные, но не зависящие друг от друга вещи. Реализован пока не полностью: нет обнаружения и вычисления встроенных функций, которые могут использоваться в выражениях. Плюс, вычисления с плавающей запятой вынесены в отдельный файл, но пока не реализованы (сделан лишь тип, хранящий вещественные числа -- тоже в не зависящей от конкретного проца виде, плюс поддерживаются и двоичные, и десятичные вещественные -- последние есть, в частности, в z/Architecture -- добавлены туда вместе с их добавлением в IEEE 754).

Генерация эльфа под арм32 из образов программных секций и таблиц символов, сформированных в процессе трансляции (есно, опять никакой экономии: всё лежит в ОЗУ до завершения работы), у меня заняла 1623 строки -- включая запись уже накопленной отладочной информации (по сути, информацию о номерах строк). Вроде как работает корректно, но это надо интенсивно тестировать, а пока руки не доходят: работа появилась, которую работать надо.

Всё убила узкая специализация ...
Переусложнение, торможение роста железа - некая стагнация, в которой все принялись бурно имитировать и забурились в эти самые миллионы строк кода. В результате переусложнения всегда теряется универсальность - человеческий мозг просто не справляется с общей картиной.

Когда вещи были проще - подход определённо был более системным.

Ну, вот - ватком, к примеру ... вполне себе "платформо-независимый компилятор". Т.е., там доделывают нормальную версию 2.0, а не то глючное чудо, которое "выкатили" сколько-то лет назад ... и они собирают её ради развлечения в bsd, полуоси, итд, итп ...

Он писался с расчётом работы на "голом железе", в итоге дефолтная C++ либа, которая обрабатывает всё компиляторо-зависимое линкуется вообще без своего C-шного рантайма. Она хочет из него, кажется, только exit().

И это чудесно - лёгким движением руки оно линкуется в совершенно левый проект с собственным рантаймом и в итоге плюсы становятся удобным и доступным средством.
Это нормально, но кто-то должен был следить за этим во время разработки.
Когда вещи усложняются - про такие тонкости забывают в первую очередь.

Другой пример - NT. Ядро, NTFS, подсистемы, итд, итп ... Какой это год - 92? Больше 30 лет они живут на этом коде, весь мир живёт. Навешивают на него килотонны глупых рюшечек, а он держит. Удивительно.
Написал бы кто-то сейчас такое же? Нет.
Именно поэтому - переусложнение, сужение кругозора. Скорее всего уже нет ни архитекторов, ни кодеров которые породили бы нечто столь универсальное.

Ну и хаос железа, конечно ... То же самое переусложнение.
Вы либо принимаете чью-то модель драйверов и эмулируете её, либо остаётесь ни с чем. В итоге все и упираются в "очередной юникс".
Это самый страшный подарок человечеству от некоего финна

Почему я у себя и отказался от драйверов вообще
Концепция работы на BIOS или EFI имеет минусы, но для одного человека она разумна. Можно сделать кучу других интересных вещей - если не забуриться в ahci или usb с головой Однопроцессорная многозадачность как работала в 80-х, так работает и сейчас И на ней делали много разного, если вспомнить.

Это просто способ не свалиться в это самое переусложнение, которому требуются тысячи кодеров и миллионы их часов и строк кода.
Мозг реагирует на переусложнение желанием отключиться и сбросить задачу с плеч - так проекты и умирают
Надо просто ловить этот момент и сворачивать на другой путь, чаще всего он есть ....

Именно. "Начало конца" — это когда проект не умещается в голове, тогда начинается взрывной рост объёма когда. Но даже в этих условиях я не могу понять, почему apk пакеты многих приложений с весьма простым функционалом занимают в РуСторе по 200 мегабайт.


IMHO, драйверы всё же желательны, но для того "оборудования", которое входит в состав распространённых виртуальных машин. Всё же BIOS — довольно ограниченная по функционалу, тормознутая и кривая прослойка. А в целом я согласен, поддержка UEFI потенциально даёт возможность работы без драйверов, т.е. упрощает разработку.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

BIOS вообще для полноценного ввода-вывода не годится от слова совсем. Что ж до UEFI, я с ним не работал, но, кажется, он чисто 32-разрядный? И поддерживает ли он асинхронный ввод-вывод? Переключать процессор туда-сюда -- не дело, если нужна нормальная система, без асинхронщины нормальный ввод-вывод тоже не получится.

Ну, как-то, ведь, Win 3.11 работала - и неплохо работала
Диски, даже в PIO режиме - вполне себе бегают и резвятся. Т.е., падение скорости не в разы. USB девайсы эмулируются, пусть и медленно и печально. Интерфейс с юзером сделан для работы, а не для галочки.

Ну, простой пример - клон NC(фара). * на клавитуре добавляет её в командную строку, * на нумпаде инвертирует выбранные файлы в панели. В биосе, разумеется, разные коды для * на клавиатуре и нумпаде. В EFI отдельного кода нет. Никто просто об этом не подумал.

Вообще, EFI существует строго для того, чтобы загрузить Windows
Все остальное через задницу по определению, поскольку никто это не тестирует. В этом коренное отличие от BIOS, в котором работали. Эпоха DOS - это добрых лет 15 ...
Идея EFI, возможно, была хорошей, но получилось "как всегда"

Разрядность в EFI зависит от платформы - 64 или 32. Асинхронности скорее нет, чем есть, но она там и не нужна - учитывая руки кодеров, пользоваться было бы нельзя (поскольку этим не пользуется загрузчик Windows, да).

В любом случае - работа *только* через BIOS/EFI - это такой осознанный выбор, который позволяет грузиться везде, а не только в VM Наверно можно было бы добавить те же драйвера для ACHI, например - но реальный опыт использования пока не требует этого вот прям сильно.

Т.е., быстродействия современного железа вполне хватает, чтобы в одной сессии искать по диску (или копировать), а в другой спокойно что-то делать.

Понятно, что для "нормальной ос" это не вариант, но тут оно вообще выросло из однозадачного dos-подобного загрузчика за 15 лет Отсюда и подход.

p.s. с наступающим

Плохо она работала, плохо.



Вопрос не в скорости обмена, а в том, что необходимо стоять и ждать завершения операции, а не работать себе дальше полностью параллельно с вводом-выводом.



Ну, я Вашу идею понял, и как один из возможных вариантов -- вполне, хотя он и далёк от совершенства (в силу далёкости от него BIOS/UEFI).



О чём, собсно, и речь

Собсно, ввод-вывод -- самая сложная часть в любой настоящей оси на почти любой архитектуре. Единственное известное мне исключение -- мэйнфреймы IBM (Система 360 и её наследники вплоть до современной z/Architecture), но в силу их уникальной организации ввода-вывода на уровне железа, из-за чего программировать его легко и просто. По этой причине на моей меганедооси начала 1990-х, работавшей на ЕС-1035, а позднее под виртуальной машиной на ЕС-1130, основные устройства уже на базовом уровне поддерживались и даже была сделана полноценная виртуальная память. (А на виртмашине на ЕС-1130 приходилось работать потому, что у меня в качестве консольного терминала поддерживалась только пишущая машина, а у ЕС-1130 её уже не было; дисплеи же прикрутить банально не успел: реализовав базовый ввод-вывод -- пишмашку, вывод на печать, ввод с перфокарт, ввод-вывод на магнитных лентах и дисках -- я перешёл к развитию собственно системы, оставив остальной ввод-вывод "на потом"). Чтоб такое поднять на персоналке, требуется в 100500 раз больше труда Но у мэйнфреймовского ввода-вывода есть и обратная сторона: негибкость и неопределённость в задержках, поэтому, например, ногодрыг в стиле микроконтроллеров на нём не сделаешь (т.е. сам-то контроллер GPIO спроектировать и прицепить к каналу ввода-вывода несложно -- но не будет никаких гарантий с задержками в операциях и т.д. и т.п., даже если скорость работы собственно процессора ты способен просчитать буквально по тактам). В общем, он превосходит общепринятый в виде регистров в адресном пространстве в плане простоты программирования, а зачастую -- и пропускной способности (недаром мэйнфреймы ворочают гигантские базы данных), но уступает в гибкости и универсальности.

UEFI, чисто понятийно/терминологически, это тоже BIOS. Безусловно, старый 86 БИОС (для различения его иногда называют PC-BIOS) не годится ни для какого ввода/вывода, только как последнее средство, когда ничего другое не работает. И то, не в 64-битной ОС.
Да, UEFI 32-битный. Мало того, он сам переводит процессор в защищённый режим и даже может самостоятельно грузить правильное ядро системы в зависимости от архитектуры процессора при условии наличия EFI раздела на диске. В принципе, он как раз и разрабатывался с целью не только загрузки ОС, но и предоставления драйверов ряда устройств через свой интерфейс, т.е. в теории он вполне может предоставить базовую поддержку для ОС. В реальности сильно сомневаюсь, что эта поддержка интенсивно проверяется, даже в полноценных драйверах присутствуют печальные ошибки, которые иногда вообще не исправляются производителем.

PS
С наступившим!

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>