Ядро и C

Kernel architecture questions
  • Вот один из примеров:
    kernel.asm 668 строчка

    Code: Select all

    xor     edi,edi
    mov     eax, 0x00040000
    inc	 edi
    Вообще если смысл спорить в этом случае? Увеличение производительности происходит только в критичном участке, а это только 10 % от общего кода. В свое время в 2006 году, писал программу, что же быстрее inc eax или add eax,1. Так вот, погрешность замеров не позволяет однозначно выявить лучшее решение. Если волнует оптимизация и тормознутость кода, в первую очередь нужна логическая оптимизация.
  • Люди лучше бы вы с таким упорством проектировали алгоритмы и писали код.

    1) Споры ASM vs HLL можно вести бесконечно.
    2) При всех прочих преимуществах ЯВУ - почему то IBM не отказывается от своего HLASM и актуальных проектов на нем не мало.
    3) Не смотря на то, что не все довольны как Асмом, так и ЯВУ - никто никому ничего не запрещает. Неужели это так трудно понять? Обязательно надо навязать свою точку зрения собеседнику и забить его под плинтус?

    Нынче жаркое лето - еще как минимум 2 месяца,может лучше таки делом заниматься, а не рычать друг на друга?
  • wolf.ram wrote:А если нормальный компилятор взять?
    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:Ну да. На 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:
    wolf.ram wrote:А теперь дай вменяемый ответ на вопрос: зачем самому делать то, что делает компилятор на порядки быстрее?
    Чтобы отказаться от компилятора и тем самым получить бОльшую свободу для написания и оптимизации кода. Например, чтобы можно было оперировать флагом переноса, а также длинным умножением 32*32->64.
    Это делается ассемблерными вставками. В одном-двух местах. Ради этого выкидывать весь компилятор? Или у тебя код только из этих двух мест и состоит?

    Ладно, повторю ещё раз схему диалога и вопрос:
    — Компилятор оптимально распихивает переменные по регистрам.
    — Но ведь можно это делать руками!!!
    — Зачем руками делать то, что делает компилятор на порядки быстрее?
    diamond wrote:
    wolf.ram wrote:И написали бы, если бы C юзали.
    Нет, не написали бы. Статический массив и на сях написать проще, чем даже банальный список, не говоря уж о деревьях. Поскольку база ядра делалась по принципу "пишем так, чтобы прямо сейчас было проще всего", то и на сях были бы статические массивы.
    А переписать сишный код было бы точно проще. Чем реfuckторить простыни асмокода.
    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.
  • Mario wrote:1) Споры ASM vs HLL можно вести бесконечно.
    Можно. С ярыми фанатиками асма, не принимающими никаких аргументов, только машущими лозунгами «Код на асме компактнее!», «На асме код быстрее!», «Зачем пользоваться компиляторами, когда можно лабать руками!», «То, что нельзя написать на асме, приходится паять!»(Из чьей-то подписи на васме. Вообще фееричная по своей дебильности фраза. Maxima, вон, нельзя написать на асме, но как-то без паяльника обошлись).
    Mario wrote:Обязательно надо навязать свою точку зрения собеседнику и забить его под плинтус?
    Это не точка зрения. Писать ядро на Си — более рациональный выбор, чем писать его на асме. Объективно рациональный. Без всяких точек зрения и прочих вкусов/привычек.
  • wolf.ram, покажи своё ядро и я скажу кто ты.

    ..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:но есть и плюсы - это будет занимать меньше в размере кода
    Исходного? Конечно нет. Бинарного? Тоже никаких гарантий. В большом проекте на асме скорее всего будет образовываться куча дублирующего кода.
    Да и кого сношают размеры бинарника? Если на диске хранятся базы на несколько десятков гигов, какая разница, на метр больше размер сервера БД или на метр меньше?
  • wolf.ram wrote:Утверждение о том, что на низкоуровневом язке можно сделать больше, чем на высокоуровневом — почти всегда неверно.
    Высокоуровневые языки изначально создавались для того, чтобы упростить и ускорить разработку. Но на ассемблере можно сделать куда больше, чем на ЯВУ, потому что ассемблерщик работает с инструкциями процессора, а значит априори имееn куда больший контроль над системой, чем тот же С-кодер.
    wolf.ram wrote:Ну если теоретически — то и на машине Тьюринга можно написать проект любой сложности.
    Ну и пусть. Можно написать хоть на Brainfuck'е или нарисовать в Piet. Это исключительно личное дело разработчика.
    wolf.ram wrote:Хрен с ним — написать. Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
    Хм.. Странно. Почему-то ядро Колибри постоянно "соправождают и модифицируют". Причем, не прибегая к магии.
    wolf.ram wrote:В большом проекте на асме скорее всего будет образовываться куча дублирующего кода.
    Это всё зависит не от языка, а от опыта и пряморукости программиста.

    P.S. Не вижу причины спора. Если кому-то охота переписать ядро на С/С++, флаг тому в руки. Но не надо обсирать асм, и традиционный вариант ядра - ядра написанного на асме.
    P.P.S. Не могу не согласится и с этим:
    Может для начала имеет смысл заняться портированием компилятора?
    ушёл...
  • wolf.ram wrote:Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
    Очень странно IBM вот сопровождает, наверно там не самые умные программисты?
    wolf.ram wrote:Бинарного? Тоже никаких гарантий.
    Спорное утверждение - пока что наблюдаю: размер бинарника на асме всегда меньше чем на ЯВУ.
    wolf.ram wrote:В большом проекте на асме скорее всего будет образовываться куча дублирующего кода.
    Степерь кривизны рук и наличие предварительного грамотного проектирования.
    wolf.ram wrote:Да и кого сношают размеры бинарника?
    Меня. :lol:
    А еще около 30 программистов вложивших свой труд в Колибри.
    А еще около 10000 скачивающих каждый выпуск Колибри.
    wolf.ram wrote:Если на диске хранятся базы на несколько десятков гигов, какая разница, на метр больше размер сервера БД или на метр меньше?
    Ой-ли на метр? А если сравнить код написанный на С# с кодом аналогичной функциональности на асме? :mrgreen:
  • Nasarus wrote:Но на ассемблере можно сделать куда больше, чем на ЯВУ, потому что ассемблерщик работает с инструкциями процессора
    Единственное, что можно сделать на асме, но нельзя сделать на ЯВУ в прикладных задачах — использовать SIMD-расширения процессора. И всё.
    Nasarus wrote:а значит априори имееn куда больший контроль над системой, чем тот же С-кодер.
    Какой такой контроль над системой? Над процом? Тебе так важно проконтроллировать, в какой регистр запишется та или иная переменная? В этом весь смысл задач, которые ты программируешь? Ню-ню.
    Nasarus wrote:Хм.. Странно. Почему-то ядро Колибри постоянно "соправождают и модифицируют". Причем, не прибегая к магии.
    Мгм. Модифицируют только то, что можно модифицировать минимумом костылей и переписываний существующего кода, так, по мелочам.
    Nasarus wrote:Это всё зависит не от языка, а от опыта и пряморукости программиста.
    Это зависит-таки от языка. От лёгкости code reuse в этом языке.
  • Mario wrote:
    wolf.ram wrote:Проект будет НЕВОЗМОЖНО сопровождать и модифицировать.
    Очень странно IBM вот сопровождает, наверно там не самые умные программисты?
    Очень даже вероятно, что так.
    А что за задачи у них там решаются?
    Mario wrote:
    wolf.ram wrote:Бинарного? Тоже никаких гарантий.
    Спорное утверждение - пока что наблюдаю: размер бинарника на асме всегда меньше чем на ЯВУ.
    Ну и хрен с ним. Размер исходника в разы важнее.
    Mario wrote:Степерь кривизны рук и наличие предварительного грамотного проектирования.
    Нет. Степень лёгкости code reuse на этом языке главную роль играет.
    Проектирование, конечно, важно, но возможность code reuse асму оно не добавит.
    Mario wrote:Ой-ли на метр? А если сравнить код написанный на С# с кодом аналогичной функциональности на асме? :mrgreen:
    А если размер исходника и лёгкость сопровождения сравнить?
  • Who is online

    Users browsing this forum: No registered users and 3 guests