Previous Entry Share Next Entry
msl-five и виртуальные машины.
mikelsv
Первый шаг не то, что бы провален, скорее заброшен в состоянии "работать вероятно будет". Там столько мыслей и вариантов, что проще сделать чтобы оно как бы было. Отладка покажет.

Далее логика разработки свелась к идее стеков. А перед этим к вопросу, почему главный класс всего один? Теперь их два, один генерит псевдокод, второй его выполняет. Пересекаться им в общем-то не надо, а структура упрощается в два раза.
Так вот о стеках. В текущих задачах использование new() для выделения памяти приравнивается к ереси с последующим сожжением пациента. Да и любые лишние выделения памяти. И тут я осознал всю прелесть стека, неразрывного блока памяти, достаточной длинны, в который запихиваются все данные, которые ложатся в логику. Например названия включаемых файлов или переменных с псевдокодом.

Итого:
- Стек для хранения данных, которые можно впоследствие выкинуть. Используется в виде: int pos = stack.GetPos(); здесь вставляем данные и работаем с ними. stack.SetPos(pos); Итого шустрая работа с памятью.
- Линейный буффер для остальных данных. Буффер для псевдокода, текстовых данных, информации о соответствии имен переменных к стеку.

По этой логике все и строится.

Теперь о текущем состоянии. msl-ce был настолько крут, что почти в том же виде потихоньку мигрирует в msl-five, постепенно меняясь под новую логику.
Что же до результатов, генерация псевдокода и исполнение написаны и, в каком-то виде работают. Но вопросов еще много. Отладка находится в районе $a = '1'; Остается писать и отлаживать. Большой вопрос, в каком виде делать переменные в стеке. msl_value весит 32 байта, что немного много. Плюс, нужны новые переменные, сейчас используется MString, которая адски тормозит в случае $a.= '1'; Так же вопросы по пространствам, global, this, local.

Сейчас я доволен лишь генерацией псевдокода, он оптимален и тормозить там нечему.
Ну, еще пять тысяч строчек кода и msl залетает.
Tags: ,

?

Log in

No account? Create an account