OSDev

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

Сообщения отделены отсюда.

Как ассемблерщик со стажем, скажу, что писать всё ж сложней в общем случае. Однако:

1) сложность написания программ на ассемблере по сравнению с ЯВУ в общем же случае сильно преувеличена;

2) сложность применительно к асму чрезвычайно сильно зависит от особенностей системы команд конкретной машины. Например, для VAX-11 писать на асме -- одно удовольствие; на "низкоуровневых" задачах, типичных для кода ОС, по времени написания вообще близко к ЯВУ получается; на PDP-11 -- не шибко хуже, а вот для 8086 -- ужас (я дико матерился в своё время, когда с означенных DECовских машин вынужден был на ПК перейти). Для IA-32 писать уже легче, поскольку многие глупости 8086 сгладили (хотя они и остались на уровне машинного кода), однако писать по-настоящему эффективно достаточно сложно, поскольку необходимо учитывать различные низкоуровневые нюансы работы процессора.

Как ассемблерщик с очень большим стажем работы на ассемблерах i8080, Z80, PDP-11, VAX-11, x86, i8048/51, PIC, никак не могу согласиться с утверждением, что на ассемблере программировать не сложней, чем на ЯВУ.
1. Нет проверки типов, - больше вероятность тонких ошибок.
2. Нет проверки адресов, в т.ч. содержимого стека, - больше вероятность тонких ошибок.
3. Нет контроля зависимости данных со стороны компилятора, - больше вероятность тонких ошибок.
3. Нет гибких языковых конструкций (операторов), - низкая продуктивность.
4. Имеются явные ограничения по аппаратным ресурсам (количество регистров и способы их использования), приходится держать в голове потоки данных, - низкая продуктивность.
5. Нет наглядности и структурности, - низкая продуктивность.
6. Нет объектной ориентированности, - низкая продуктивность.
Конечно хорошая система команд (например, VAX-11) существенно облегчает работу, но даже в этом случае до ЯВУ далеко.

SII, ты с PICами работал? Вот где наматеришься, - работа на x86 блаженством покажется .

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

Самую малость с PIC18 -- наши америкосские партнёры их используют. Вот познакомившись с ними, я и понял, что x86 И IA-32 -- не самые худшие архитектуры в мире, хотя был в этом уверен четверть века ))

Ну а со всем остальным приведённым списком и ещё с некоторыми другими работать приходилось.



По этим причинам не пользуюсь Си/Си++: проверки там откровенно слабые, синтаксис ужасный (особенно у Си++), так что ещё неизвестно, где больше ошибок окажется. Вот асм или Паскаль/Ада -- это уже другой разговор



Не в разы, не в разы. Когда идут сложные вычисления, то п. 3 скажется сильно: записать выражение близко к математике всяко проще и лучше. Однако если в основном проверки битов, сравнения, ветвления и т.п. вещи, то особо большой разницы нет. Грубо говоря if (a == b) или CMP A, B / BEQ Addr -- не слишком большая разница и в читабельности, и в скорости кодирования, и в надёжности.

А вот п. 6 вообще считаю совершенно незначительным применительно к низкоуровневым задачам: не вижу я там места для ООП. Нет, прикрутить-то можно, это и ежу понятно, но зачем? "Ради концепции"? Ну дык это уже религиозный вопрос...

С одной стороны, проверка типов всё же есть и не настолько уж слабая. Указатель с числом не перепутаешь. С другой стороны, синтаксис - это уже из области субъективизма. Мне их синтаксис нравится. Речь же о ЯВУ в целом.


Посчитать "разы" не представляется возможным без специального исследования. Однако разница всё же заметна.


В простом случае, да. Но достаточно вспомнить, что a и b могут быть разных типов и компилятор их самостоятельно приведёт к общему типу. Ещё, они могут быть обе на стеке и для сравнения нужно не ошибившись адресом загрузить их в свободные (!) регистры. Ещё можно вспомнить понятие "структурное программирование" и понять, что ассемблер - это 100% возврат к goto.


Во-первых, тут пока не разделяли задачи на низкоуровневые и высокоуровневые. Во-вторых, при разработке ОС могут возникать и вполне высокоуровневые задачи, например, работа планировщика с нетривиальными алгоритмами и очередями.

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

В каком смысле за базу взят? СhromeOS - на ассемблере?


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

С другой стороны трудоемкость написания на ассемблере высокая. Программист пишет в единицу времени примерно одинаковое количество строк. Не важно на каком языке. Строки в ассемблере не сильнофункциональные в прикладном смысле. С точки зрения системной, как раз наоборот. Программа на ассемблере напоминает высокоуровневую программу с большим количеством глобальных переменных (регистры). Каждая операция в программе эти переменные меняет. Код с большим количеством переменных писать трудоемко, чревато ошибками и не производительно. Такой стиль программирования ни к чему хорошему не приводит. Поэтому ассемблером стоит пользоваться только в случае невозможности использовать что-то иное.

Еще один аспект. Сопряжение с чужим кодом. Языки высокого уровня привносят в код т.н. Calling Conventions. Что упорядочивает код и по-крайней мере пытается внести упорядоченность в сопряжение одного кода с другим. Поверх Calling Conventions ограничения накладывают форматы объектных файлов и т.д.

Ассемблер предоставляет наинизший (наихудший) уровень совместимости и сопрягаемости. На ассемблере писали первые поколения операционных систем. На тех же мейнфреймах ОС была на ассемблере, MS DOS был писан на ассемблере по большей части по крайней мере.

Язык Си следующий шаг по сравнению с ассемблером. Он предоставляет совместимость на уровне исходного кода. На нём написано подавляющее большинство системного кода на сегодняшний день. На самом деле между голым Си и ассемблером очень мало прогресса. У Си есть проблемы - он достаточно примитивен, чтобы на нём было писать быстро. Но при всей своей примитивности Си достаточно сложен, чтобы компилятор с него был достаточно сложным (отнимал много процессорного времени на компиляцию). Поэтому следующий шаг развития языков высокого уровня - языки с виртуальными машинами.

Виртуальная машина может быть не обязательно интерпретируемой. Она может быть средством обеспечения переносимости. А на target платформе компилироваться в native - код. Пример LLVM. Виртуальные машины позволяют существование нескольких высокоуровневых языков программирования, компилирующихся в одинаковый код виртуальной машины. На конкретной платформе код виртуальной машины может компилироваться в native-код. Байт-код виртуальных машин значительно проще компилировать, чем язык высокого уровня, поэтому компилировать байт-код в native можно либо c помощью предварительной компиляции, либо с помощью JIT.

За счет байт-кода (виртуальной машины) Java имеет уровень совместимости - "один раз скомпилировал - работает везде"... Код совместим не только на уровне исходников, но и на уровне скомпилированного байт-кода. Это ведет к высочайшему уровню совместимости разных библиотек и тулкитов.
Что и приводит к тому, что найти в интернете необходимый фрагмент кода на Java чаще всего ничего сложного не представляет. Сложности возникают только с какой-нибудь малоиспользуемой экзотикой или чем-нибудь очень современным и малораспространенным... (пока). Сегодня, правда, с появлением Android, появилось большое ответвление Java, что не радует. Назвали бы её по-другому... чтобы не нарушать принципа.

Ещё одна проблема с написанием операционных систем - отсутствие большого количества проработанных архитектур. Причем большая часть из того, что есть базируется на Си. Чем руководствуются разработчики операционных систем на ассемблере вообще загадка.

Хулиганский Hello World на ассемблере:



Или что-нибудь наподобии:



Ассемблер это позволяет. Почему бы все это не использовать в коде?

UNIX по сравнению с операционными системами на ассемблере - это продуманная архитектура. Пусть и устаревшая местами, но в классическом её виде элегантная как сам Си.

Тем не менее, прогресс не стоит на месте. Думаю наиболее интересными разработками на сегодняшний день являются эксперименты вроде Mona или (присутствущий на этом форуме) Phantom OS.

P.S. Сорримногобукв. Пока писал, тред уже разросся.

Легче программировать в Паскале. Этот язык создавался для обучения с нуля и у меня остались о нём только хорошие воспоминания. Но жизнь сурова и ассемблер вне конкуренции в практических задачах. На лицо ситуация со всеми ЯВУ как в одном юмористическом фантастическом рассказе , там описывается ситуация когда построили такой большой космический корабль, что пришлось строить ещё один, что бы летать внутри большого. Если допустить что самая лучшая ОС (идеальная) уже есть, то всё равно мы будим делать другие. Человеку свойственно. Полезно иногда ставить всё под сомнение. Лично у меня вопрос вообще ко всем - почему так важна производительность?. Пора менять приоритеты. Выдвинуть на первое место внутреннюю логичную гармоничную архитектуру ОС. Это опорная точка для всех последующих вопросов и ЯВУ против асма здесь ни чем не лучше. Для описания ОС надо другой язык, наверно.
В своей "H2O" я пробую писать вообще почти в машинных(для моей ВМ) кодах.

Половину сообщения achesnokov вообще не понял: при чем тут виртуальные машины? Писать ось на Жаве/.NET? Можно, конечно. Написать интерпретатор или JIT-компилятор для ВМ, а потом городить огород, пытаясь работать с железом инструментами, сделанными специально, чтобы быть как можно дальше от железа. Можно и из Москвы в Петербург ехать через Владивосток.
Про Calling Conversions - не знаю, что мешает использовать те же cdecl или stdcall на асме. Я сам использую в своей оси (где ядро на асме) STDCALL для всех внешних интерфейсов. А ручной вызов мелких внутренних функций с передачей параметров через регистры только повышает производительность, и, ИМХО, читаемость (если конечно регистры использовать примерно одинаково везде).


На современных ПК, с одной стороны, толку мало. С другой, чем меньше времени ест ОСь, тем больше времени приложениям, и это может быть очень заметно под нагрузкой.
А если говорить о других архитектурах, то там как раз бывает очень важно. Стоит например у какого-нить МК тактовый генератор на 8 МГЦ. Тут вручную с карандашом и бумагой будет быстрее все операции делать, чем ждать их выполнения на какой-нибудь навороченной виртуалке. Слышал, как-то написали ради интереса виртуалку под такой МК и запустили Linux Ubuntu на ней. "Лого" висело порядка двух часов.


Архитектура ОС от языка не зависит. Архитектура - это устройство, а язык - инструмент реализации устройства. Просто на одном языке одна и та же архитектура будет состоять из "многобукаф", а на другом - намного короче.

Мое мнение - кто на чем хочет, на том и пишет. В ОСДеве от ЯВУ остаются только длинные арифметические выражения и типизация. Мне не попадалось таких выражений, которые было бы прям очень трудно расписать на асм. Для меня из плюсов остается типизация. Однако на асме проще и понятнее работать с памятью и видно код "как есть". Так что для меня асм тоже (как для ТС) является более хорошим выбором.

[OFFTOP]

Вспомнилось:


[OFFTOP2]
Сначала придумали много архитектур железа. Потом репу почесали - "Че-то не то. Надо сделать виртуалку, которая покроет все архитектуры". Сделали 5-10 виртуалок, не совместимых между собой. Потом скажут "Точно! Надо сделать виртуалку на виртуалках!" и сделают еще 5 виртуалок, по-разному объединяющих существующие
[/OFFTOP2]

Bargest, здесь можно спорить до бесконечности. Каждый прав по своему. Спасибо за мнение.Если не трудно ответьте на один вопрос , только одним предложением. Какая главная задача операционной системы? Я так думаю что очень разные будут ответы. Просто я хочу от ОС - свою платформу для своих программ.

ИМХО главная задача ОС - прослойка между железякой и приложениями, чтобы производители ПО не думали, на каком оборудовании будет работать их программа и какие еще проги будут запущены на компьютере пользователя.