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
В качестве последнего довода: можете считать все аргументы за ассемблер неубедительными, но на этом конкретном форуме собралось некоторое множество программистов, которые считают, что на ассемблере, во всяком случае, имеет смысл писать. Помните: вас здесь никто не держит.