Comments 11
Забавно. А с практической точки зрения? Вылизывать производительность в узких местах или просто для фана?
Однако… можно было бы до уровня IL расковырять (в том же linqpad) и остановиться, но нет… we need to go deeper! ))
Это в смысле visual studio позволяет дизассемблированный листинг просмотреть, или собственно откуда взят ассемблерный код?
Просто с IL кодом как бы все понятно, а вот прям столь низко…
Просто с IL кодом как бы все понятно, а вот прям столь низко…
В первых своих исследованиях я использовал winDbg, но там надо учитывать, что для начала надо дождаться, пока функция вызовется хоть раз (до этого JIT ее просто не скомпелит) или предкомпелить. Разумеется, windbg очень мощный, но для таких примеров слишком громоздкий.
И не так давно один добрый человек мне подсказал сайт https://sharplab.io. Я сверял с windbg (к нему было доверие), все совпадает. Так что для небольших примеров пользуюсь им.
Тут генерируется asm 32-битный, не 64, я думал должны быть 64 битные регистры? Хотя может потому что операнды Int32.
Как я выше упоминал, я использовал тот ресурс для получения кода Ассемблера. А они видимо решили использовать 32 бита. В этом плане я даже и согласен с ними. Это классика — 32 бита на ссылку и прочее.
Когда я использовал windbg я наблюдал 64 битный код.
Как я знаю, от Int32 он не зависит, как известно, int — просто элиас для Int32. А число 32 в названии Int32 означает, что мы используем 32 бита для представления числа. Ведь Int64 (он же long) доступен не только на 64 битной платформе. Мы, как разработчики, не должны об этом знать. Об этом должна заботиться среда, а мы просто работаем с 32 или 64 битным числом. И т.к. мы кроссплатформенны, это не наше дело, свалим это на плечи JIT'a
Когда я использовал windbg я наблюдал 64 битный код.
Как я знаю, от Int32 он не зависит, как известно, int — просто элиас для Int32. А число 32 в названии Int32 означает, что мы используем 32 бита для представления числа. Ведь Int64 (он же long) доступен не только на 64 битной платформе. Мы, как разработчики, не должны об этом знать. Об этом должна заботиться среда, а мы просто работаем с 32 или 64 битным числом. И т.к. мы кроссплатформенны, это не наше дело, свалим это на плечи JIT'a
Не уловил, что в статье C#-специфичное; скорее описана общая для большинства компилируемых языков концепция. Аудитория читающих могла бы быть шире.
Также стоит помнить, что стек растет в сторону меньших адресов
Мне кажется, стоит уточнить, что здесь идет речь именно про x86. Для других платформ может быть не так.
Sign up to leave a comment.
Что происходит за кулисами С#: основы работы со стеком