Комментарии 18
если хотите, можно это сделать в следующей статьеВы же не спрашивали, когда начинали писать статью, т.е. действовали по своему плану. Так и сейчас не надо спрашивать: конечно, пишите.
Только я бы подавал этот материал не в контексте описания работы компиляторов, а как рекомендации разработчикам по написанию кода на Assembler. Ведь запуская на компиляцию уже оптимизированный код, мы ускоряем процесс отладки и экономим память.
Спасибо!
Неплохо бы в начале статьи (или в конце) размещать список ссылок на другие статьи этого же цикла, раз их у вас будет минимум три.
Неплохо бы в начале статьи (или в конце) размещать список ссылок на другие статьи этого же цикла, раз их у вас будет минимум три.
Т. е. внутренняя часть условия падает вниз программы, что не очень хорошо: допустим, после условия (в секции #1) есть еще куча строчек, тогда, чтобы увидеть секцию #0, мы будем крутить листинг очень далеко вниз.
Причина другая. Обычно используется короткий условный переход, всего команда занимает 2 байта, из которых один байт задаёт смещение (со знаком) относительно следующей команды, т.е. условный переход может быть не далее 127 байт. Если тело не помещается в 127 байт то делается этот трюк с дополнительным длинным переходом.
Представляю размер статьи, когда речь пойдёт о классах.
Это C, здесь нет классов :)
А почему там должно быть много кода?
Разве классы нельзя преобразовать в что-то вроде
void MyClass_foo(MyClass* self, int arg) {
//...
}?
Увидел комментарий и вспомнил про статью, что когда-то попадалась. Потом около часа её искал. Вот!
Если речь о C++, то там ещё есть виртуальные функции и виртуальные предки.
Я раньше писал на Fasm. Потом понял, что это не перспективно и не кроссплатформенно, и перешёл на javascript, чтоб уж наверняка) Дело в том, что ассемблер — это не только x86. А я более менее разобрался только в нём. А всё остальное (mmx, sse) оказалось слишком сложным. А от одного x86 смысла не так много, любой компилятор сделает это не так уж и плохо и при этом кроссплатформенно! А с распространением arm всё стало совсем плохо.
Да что там сложного? Двоичная математика везде одинаковая. И идея SIMD тоже вполне себе универсальна.
Просто надо asm в правильных местах применять.
Просто надо asm в правильных местах применять.
Забыл что есть ещё x86-64. SIMD идея красивая, так же как и VLIW. Только не для человека! Я не осилил даже MMX, хотя он достаточно прост. А SSE… ну дело ведь не в двоичной математике, а в какой-то каши из сотен мнемоник, об которые можно сломать и мозг, и глаза, и язык… А полюбил я ассемблер за простой и однозначный синтаксис, без непредсказуемого поведения. Тогда я не знал, что это только верхушка айсберга.
А эти правильные места где нужно применять ассемблер как-то мне сейчас не попадаются…
А эти правильные места где нужно применять ассемблер как-то мне сейчас не попадаются…
у дело ведь не в двоичной математике, а в какой-то каши из сотен мнемоник, об которые можно сломать и мозг, и глаза, и язык…
Это решается небольшой справочной табличкой и опытом применения. Достаточно помнить, что «есть инструкция, которая делает что-то такое», а дальше уже можно в документацию подглядеть. У меня, например, перманентно открыт интеловский гайд по инструкциям. Как раз чтобы мозг не загружать заучиванием мнемоник. И хотя десяток наиболее часто употребляемых SIMD-инструкций всё равно уже осели в голове, я не сильно расстроюсь, если забуду их точное написание после праздников. Ведь я всё равно помню, что они делают.
А полюбил я ассемблер за простой и однозначный синтаксис, без непредсказуемого поведения.
Это да, за этого его у любят — что будет сделано именно то, что написано в коде. Хотя есть и обратная сторона — никто не будет оптимизировать ваш код за вас.
А эти правильные места где нужно применять ассемблер как-то мне сейчас не попадаются…
Обычно все эти места находятся внутри библиотек, которые вы наверняка активно используете в своей деятельности. А вот если вы сами пишете библиотеки для вычислительно-нагруженных алгоритмов, то без asm-а тяжело обойтись.
Вообще не понял, зачем на ассамблере в условии аж два перехода. Неужели не проще сначала записать одно значение в регистр, а уж потом если условие выполнилось, другое. В случае невыполнения условия нам нужен всего лишь один переход пропускающий второе присваивание. Зачем целых два перехода?
Я вам открою одну тайну: в этом куске кода вообще не нужны переходы, достаточно воспользоваться чудесной инструкцией cmov (с нужным вариантом условия), которая как раз делает то, что вы хотите, — заменяет значение в регистре при соблюдении условия.
И тогда вообще не нужно дёргать конвейер лишний раз, всё исполняется линейно.
И тогда вообще не нужно дёргать конвейер лишний раз, всё исполняется линейно.
если про код с else, то это же не оптимизированный код. В Си мы не записывает какое-то число в переменную, поэтому компилятор и не делает таких смелых предположений. А вот с включенной оптимизацией вообще переходов не будет =)
Больше, больше статей на эту тему нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Постигаем Си глубже, используя ассемблер. Часть 2 (условия)