Comments 11
Забавно. А с практической точки зрения? Вылизывать производительность в узких местах или просто для фана?
Пример чисто для фана. Думал о его применимости (возможно, для повышения привилегий, где вызов стандартных функций принимает интерфейс/делегат), но не нашел. Да и не особо искал, если честно, не ставил это целью. Ну а еще люблю понимать, как оно все там происходит.
Однако… можно было бы до уровня IL расковырять (в том же linqpad) и остановиться, но нет… we need to go deeper! ))
Это в смысле visual studio позволяет дизассемблированный листинг просмотреть, или собственно откуда взят ассемблерный код?
Просто с 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

Не уловил, что в статье C#-специфичное; скорее описана общая для большинства компилируемых языков концепция. Аудитория читающих могла бы быть шире.

Также стоит помнить, что стек растет в сторону меньших адресов

Мне кажется, стоит уточнить, что здесь идет речь именно про x86. Для других платформ может быть не так.
Я вроде писал где-то, что все примеры для 32 бит. Сейчас перечитаю, мб в дисклеймер внесу. Но вы правы, конечно.
Справедливости ради, в .NET Core еще и структура таблицы методов поменялась. Общая схема работы осталась, но конкретные смещения уже не те.
Only those users with full accounts are able to leave comments. Log in, please.