OSDev http://osdev.su/ |
|
ASM vs ЯВУ http://osdev.su/viewtopic.php?f=18&t=567 |
Страница 7 из 8 |
Автор: | SII [ 31 май 2012, 17:33 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
Станислав писал(а): Например такой вопрос, что будет быстрее, послать команду чтения сектора и создать бесконечный цикл с ожиданием от контроллера о выполнении, или выйти и ожидать прерывания от контроллера? Второй вариант кажется менее болезненный для процессора, он не вешает бесконечный цикл, но труднее реализуется, так же нужно думать о том, что процессор в режиме ожидания находится тоже в бесконечном цикле и на скорость не влияет, прерыванию с высшим приоритетом он не мешает. Про прерывания сказано, что они останавливают процессор и выполняются полностью, после чего возвращают управление старой команде, т.е. циклу с проверкой готовности чтения сектора. Причём само чтение не использует процессор, а чтение например видео файла размером 8Гб идёт блоками(прочитал блок, вывел на экран, в это же место прочитал ещё блок), причём в это же время видео карта и звуковая карта получили пакеты на воспроизведение из памяти, и параллельно запущено много команд похожих. Такое впечатление, что Вы не слишком хорошо понимаете работу прерываний. Сами по себе они не "останавливают" процессор, не возвращают управление и т.д. Собственно прерывание лишь сохраняет состояние процессора (адрес команды и регистр флагов, если склероз не изменяет -- в разных архитектурах это несколько различается, хотя общий смысл везде одинаков) и вызывает тот или иной обработчик прерывания -- и всё. Остальное реализует обработчик, а он может сделать всё, что нужно. |
Автор: | Станислав [ 31 май 2012, 17:55 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
SII писал(а): Такое впечатление, что Вы не слишком хорошо понимаете работу прерываний. Сами по себе они не "останавливают" процессор, не возвращают управление и т.д. Собственно прерывание лишь сохраняет состояние процессора (адрес команды и регистр флагов, если склероз не изменяет -- в разных архитектурах это несколько различается, хотя общий смысл везде одинаков) и вызывает тот или иной обработчик прерывания -- и всё. Остальное реализует обработчик, а он может сделать всё, что нужно. а выходим из обработчика iret эта инструкция отличается от "ret" в том, что она также выводит из стека флаги в регистр флагов. Кстати это отличие между call и int 1 |
Автор: | D-S [ 09 июн 2012, 22:44 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
achesnokov писал(а): Для асинхронного ввода-вывода нужны потоки. В классическом юниксе их и не было. Практика разработки показала, что системы, реализованные на базе классической однотредовой реализации, в разы надежнее, чем аналогичные более поздние реализации. Так например случилось с QNX4 и QNX6. QNX конечно своеобразная операционная система. QNX6 от QNX4 отличается прежде всего многотредовостью от природы. В QNX4 все было однотредовым. Системы на базе QNX4 намного надежнее, чем на базе QNX6. Другой надежной однотредовой системой был SCO UNIX. В нем тоже не было никаких тредов. SCO UNIX в то время как у FreeBSD был аптайм пол месяца, не перегружался годами. Не согласен в корне. Очень много занимался Novell NetWare. Админил, писал всякие мелочи. В ней были потоки и работала она без перезагрузки годами. Рекорд - помню показывали на Brainshare фотку с консоли экрана, где аптайм был более 5-ти лет. Она стояла в каком-то игорном заведении. Это в России, в остальном мире - возможно есть и большие достижения. Вообще ОС была своеобразная (одна корпоративная многозадачность чего стОит), но были в ней фичи, которых в других или не было вообще, или появились намного позднее (SFTIII, распределенная база данных объектов). SFTIII так кстати никто повторить не смог (только аппаратными решениями), а это реально работало! Сошла со сцены эта операционка, когда попыталась стать как все. С выходом 5-й версии в самом конце 90-х появилась джава, вместо SFTIII - кластеры и стендбай серверы, упала скорость работы и надежность (в этом кстати очень часто винили аутсорсинг разработки) и клиенты стали массово мигрировать на 2000-й. Что касаемо основной дискуссии, то позвольте мне как ассемблерщику с достаточным стажем высказатся за языки высого уровня. По моему мнению любой крупный ассемблерный проект неминуемо хоронит сам себя. Реально - у проектов на ассемблере два достоинства - компактность кода и более высокая скорость работы. Всё это было обязательно в 80-е и раньше, желательно в 90-е, а сейчас не востребовано т.к. память и процессоры стоят дешево, Требования теперь другие - переносимость, скорость разработки и легкость сопровождения проекта (то что в наше время стоит дорого). Всего этого на ассемблере не добится. Хороший код системы - тот, который для аппаратно независимых частей одинаковый для всех процессоров (в идеале - для 32 и 64 битных). Как это сделать на ассемблере? |
Автор: | Станислав [ 10 июн 2012, 05:19 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
D-S писал(а): Что касаемо основной дискуссии, то позвольте мне как ассемблерщику с достаточным стажем высказатся за языки высого уровня. По моему мнению любой крупный ассемблерный проект неминуемо хоронит сам себя. Реально - у проектов на ассемблере два достоинства - компактность кода и более высокая скорость работы. Всё это было обязательно в 80-е и раньше, желательно в 90-е, а сейчас не востребовано т.к. память и процессоры стоят дешево, Требования теперь другие - переносимость, скорость разработки и легкость сопровождения проекта (то что в наше время стоит дорого). Всего этого на ассемблере не добится. Хороший код системы - тот, который для аппаратно независимых частей одинаковый для всех процессоров (в идеале - для 32 и 64 битных). Как это сделать на ассемблере? Есть алгоритм решения задачи, а есть компиляторы, транслятора, со своим лексиконом для их реализации. Мне проще писать на фасме, я могу написать на нём всё и собственно это и делаю для ОС, мне на нём проще, а теперь я убедился, что тем, чем пользуюсь в асме(конструкции командами) в других языках не сделать. В ОС есть разные объекты у которых есть переменные и адреса функций её, ссылки на другие объекты(вообще продуманные объекты в ОС это её 90%, с ними можно интересные вещи делать), так вот ссылка на объект обязательно должна быть в регистре, например ebp, а пользоваться её функциями нужно читая её адрес со смещением на неё, по пути цеплять в регистры данные её как параметры, и вызывается call dword[ebp+?]. Это похоже как в дельфи пишут типа Form.Canvas.paint. объект форма имеет много типов функций переменных, канвас тоже самое и вызывают функцию паинт. Но языки ариентированы на винду, а мы пишем свою ОС. |
Автор: | 418ImATeapot [ 10 июн 2012, 14:19 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
Станислав писал(а): Это похоже как в дельфи пишут типа Form.Canvas.paint. объект форма имеет много типов функций переменных, канвас тоже самое и вызывают функцию паинт. Но языки ариентированы на винду, а мы пишем свою ОС. Это не винда, это дельфи. Точно так же можно написать и под Нет (будет работать почти везде) и под лазарус (опять же, будет работать почти везде). Сама винда об этих заморочках ничего не знает, она построена на динамических библиотеках, а не на ООП. Form.Canvas.paint - это не элемент ОС (и, кстати, не элемент языка). ЯВУ, кстати говоря, редко бывают ориентированы на какую-то одну ОС. Если язык завязан на ОС или архитектуру, то это либо не ЯВУ, либо плохой ЯВУ (я не имею в виду всякие batch/shell/AREXX/etc - на них же ОС писать не станешь ). D-S писал(а): Хороший код системы - тот, который для аппаратно независимых частей одинаковый для всех процессоров (в идеале - для 32 и 64 битных). Как это сделать на ассемблере? Все это верно для компонентов, которые действительно платформонезависимы (TCP/IP, проверка прав доступа, отрисовка окошка). Их, ИМХО, следует писать только на ЯВУ (написать тут что-нибудь внятное на ассемблере - малореально. Смотри КолОС, как негативный пример.). Но какой смысл в портируемом коде обработчика страничного сбоя или переключателе контекста? ИМХО, это лучше и проще писать на АСМ. ЗЫ-ИМХО: если портируемость не нужна, качество языка определяется временем, через которое программа в руках незнакомого с code formatting превращается в кашу. В этом смысле ассемблер - самый худший язык (а самый лучший - питон, но на нем ОС, к сожалению, не напишешь). |
Автор: | Станислав [ 10 июн 2012, 15:07 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
418ImATeapot писал(а): Это не винда, это дельфи. Точно так же можно написать и под Нет (будет работать почти везде) и под лазарус (опять же, будет работать почти везде). Сама винда об этих заморочках ничего не знает, она построена на динамических библиотеках, а не на ООП. Form.Canvas.paint - это не элемент ОС (и, кстати, не элемент языка). ЯВУ, кстати говоря, редко бывают ориентированы на какую-то одну ОС. Если язык завязан на ОС или архитектуру, то это либо не ЯВУ, либо плохой ЯВУ (я не имею в виду всякие batch/shell/AREXX/etc - на них же ОС писать не станешь ). Объект Form про которую говорил это объект винды, который больше ни где не используется, такими конструкциями в Дельфи можно пользоваться и в других ОС с другими объектами, но как идёт работа не понятно. КоОС мёртвая и ни кто её не пишет, но кто вам мешает написать лучше, а если напишут на фасме хорошую ОС вы что скажете, "этого не далжно быть", а теоретически это возможно на 100%. Кто мне помешает написать проверку TCP/IP на фасме, причём если во всех ос будет одинаковая проверка, то взламываться тоже будут одинакова |
Автор: | 418ImATeapot [ 10 июн 2012, 15:23 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
Станислав писал(а): Объект Form про которую говорил это объект винды, который больше ни где не используется, такими конструкциями в Дельфи можно пользоваться и в других ОС с другими объектами, но как идёт работа не понятно. --- КоОС мёртвая и ни кто её не пишет, но кто вам мешает написать лучше, а если напишут на фасме хорошую ОС вы что скажете, "этого не далжно быть", а теоретически это возможно на 100%. ОБЪЕКТ Form - это объект библиотеки делфи. Внутри него реализован доступ к Windows API. Windows API не объектно-ориентированая (по крайней мере, снаружи). А в лазарусе оный объект реализует доступ например к QT. --- Теоретически, существует код написанный на ФАСМ, реализующий "хорошую" ОС, тк ФАСМ - Тьюринг-полный. Но не факт, что есть на свете программист, способный этот код написать . (Я не говорю что это априори невозможно. Но ОЧЕНЬ тяжело и главное - бессмысленно.). |
Автор: | Станислав [ 10 июн 2012, 16:02 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
418ImATeapot писал(а): ОБЪЕКТ Form - это объект библиотеки делфи. Внутри него реализован доступ к Windows API. Windows API не объектно-ориентированая (по крайней мере, снаружи). А в лазарусе оный объект реализует доступ например к QT. --- Теоретически, существует код написанный на ФАСМ, реализующий "хорошую" ОС, тк ФАСМ - Тьюринг-полный. Но не факт, что есть на свете программист, способный этот код написать . (Я не говорю что это априори невозможно. Но ОЧЕНЬ тяжело и главное - бессмысленно.). Объект это кусок памяти, в которой записаны переменные, адреса функций этого объекта, ссылки на другие объекты, т.е. это умный кусок памяти который много знает и много умеет. И правильная работа с объектами даёт безграничные возможности, я пишу ОС на фасме и у меня много чего лучше, чем в других ОС. На асме мне пишется лучше чем на С++ или Дельфи(проще и быстрее). |
Автор: | Bargest [ 10 июн 2012, 16:06 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
Цитата: т.е. это умный кусок памяти который много знает и много умеет. Это не умный кусок памяти. Это всего лишь структура и ассоциированные с ней функции. Никакого отношения к ОС они не имеют. В Windows ВСЯ работа с окнами идет через WinAPI. Любые навороты (будь то делфовские VCL с формами, будь то QT, будь то .NET) в конечном итоге вызывают функции WinAPI для управления окнами. ИМХО на асме можно написать "хорошую ось" (вернее её ядро) целиком, и не так уж это прям нереально и архитрудно. И смысл есть - при нормальных навыках программирования работать оно будет быстрее, чем на ЯВУ. Читаемость же зависит от стиля. Можно писать как КОС, которую действительно нереально поддерживать, а можно нормально оформлять и комментировать код, описывая всю логику работы. Но написать драйвера всех устройств и реализацию всех протоколов на асм невозможно по количеству времени, поскольку их огромное количество, к тому же под многие устройства есть готовые драйвера на ЯВУ (под тот же линух), которые можно при желании портировать (хоть часто непросто). |
Автор: | SII [ 10 июн 2012, 16:20 ] |
Заголовок сообщения: | Re: ASM vs ЯВУ |
Bargest писал(а): ИМХО на асме можно написать "хорошую ось" (вернее её ядро) целиком, и не так уж это прям нереально и архитрудно. И смысл есть - при нормальных навыках программирования работать оно будет быстрее, чем на ЯВУ Ну дык этих осей было полно, ведь до Мультикса (самый конец 1960-х) вообще все они писались только на асме, да и после, вплоть до 1980-х, именно асм был основным языком. Цитата: Читаемость же зависит от стиля. Можно писать как КОС, которую действительно нереально поддерживать, а можно нормально оформлять и комментировать код, описывая всю логику работы. Всё верно, но опять добавлю свою любимую заметку про то, что продуманная архитектура важней качественного написания. В конце концов, хорошо спроектированную, но плохо реализованную ОС можно переписать заново (вместо индусов-быдлокодеров посадить "белых людей"), а плохо спроектированной никакое качество собственно кодинга не поможет. У КОС с проектированием не просто плохо, а вообще никак, и именно это делает её абсолютно бесперспективной. Цитата: Но написать драйвера всех устройств и реализацию всех протоколов на асм невозможно по количеству времени, поскольку их огромное количество, к тому же под многие устройства есть готовые драйвера на ЯВУ (под тот же линух), которые можно при желании портировать (хоть часто непросто). Насчёт времени Вы правы, а вот насчёт возможности портировать драйверы... Чтобы их просто взять готовыми, нужно, чтобы подсистема ввода-вывода, входящая в состав ядра системы, на 100% соответствовала системе, откуда берутся драйвера -- ну а по объёму и сложности эта подсистема превосходит любую другую, а зачастую одна имеет больший объём, чем всё остальное ядро системы со всеми этими многозадачностями, управлением памятью, таймерами и т.п. Но мало того, что нужна совместимость по вводу-выводу; остальное тоже очень важно. Например, многие драйверы в Винде используют потоки режима ядра -- пожалуй, самый большой недостаток архитектуры самой Винды, который не только усложняет систему, но ещё и делает её поведение малопредсказуемым. Соответственно, в самописной ОС, способной использовать драйверы Винды, необходимо обеспечить поддержку всех таких системных механизмов, т.е. по крайней мере в плане ядра написать свою Винду. То же самое касается и Линуха, и БЗДи, и любой другой системы. Ну а если ядро своей системы серьёзно отличается от другого, ни о каком простом портировании драйверов речи уже не будет: их придётся переделывать, и очень серьёзно. Соответственно, как ни крути, а драйверы тоже придётся делать свои. Драйверы нижнего уровня, непосредственно взаимодействующие с "железом", есть смысл писать на ассемблере: они, как правило, небольшие по размерам и требуют таких специфических операций, как управление прерываниями, доступ к портам ввода-вывода и т.п. вещи, не слишком хорошо выразимые на языках высокого уровня (про эффективность уже вообще молчу, а ведь сокращение времени выполнения даже одного обработчика прерывания может прилично поднять характеристики системы в целом, в первую очередь её скорость реакции на эти самые прерывания). Кроме того, низкроуровневые драйверы привязаны к конкретному железу, а соответственно, и переносимость у них относительная (между разными системами её нет в силу различий в системных сервисах, предоставляемых ядром системы драйверам, ну а между разными архитектурами её нет в силу различий в программировании внешних устройств; лишь немногие устройства присутствуют в практически неизменном виде в разных архитектурах). А вот высокоуровневые драйверы типа файловых систем и сетевых протоколов, ИМХО, лучше писать на ЯВУ. Они действительно являются более-менее переносимыми и между разными архитектурами (поскольку не "завязаны" на аппаратуру), и между системами (поскольку интерфейс с ОС, зависящий от неё, обычно составляет лишь малую часть сложности таких драйверов, и проще переписать его, чем заново писать весь драйвер). |
Страница 7 из 8 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |