Обратный ход

[bw]

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

p.s. Поясню. В реальных условиях под инструкциями можно (нужно?) понимать операторы языка и прочее, чем последний оперирует.

..bw

[alexs]

а разве можно интерпретировать команды процессора в обратном направлении? там будет не однозначность сплошная

[bw]

Я думаю что можно, а почему нет.
Мы все же тут создаем самый лучший язык программирования и компилятор в мире. Поэтому с такой позиции стоит рассмотреть все возможности и новые идеи, иначе получится тот же Pascal, может скрещенный с Python, C и/или другими языками.

..bw

[alexs]

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

[ev]

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

[alexs]

да - для отладки нужно будет учитывать обратный ход времени
т.е вместо "+" ставить "-" и т.д.

[Vadim]

Итак, что у нас, в результате, получится? Можно по клаве бить кулаками, всеё ладонью, головой. Неважно какие символы вводятся. Процессор сам составит из этого винигрета программу.

[Bupyc]

Вопрос: а зачем это нужно?

[alexs]

практический смысл - посмотреть - а что было в программе 5 шагов назад - идея в принципе инетересная - но трудная

[shade]

практический смысл - посмотреть - а что было в программе 5 шагов назад - идея в принципе инетересная - но трудная

Может просто тогда записывать "трассу", и предоставить возможность откатиться назад.. Типа как отмена в редакторах. Можно на каждый шаг либо запоминать состояние процессора либо (набор регистров), либо запоминать только изменные регистры..

[alexs]

а если ты поставил бряк-поинт?
всю трассу исполнения программы писать несколько накладно - ты не находиш?

[Sergei I. Gorelkin]

Если есть команда вида 'mov ebx, 1', то откуда брать предыдущее значение этого регистра?

А полная трасса, в общем-то, вполне реальна. Вон, valgrind по сути интерпретирует машинный код, для каждой инструкции вызывая свой обработчик. Емкости современных винтов тоже вполне адекватны задаче.

[wavebvg]

Это нереально всё забекапить ))), но только так это мона реализовать
Реальнее провести анализ всего кода (что-то вроде компиляции наоборот) и выявить все возможные переходы, после этого пожно будет добиться какого-либо "сжатия бекапов"
Грубо говоря так:
Создаём поток для каждой команды (адреса перехода в нашем исходном коде, который при трассировке осуществляет переход), причём индексируем его (то бишь называем) в соответствии с тем куда перешёл а записываем адрес откуда. Если уже есть поток с таким именем, то просто дописываем в него ещё одно значение, как попал на данный адрес.
Параллельно, в файле отладки (или как его там не назови), записываем индекс потока, перехода в этом потоке и прочее, в результате получаем, что при желании можно будет откатиться назад (т.е. перейти на кусок кода, который был раньше, просто подменив адрес в переходе)
Но при этом надо ещё как-то реализовать откат введённых данных и изменение сотояний переменных, что будет довольно трудоёмко, т.к. циклы вообще никак на обработаешь...

[Brainenjii]

Отладчики и так глючные ^_^

[unC0Rr]

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