LINUX.ORG.RU

История изменений

Исправление wandrien, (текущая версия) :

Отслеживание загрузок выполнено так, что в таблице вида Узел Привязка[Регистр] мы указываем, какой узел дерева сейчас в регистре. А потом сравниваем с тем, какой узел сейчас компилируем.

Там конечно сложнее всё, так как нужно правильно учитывать сброс привязок, и также к одному регистру может быть назначена не 1 привязка, а 2.

Но общий принцип вот такой простой.

а место в памяти где она лежала уже не строго зарезервировано за ней, а может быть переиспользовано какой-то другой переменной, которая либо появилась в середине кода, либо до этого лежала в регистре а теперь больше не нужна.

Конкретно этого я делать скорее всего не буду. А вот устранение избыточного сохранения регистра в память в кейсах, которые не сложно отследить в случае с трансляцией из дерева, наверное сделаю попозже, как руки дойдут.

А продвинутые техники оптимизации требуют смены внутреннего представления с синтаксического дерева на граф элементарных блоков операций. Потому что если не менять представление, то дальнейшее всё больше будет становится похоже на мем про троллейбус из буханки.

Поэтому если проект доживёт до отдалённого светлого будущего, я возможно заменю бэк на готовый: https://c9x.me/compile/ , потому что с нуля писать бэк такого вида в мои планы не входит.

Исправление wandrien, :

Отслеживание загрузок выполнено так, что в таблице вида Узел Привязка[Регистр] мы указываем, какой узел дерева сейчас в регистре. А потом сравниваем с тем, какой узел сейчас компилируем.

Там конечно сложнее всё, так как нужно правильно учитывать сброс привязок, и также к одному регистру может быть назначена не 1 привязка, а 2.

Но общий принцип вот такой простой.

а место в памяти где она лежала уже не строго зарезервировано за ней, а может быть переиспользовано какой-то другой переменной, которая либо появилась в середине кода, либо до этого лежала в регистре а теперь больше не нужна.

Конкретно этого я делать скорее всего не буду. А вот устранение избыточного сохранения регистра в память в кейсах, которые не сложно отследить в случае с трансляцией из дерева, наверное сделаю попозже, как руки дойдут.

А продвинутые техники оптимизации требуют смены внутреннего представления с синтаксического дерева на граф элементарных блоков операций. Потому что если не менять представление, то дальнейшее всё больше будет становиться похоже на мем про троллейбус из буханки.

Поэтому если проект доживёт до отдалённого светлого будущего, я возможно заменю бэк на готовый: https://c9x.me/compile/ , потому что с нуля писать бэк такого вида в мои планы не входит.

Исправление wandrien, :

Отслеживание загрузок выполнено так, что в таблице вида Узел Привязка[Регистр] мы указываем, какой узел дерева сейчас в регистре. А потом сравниваем с тем, какой узел сейчас компилируем.

Там конечно сложнее всё, так как нужно правильно учитывать сброс привязок, и также к одному регистру может быть назначена не 1 привязка, а 2.

Но общий принцип вот такой простой.

а место в памяти где она лежала уже не строго зарезервировано за ней, а может быть переиспользовано какой-то другой переменной, которая либо появилась в середине кода, либо до этого лежала в регистре а теперь больше не нужна.

Конкретно этого я делать скорее всего не буду, вот устранение избыточного сохранения регистра в память в кейсах, которые не сложно отследить в случае с трансляцией из дерева, наверное сделаю попозже, как руки дойдут.

А продвинутые техники оптимизации требуют смены внутреннего представления с синтаксического дерева на граф элементарных блоков операций. Потому что если не менять представление, то дальнейшее всё больше будет становиться похоже на мем про троллейбус из буханки.

Поэтому если проект доживёт до отдалённого светлого будущего, я возможно заменю бэк на готовый: https://c9x.me/compile/ , потому что с нуля писать бэк такого вида в мои планы не входит.

Исходная версия wandrien, :

Отслеживание загрузок выполнено так, что в таблице вида Узел Привязка[Регистр] мы указываем, какой узел дерева сейчас в регистре. А потом сравниваем с тем, какой узел сейчас компилируем.

Там конечно сложнее всё, так как нужно правильно учитывать сброс привязок, и также к одному регистру может быть назначена не 1 привязка, а 2.

Но общий принцип вот такой простой.

а место в памяти где она лежала уже не строго зарезервировано за ней, а может быть переиспользовано какой-то другой переменной, которая либо появилась в середине кода, либо до этого лежала в регистре а теперь больше не нужна.

Конкретно этого я делать скорее всего не буду, вот устранение избыточного сохранения регистра в память в кейсах, которые не сложно отследить в случае с трансляцией из дерева, наверное сделаю попозже, как руки дойдут.

А продвинутые техники оптимизации требуют смены внутреннего представления с синтаксиского дерева на граф элементарных блоков операций. Потому что если не менять представление, то дальнейшее всё больше будет становиться похоже на мем про троллейбус из буханки.

Поэтому если проект доживёт до отдалённого светлого будущего, я возможно заменю бэк на готовый: https://c9x.me/compile/ , потому что с нуля писать бэк такого вида в мои планы не входит.