Изучая CLI возникло пару вопросов о который раньше как-то не задумывался.
Я так понимаю, что это относится ко всем ассемблерам, но всё же: везде в книге пишут, что VES (Virtual Execution System) оперирует данными на стеке. Вопрос, почему используется именно стек? И если есть чё нибудь почитать на это тему, то прошу поделиться. Гуглом чего то не берётся это вопрос.
Как организован стек? Что область памяти понятно, но нафига например указывать директиву .maxstack в начале тела метода, если в стеке всё равно могут хранится значения разных типов и размер его, просто зная количество элементов в стеке, не посчитаешь? И как собственно выглядит размещение ValueType в стеке? Т.е. меня интересует именно как устроен стек в CLI.
Щас буду гнать чушь, ибо даже не знаю, что такое Virtual Execution System, но тем ни менее чисто из здравого смысла C>Изучая CLI возникло пару вопросов о который раньше как-то не задумывался. C>* Я так понимаю, что это относится ко всем ассемблерам, но всё же: везде в книге пишут, что VES (Virtual Execution System) оперирует данными на стеке. Вопрос, почему используется именно стек?
А что, если не стек? Ну вот смотри, что такое программа? Это тупо вызов функции, которая вызывает другие функции, которые вызывают третьи функции и тд. Где хранить данные, которые требуютмся для работы функции ?? Тут 2 варианта, либо функция НЕ знает, сколько именно памяти треба для хранения данных, тогда только дин память. Либо функция знает, и тут — стек самая простая и очевидная структура,задали сколько памяти нужно для работы функции, сначале работы она выделилась, в конце функции — освободилась. Все просто.
C>* Как организован стек? Что область памяти понятно, но нафига например указывать директиву .maxstack в начале тела метода, если в стеке всё равно могут хранится значения разных типов и размер его, просто зная количество элементов в стеке, не посчитаешь?
Ну так компилятор же знает не только кол-во переменных, но и их тип, а значит вполне может вычислить сколько памяти под них нужно выделить.
Здравствуйте, Cynic, Вы писали:
C>Изучая CLI возникло пару вопросов о который раньше как-то не задумывался. C> C>Я так понимаю, что это относится ко всем ассемблерам, но всё же: везде в книге пишут, что VES (Virtual Execution System) оперирует данными на стеке. Вопрос, почему используется именно стек? И если есть чё нибудь почитать на это тему, то прошу поделиться. Гуглом чего то не берётся это вопрос.
Тот стек, про который написано, это абстракция, которую используют, чтобы понятно было, над какими данными будет выполняться IL-опкод. Реально данные и в куче, и на стеке потока, и в регистрах хранятся.
C>Как организован стек? Что область памяти понятно, но нафига например указывать директиву .maxstack в начале тела метода, если в стеке всё равно могут хранится значения разных типов и размер его, просто зная количество элементов в стеке, не посчитаешь? И как собственно выглядит размещение ValueType в стеке? Т.е. меня интересует именно как устроен стек в CLI. C>
Исходя из вышенаписанного, эта директива нужна лишь для верификации метода (если хотите использовать кучу переменных в одном методе, будьте добры указать это в .maxstack).
Опять же, размещение ValueType в этом стеке — операция абстрактная, она означает что следующая команда будет проведена именно с этим ValueType.
Есть и другой стек, системный стек потока, в котором выполняется код в рантайме. Это деталь реализации CLI в .NET Framework, которая не специфицирована. Код CLI обычно (не всегда!) выполняется в стандартных Windows-потоках, со стеком по умолчанию размером с 1 мегабайт. Можно увеличить размер стека потока, если нужно. Он организован так: есть кусок выделенной памяти, и указатель на место в этом куске. Указатель показывает, где находится последний элемент стека. При размещении ValueType в стеке, указатель перемещается на X байт вниз, память обнуляется. При выходе из метода, указатель перемещается до места, где он был до вызова этого метода. Таким образом, автоматически стираются все данные этого метода. Именно поэтому в структах не бывает деструкторов — иначе выходить из метода было бы очень медленно.
Здравствуйте, catbert, Вы писали:
С>> Вопрос, почему в VES используется именно стековая модель?
Вычитал следующее мнение по этому вопросу:
Несмотря на то, что большинство современных процессоров для организации вычислений используют регистры, в виртуальной системе выполнения вместо регистров применяется стек вычислений. Это связано, скорее всего, с тем, что стековые вычисления достаточно легко можно отобразить на регистры процессора, так как модель, использующая стек, более абстрактна, чем регистровая модель
Здравствуйте, Cynic, Вы писали:
C>Изучая CLI возникло пару вопросов о который раньше как-то не задумывался.
курите джаву. там тоже все на стек завязано. в спецификации на байт-код подробно разбирается. и флеш так же использует стек на уровне байт-кода. CLI в этом плане не сильно отличается. думать о стеке как об области памяти никто не запрещает, но все же лучше если под стеком вы понимаете частный случай списка. непонятно с какой целью вам нужно знать "как устроен стек в". ибо реализация может поменяться в любой момент, а интерфейс останется.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Cynic, Вы писали:
C>Как организован стек? Что область памяти понятно, но нафига например указывать директиву .maxstack в начале тела метода, если в стеке всё равно могут хранится значения разных типов и размер его, просто зная количество элементов в стеке, не посчитаешь? И как собственно выглядит размещение ValueType в стеке? Т.е. меня интересует именно как устроен стек в CLI.
Стек никак не организован. Стековая VM в CLI — это исключительно способ сериализации потока команд. Все быстрые VM на первом же шаге восстанавливают из него SSA-дерево, которое дальше уже и используют для верификации, JIT-компиляции и прочих нужд. В Java всё примерно аналогично.
Нет, конечно, в теории можно запускать байт-код на чистом интерпретаторе, но конкретно для .NET это будет очень медленно и пригодно только для специальных целей типа отладки. Для Java чистая интерпретация заметно быстрее из-за типизированных команд.
Здравствуйте, acDev, Вы писали:
D>Здравствуйте, Cynic, Вы писали:
D> Лично я считаю, что стековая ВМ более гибкая, т.к. не требует наличия множества регистров CPU.
и в чем же состоит "гибкость"? кстати, регистры могут быть организованы в виде стека, т.е. быть доступны и по номеру (имени), и по смещению относительно вершины стека и записаны (прочитаны) комнадами забросить и стянуть.
гибкость стековой ВМ зависит от набора команд. если в этом наборе есть команды дублировать значение на вершине, обменять два значения из стека -- это сильно упрощает код, генерируемый компилятором. когда этих команд нет, то код становится слишком многословным.
при этом базовые команды (типа push/pop, call/return) элементарно реализуются. у выньинтела стек это вообще-то куча. ну разве что операционка знает, что стек растет вврех, а куча вниз. хотя куча может расти куда угодно, а в 64 винде от стека начали отказываться и апи функции принимают аргументы через регистры. компиляторы стемятся использовать регистры для передечи аргументов если только явно не указана обратная конверсия.
D> Видимо на ARM регистровая (14 32-bit регистров) ВМ более эффективна, нежели стековая.
вообще-то при трансляции в машинный код больше свободы для адаптивного выбора какие переменные поместить в регистр. но вы забываете о том, что для адресации 16 регистров (два из которых $sp и $pc) достаточно всего 4х бит. а для адресации 32 битного указателя нужно 32 бита. если же мы используем чистый стек в высшей математической абстракции то там для обмена значений двух переменных нужны или спец-команды или танцы с приседаниями (за исключением когда обмениваются два значения на вершине стека, но даже с ними танцы).
так что гибкость стековой машины исчезает когда вы посмотрите в тот код что генерит хотя бы джава. даже с учетом, что это байт код и что байт код оптимизирован под операции на стеке и что байт-код плохо ложится на большинство железных цп и уж точно хреново ложится на арм, оптимизированный под операции регистр — регистр.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
