Перемещаемость на лету

[alone]

Придумайте, как писать программу так, чтобы она могла быть в любой момент прервана (INT) и перемещена в памяти (возможно, с пересчётом каких-то ячеек по какому-то списку, возможно, динамически генерируемому). Так что при возврате указатели на переменные или массивы устаревают. И стек вызовов тоже. Допустим, перемещение производится по 256 или кратное число байт.

Мне пока видятся только следующие методы:

1) Типизация стека и регистров. В стек каждый раз пишется не 2 байта, а 4 (данные и тип - число/указатель). Области смены типа регистров, а также EXX'ы обрамляются системными вызовами.

2) Чтение данных по указателям - только через системные вызовы (очень медленно!). В указателях только смещения относительно начала блока программы. CALL и RET - через системные макросы (тоже по смещению, и в стеке лежит смещение точки возврата).

3) CALL и RET - через системные макросы (в стеке лежит смещение точки возврата). Типы регистров никогда не меняются.
Если указатели - HL и DE, то проблема с 16-битной арифметикой.
Если указатели - IX и IY, то всё медленно.
Если только один указатель и буферизация данных в стеке, то ещё медленнее и вообще изврат.
Компромисс - IX и DE (или DE и DE').

4) Интерпретируемый язык (очень медленно!).

[Advertiser]

[Vitamin]

Если код еще можно перемещать, но интерпретация произвольного 16-битного (или даже 8-битного) значения в регистре как изменяемого адреса - это утопия.

Компромиссный вариант- захват ресурсов через системные вызовы. На время захвата гарантируется неперемещаемость ресурса.

[jerri]

Ересь
одна команда LDIR убьет данные
если делать перемещение
ld hl,data1
ld de,data2
ld bc,size
call data_move - то тут я даже не могу предположить как надо извращаться что бы передать 1 байт и не попасть под INT и какую скорость это даст

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

[alone]

Критические секции сделать легко. Идея мне нравится. А какие есть идеи по конкретной реализации CALL-RET?

[Vitamin]

А какие есть идеи по конкретной реализации CALL-RET?

Подфункции? Каждый процесс (я правильно тебя понимаю?) может содержать таблицу патчей для таких целей.

Да, чтоб упростить себе жизнь, процессор объявляется таким же ресурсом, как и память. Т.е. кодовый сегмент процесса может перемещаться только после того, как он (процесс) явно вызвал sleep/wait/yield.

[alone]

Цитата:





Сообщение от alone


А какие есть идеи по конкретной реализации CALL-RET?




Подфункции? Каждый процесс (я правильно тебя понимаю?) может содержать таблицу патчей для таких целей.

Нельзя использовать команду CALL, потому что она кладёт в стек абсолютный адрес.

Т.е. кодовый сегмент процесса может перемещаться только после того, как он (процесс) явно вызвал sleep/wait/yield.

Чревато повисаниями всей системы.

---------- Post added at 16:19 ---------- Previous post was at 16:15 ----------

Поставим вопрос по-другому: можно ли реализовать относительный вызов без критической секции? Если нет, то как это доказать?

[Vitamin]

Нельзя использовать команду CALL, потому что она кладёт в стек абсолютный адрес.

ld hl,subroutine
call Invoke ;system call

Чревато повисаниями всей системы.

С чего это?

[alone]

ld hl,subroutine
call Invoke ;system call

И тут между call и первой командой системного вызова внезапно прерывание. Твои действия?

С чего это?

Глюки программистов неистребимы. Особенно с таймингами.

[Vitamin]

И тут между call и первой командой системного вызова внезапно прерывание. Твои действия?

Вы находитесь в закрытой комнате без окон и дверей и вам нужно выбраться. Ваши действия?

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

Глюки программистов неистребимы. Особенно с таймингами.

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

[alone]

Зачем себе ставить заведомо сложные условия чтоб потом биться о них головой и с криком "ура" преодолевать?

Это условие обусловлено архитектурой 128K.