OSDev

для всех
Текущее время: 10 дек 2018, 16:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 73 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.
Автор Сообщение
 Заголовок сообщения: ASM vs ЯВУ
СообщениеДобавлено: 28 май 2012, 20:25 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1197
grindars писал(а):
И почему ядро на асме, а не на ЯВУ?
Народ, я молча наблюдал подобную риторику в нескольких недавних постах, но на асме писать не сложнее, чем на Си, если умеешь это делать - в пользу Си могут сыграть другие, дополнительные, требования к коду, но это только, если они есть. Хотя действительно прозвучавшие здесь слова "асм" и "портировать" явно не стыкуются.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 28 май 2012, 20:40 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1357
Откуда: Зеленоград
phantom-84 писал(а):
Народ, я молча наблюдал подобную риторику в нескольких недавних постах, но на асме писать не сложнее, чем на Си, если умеешь это делать - в пользу Си могут сыграть другие, дополнительные, требования к коду, но это только, если они есть. Хотя действительно прозвучавшие здесь слова "асм" и "портировать" явно не стыкуются.


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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 28 май 2012, 22:14 
Аватара пользователя

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

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

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 28 май 2012, 22:24 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1357
Откуда: Зеленоград
Yoda писал(а):
SII, ты с PICами работал? Вот где наматеришься, - работа на x86 блаженством покажется :D.


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

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

Цитата:
1. Нет проверки типов, - больше вероятность тонких ошибок.
2. Нет проверки адресов, в т.ч. содержимого стека, - больше вероятность тонких ошибок.
3. Нет контроля зависимости данных со стороны компилятора, - больше вероятность тонких ошибок.


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

Цитата:
3. Нет гибких языковых конструкций (операторов), - низкая продуктивность.
4. Имеются явные ограничения по аппаратным ресурсам (количество регистров и способы их использования), приходится держать в голове потоки данных, - низкая продуктивность.
5. Нет наглядности и структурности, - низкая продуктивность.
6. Нет объектной ориентированности, - низкая продуктивность.


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 28 май 2012, 22:56 
Аватара пользователя

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

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

SII писал(а):
Не в разы, не в разы.

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

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

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

SII писал(а):
А вот п. 6 вообще считаю совершенно незначительным применительно к низкоуровневым задачам: не вижу я там места для ООП.

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

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 28 май 2012, 23:29 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
Цитата:
За базу взят ChromeOS. О подробном функционале - в прикреплённой теме.


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


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

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

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

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

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

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

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

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

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

Код:
   mov si, hello
   call print_msg
hello:
    db 'Hello',0
    mov si, world
    call print_msg
world:
    db 'World',0
    ret
print_msg:
  mov ah,0xe
  int 0x10
  pop si
  lodsb
  push si
  jnz print_msg
  ret


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

Код:
getcodeaddr:
   call $+3
   mov ax,[sp+2]
   ...


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

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

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

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


Последний раз редактировалось achesnokov 29 май 2012, 09:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 28 май 2012, 23:34 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Ассемблер vs ЯВУ
СообщениеДобавлено: 29 май 2012, 00:29 

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

Цитата:
почему так важна производительность?

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

Цитата:
Пора менять приоритеты. Выдвинуть на первое место внутреннюю логичную гармоничную архитектуру ОС.

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

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

[OFFTOP]
Цитата:
За счет байт-кода (виртуальной машины) Java имеет уровень совместимости - "один раз скомпилировал - работает везде"

Вспомнилось:
Цитата:
Saying that Java is good because it works on all platforms is like saying anal sex is good because it works on all genders

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 29 май 2012, 00:48 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ответы на вопросы
СообщениеДобавлено: 29 май 2012, 00:55 

Зарегистрирован: 31 окт 2011, 18:20
Сообщения: 230
Цитата:
только одним предложением. Какая главная задача операционной системы?

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 73 ]  На страницу 1, 2, 3, 4, 5 ... 8  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB