Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2009-07-11 00:48:51 ЛС | профиль | цитата
Если честно, сам нефига понять не могу
Нет, ну то, что в те стародавние времена я имел очень приблизительное понимание о бинарном представлении конструкций Дельфи - это видно буквально с первых же строк

Основная идея заключалась в том, что код не генерировался сразу, а "откладывался". Вместо конечного кода команды возвращалась "заготовка" для его генерации потом
Видимо коды составных частей, и код операции которую потом надо будет сгенерировать.
Почему потом - для целей оптимизации.
Скажем, получили результат C_plus_V - это означает что где-то (помимо этого кода) мы получили константу (посчитанную в compile-time), и некий код, формирующий результат в стеке (наверное!!! - еще есть результат в памяти, проверять надо).
Далее, по результатам парсинга оказалось, что надо сложить с чем??? - оказалось что с C_minus_A.
Чего мы делаем (видимо)...
Есть код, формирующий результат в стеке сопроцессора (это первый), и есть код, формирующий результат в памяти (это второй, наверное!!! - проверять надо)
Соединяем их, приклеиваем к полученной склейке еще и команду отнимания от стека содержимого памяти, складываем две константы, и этому всему добру присваиваем код C_plus_V

Вот как-то так....
Помню, что все это разнообразие приводит к нескончаемому потоку разборок. А еще ведь и целочисленные результаты надо "обмногообразить"
Функции - надо думать про inline/call, учитывать размер требуемого им стека.
Если функциональные обращения к схеме из формулы - полная непонятка со стеком сопроцессора (его размером)
В общем, оно и так "пухлое", а любая заморочка начинает раздувать его. Не пропорционально...
Ощущение такое у меня сложилось, что надо все переосмысливать заново.

Попробую, конечно, разобраться по-детальней... Но уж точно -- не сегодня
Ну или можно апологетов скриптов попросить... Пусть и они нам продемонстрируют великую понятность их инструмента.
Ерунда ведь по объему, рядом с творениями nesco-то - и рядом не стояло
карма: 9

0