: Просто констатация факта.
Время от времени на форуме наблюдается появление новых людей, которые:
1) утверждают, что КОС никто не купит ("Миша, тебе никто денег не даст" (с) Геша);
2) открывают, что КОС плохо спроектирована, но они знают, как это исправить;
3) заявляют, что Си - цаца, ассемблер - кака.
Форум заводится, и начинается дискуссия, подобная этой.
[quote]Курить есть?
нет..........да
.l..............l
драка...часы есть?
................l
................l
....нет.............есть
.....l..................l
..драка.......скока время?
.........................l
......................10-30
l
чё так мало?
l
драка
[/quote]
Ядро и C
Вот один из примеров:
kernel.asm 668 строчка
Вообще если смысл спорить в этом случае? Увеличение производительности происходит только в критичном участке, а это только 10 % от общего кода. В свое время в 2006 году, писал программу, что же быстрее inc eax или add eax,1. Так вот, погрешность замеров не позволяет однозначно выявить лучшее решение. Если волнует оптимизация и тормознутость кода, в первую очередь нужна логическая оптимизация.
kernel.asm 668 строчка
Code: Select all
xor edi,edi
mov eax, 0x00040000
inc edi
Люди лучше бы вы с таким упорством проектировали алгоритмы и писали код.
1) Споры ASM vs HLL можно вести бесконечно.
2) При всех прочих преимуществах ЯВУ - почему то IBM не отказывается от своего HLASM и актуальных проектов на нем не мало.
3) Не смотря на то, что не все довольны как Асмом, так и ЯВУ - никто никому ничего не запрещает. Неужели это так трудно понять? Обязательно надо навязать свою точку зрения собеседнику и забить его под плинтус?
Нынче жаркое лето - еще как минимум 2 месяца,может лучше таки делом заниматься, а не рычать друг на друга?
1) Споры ASM vs HLL можно вести бесконечно.
2) При всех прочих преимуществах ЯВУ - почему то IBM не отказывается от своего HLASM и актуальных проектов на нем не мало.
3) Не смотря на то, что не все довольны как Асмом, так и ЯВУ - никто никому ничего не запрещает. Неужели это так трудно понять? Обязательно надо навязать свою точку зрения собеседнику и забить его под плинтус?
Нынче жаркое лето - еще как минимум 2 месяца,может лучше таки делом заниматься, а не рычать друг на друга?
MSVC2005 - нормальный компилятор. Впрочем, можете взять и другой.wolf.ram wrote:А если нормальный компилятор взять?
Чтобы отказаться от компилятора и тем самым получить бОльшую свободу для написания и оптимизации кода. Например, чтобы можно было оперировать флагом переноса, а также длинным умножением 32*32->64.wolf.ram wrote:А теперь дай вменяемый ответ на вопрос: зачем самому делать то, что делает компилятор на порядки быстрее?
Ложные зависимости типа mov eax,something1 / add ebx,eax / mov eax,something2 / add ecx,eax (где последняя команда как бы зависит от первой), вызванные необходимостью повторно использовать небольшое число регистров общего назначения, процессоры успешно разбивают. Истинные зависимости по данным определяются алгоритмом, и компилятор, в отличие от человека, не способен изменить алгоритм.wolf.ram wrote:Только и при упорядочивании, и при подмене регистров остаются ситуации зависимостей.
Не всегда можно. А когда можно, не всегда целесообразно.wolf.ram wrote:По крайней мере перекомпилить можно с оптимизацией под другую модель )))
Верно.wolf.ram wrote:И даже, при должном качестве кода, под другую архитектуру. Вот тут ты со своим асмокодом ничего не сможешь в ответ предложить (кроме эмуляции).
А если посчитать? Числа не стоит брать с потолка, а одно проверяемое неверное утверждение ставит под сомнение и все утверждения в контексте.wolf.ram wrote:Ну да. На 2 байта больше. Там с десяток мест такого кода. На целых 20 байт больше будет…
Шаблон "xor reg,reg / <ноль или больше строчек без reg и без меток> / inc reg" встречается в файлах, используемых для компиляции ядра (то есть *.asm и *.inc в kernel/trunk и всех подпапках, кроме drivers/, bootcode/, sec_loader/), 46 раз. (Константа 1 вообще встречается довольно часто.) Такой же шаблон с dec вместо inc встречается 18 раз. (Для подсчёта был использован текущий trunk версии svn.1510.) Итого 64 вхождения, что существенно больше оценки "с десяток мест такого кода", так что поздравляю с очередным неверным утверждением. Экономия в 128 байт при записи на устройство с секторами размером 512 байт приводит к тому, что примерно раз в 4 версии понадобится на один сектор меньше, что с учётом общего размера ядра для одной тривиальной оптимизации очень и очень неплохо.
Ну и ещё должен отметить, что файлы не только хранятся на дисках, но и иногда передаются по сети.
Это субъективная оценка.wolf.ram wrote:На C было бы легче это написать.
Нет, не написали бы. Статический массив и на сях написать проще, чем даже банальный список, не говоря уж о деревьях. Поскольку база ядра делалась по принципу "пишем так, чтобы прямо сейчас было проще всего", то и на сях были бы статические массивы.wolf.ram wrote:И написали бы, если бы C юзали.
Mario79
Собственно, объясняю, зачем я в этот спор ввязался. Понятно, что товарища wolf.ram'а не переубедить. Просто не хочется, чтобы абстрактный человек со стороны пришёл на форум в эту тему и увидел бы, что отдельные товарищи утверждают, что Си безусловно лучше какого-то там асма, а старожилы форума просто молчат, что можно интерпретировать как знак согласия. В общем, доводы в пользу ассемблера существуют, а некоторые доводы в пользу си являются мифами. Пожалуй, на этом имеет смысл закончить дискуссию.
wolf.ram
В качестве последнего довода: можете считать все аргументы за ассемблер неубедительными, но на этом конкретном форуме собралось некоторое множество программистов, которые считают, что на ассемблере, во всяком случае, имеет смысл писать. Помните: вас здесь никто не держит.
Это делается ассемблерными вставками. В одном-двух местах. Ради этого выкидывать весь компилятор? Или у тебя код только из этих двух мест и состоит?diamond wrote:Чтобы отказаться от компилятора и тем самым получить бОльшую свободу для написания и оптимизации кода. Например, чтобы можно было оперировать флагом переноса, а также длинным умножением 32*32->64.wolf.ram wrote:А теперь дай вменяемый ответ на вопрос: зачем самому делать то, что делает компилятор на порядки быстрее?
Ладно, повторю ещё раз схему диалога и вопрос:
— Компилятор оптимально распихивает переменные по регистрам.
— Но ведь можно это делать руками!!!
— Зачем руками делать то, что делает компилятор на порядки быстрее?
А переписать сишный код было бы точно проще. Чем реfuckторить простыни асмокода.diamond wrote:Нет, не написали бы. Статический массив и на сях написать проще, чем даже банальный список, не говоря уж о деревьях. Поскольку база ядра делалась по принципу "пишем так, чтобы прямо сейчас было проще всего", то и на сях были бы статические массивы.wolf.ram wrote:И написали бы, если бы C юзали.
Ты ещё ни одного аргумента не привёл. Всё какие-то ответы в стиле «а у вас негров линчуют!».diamond wrote:Понятно, что товарища wolf.ram'а не переубедить.
Приведи хоть нормальный ответ на вопрос об распределении регистров.
Я не утверждаю, что Си лучше/хуже асма. Вообще утверждение о том, что какой-то язык безусловно лучше другого — показатель ламеризма. Языки имеет смысл сравнивать применительно к какой-либо задаче.diamond wrote:отдельные товарищи утверждают, что Си безусловно лучше какого-то там асма
Я говорю, что выбор Си при написании ядра — более оптимальный выбор, чем выбор асма.
Существуют.diamond wrote:В общем, доводы в пользу ассемблера существуют
Но нет ни одного, который бы указывал на то, что ядро лучше писать на асме.
Last edited by wolf.ram on Fri Jul 02, 2010 8:00 am, edited 1 time in total.
Можно. С ярыми фанатиками асма, не принимающими никаких аргументов, только машущими лозунгами «Код на асме компактнее!», «На асме код быстрее!», «Зачем пользоваться компиляторами, когда можно лабать руками!», «То, что нельзя написать на асме, приходится паять!»(Из чьей-то подписи на васме. Вообще фееричная по своей дебильности фраза. Maxima, вон, нельзя написать на асме, но как-то без паяльника обошлись).Mario wrote:1) Споры ASM vs HLL можно вести бесконечно.
Это не точка зрения. Писать ядро на Си — более рациональный выбор, чем писать его на асме. Объективно рациональный. Без всяких точек зрения и прочих вкусов/привычек.Mario wrote:Обязательно надо навязать свою точку зрения собеседнику и забить его под плинтус?
wolf.ram, покажи своё ядро и я скажу кто ты.
..bw
..bw
В виду отсутствия аргументов оппонент использовал стандартный демагогический приём «сперва добейся».bw wrote:wolf.ram, покажи своё ядро и я скажу кто ты.
Слив засчитан.
Не стоит разводить полемику, у каждого есть своя точка зрения на происходящее. wolf.ram, тебе нравиться писать на С/C++, пожалуйста, разве кто-либо против этого? Можешь сделать лучше, чем существующий код в ядре ?
Ты воспринимаешь эту фразу выдернутой из контекста. Целиком по идее это должно звучать приблизительно так:wolf.ram wrote:«То, что нельзя написать на асме, приходится паять!»(Из чьей-то подписи на васме. Вообще фееричная по своей дебильности фраза
Большую часть кода можно написать на Си, то что нельзя написать на Си можно написать на Асме, то что нельзя написать на Асме, приходится паять!
Разумеется сторонники асма приводят только ту часть, которую им выгодно приводить. Одно время у меня она тоже в подписи висела. И я по прежнему считаю, что на асме теоретически можно написать проект любой сложности. Да есть минусы - это займет больше времени, но есть и плюсы - это будет занимать меньше в размере кода (размеры структур данных будут с вероятностью 99,9% не будут отличаться в размерах, если программист не полный дебил) и с некоторой вероятностью это может быстрее работать (а может и медленней, все зависит от реализации).
Однако переписывание ядра на Си в нашем случае мало что даст. Компилятора в самой ОС нет (а кому нужна Ос которая сама себя собрать не может?) и к тому же такой объем работы является непосильным для 2-3 человек в приемлемые сроки. К тому же сишников среди активных программистов Колибри вряд ли даже 40-45%.
Но опять же никто не запрещает заниматься любой даже самой казалось бы бредовой работой, так же как никто не запрещает на все плюнуть и пойти пить пиво.
Может для начала имеет смысл заняться портированием компилятора?
Не имеет смысла убеждать христианина, мусульманина, буддиста, зороастрийца и ассемблерщика - что его догмы не правильны, имеют нестыковки и неточности. В лучшем случае вам плюнут в след, а в худшем могут что-нибудь сказать или сделать. Вот как-то так.
Да и эта фраза не очень уж умная. Утверждение о том, что на низкоуровневом язке можно сделать больше, чем на высокоуровневом — почти всегда неверно.Mario wrote:Ты воспринимаешь эту фразу выдернутой из контекста.Целиком по идее это должно звучать приблизительно так:wolf.ram wrote:«То, что нельзя написать на асме, приходится паять!»(Из чьей-то подписи на васме. Вообще фееричная по своей дебильности фраза
Большую часть кода можно написать на Си, то что нельзя написать на Си можно написать на Асме, то что нельзя написать на Асме, приходится паять!
Разумеется сторонники асма приводят только ту часть, которую им выгодно приводить.
Ну если теоретически — то и на машине Тьюринга можно написать проект любой сложности.Mario wrote:И я по прежнему считаю, что на асме теоретически можно написать проект любой сложности.
Это не все минусы.Mario wrote:Да есть минусы - это займет больше времени
Хрен с ним — написать. Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
Исходного? Конечно нет. Бинарного? Тоже никаких гарантий. В большом проекте на асме скорее всего будет образовываться куча дублирующего кода.Mario wrote:но есть и плюсы - это будет занимать меньше в размере кода
Да и кого сношают размеры бинарника? Если на диске хранятся базы на несколько десятков гигов, какая разница, на метр больше размер сервера БД или на метр меньше?
Высокоуровневые языки изначально создавались для того, чтобы упростить и ускорить разработку. Но на ассемблере можно сделать куда больше, чем на ЯВУ, потому что ассемблерщик работает с инструкциями процессора, а значит априори имееn куда больший контроль над системой, чем тот же С-кодер.wolf.ram wrote:Утверждение о том, что на низкоуровневом язке можно сделать больше, чем на высокоуровневом — почти всегда неверно.
Ну и пусть. Можно написать хоть на Brainfuck'е или нарисовать в Piet. Это исключительно личное дело разработчика.wolf.ram wrote:Ну если теоретически — то и на машине Тьюринга можно написать проект любой сложности.
Хм.. Странно. Почему-то ядро Колибри постоянно "соправождают и модифицируют". Причем, не прибегая к магии.wolf.ram wrote:Хрен с ним — написать. Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
Это всё зависит не от языка, а от опыта и пряморукости программиста.wolf.ram wrote:В большом проекте на асме скорее всего будет образовываться куча дублирующего кода.
P.S. Не вижу причины спора. Если кому-то охота переписать ядро на С/С++, флаг тому в руки. Но не надо обсирать асм, и традиционный вариант ядра - ядра написанного на асме.
P.P.S. Не могу не согласится и с этим:
Может для начала имеет смысл заняться портированием компилятора?
ушёл...
Очень странно IBM вот сопровождает, наверно там не самые умные программисты?wolf.ram wrote:Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
Спорное утверждение - пока что наблюдаю: размер бинарника на асме всегда меньше чем на ЯВУ.wolf.ram wrote:Бинарного? Тоже никаких гарантий.
Степерь кривизны рук и наличие предварительного грамотного проектирования.wolf.ram wrote:В большом проекте на асме скорее всего будет образовываться куча дублирующего кода.
Меня.wolf.ram wrote:Да и кого сношают размеры бинарника?
А еще около 30 программистов вложивших свой труд в Колибри.
А еще около 10000 скачивающих каждый выпуск Колибри.
Ой-ли на метр? А если сравнить код написанный на С# с кодом аналогичной функциональности на асме?wolf.ram wrote:Если на диске хранятся базы на несколько десятков гигов, какая разница, на метр больше размер сервера БД или на метр меньше?
Единственное, что можно сделать на асме, но нельзя сделать на ЯВУ в прикладных задачах — использовать SIMD-расширения процессора. И всё.Nasarus wrote:Но на ассемблере можно сделать куда больше, чем на ЯВУ, потому что ассемблерщик работает с инструкциями процессора
Какой такой контроль над системой? Над процом? Тебе так важно проконтроллировать, в какой регистр запишется та или иная переменная? В этом весь смысл задач, которые ты программируешь? Ню-ню.Nasarus wrote:а значит априори имееn куда больший контроль над системой, чем тот же С-кодер.
Мгм. Модифицируют только то, что можно модифицировать минимумом костылей и переписываний существующего кода, так, по мелочам.Nasarus wrote:Хм.. Странно. Почему-то ядро Колибри постоянно "соправождают и модифицируют". Причем, не прибегая к магии.
Это зависит-таки от языка. От лёгкости code reuse в этом языке.Nasarus wrote:Это всё зависит не от языка, а от опыта и пряморукости программиста.
Очень даже вероятно, что так.Mario wrote:Очень странно IBM вот сопровождает, наверно там не самые умные программисты?wolf.ram wrote:Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
А что за задачи у них там решаются?
Ну и хрен с ним. Размер исходника в разы важнее.Mario wrote:Спорное утверждение - пока что наблюдаю: размер бинарника на асме всегда меньше чем на ЯВУ.wolf.ram wrote:Бинарного? Тоже никаких гарантий.
Нет. Степень лёгкости code reuse на этом языке главную роль играет.Mario wrote:Степерь кривизны рук и наличие предварительного грамотного проектирования.
Проектирование, конечно, важно, но возможность code reuse асму оно не добавит.
А если размер исходника и лёгкость сопровождения сравнить?Mario wrote:Ой-ли на метр? А если сравнить код написанный на С# с кодом аналогичной функциональности на асме?
Who is online
Users browsing this forum: No registered users and 30 guests