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

[jerri]

Дим, как писать программу не используя CALL:RET?
что это будет за программа?
тут только один вариант
ld iy,return_adress
ld ix,procedure_adress
jp cheduler_call
return_adress
jp cheduler_ret
procedure_adress
jp cheduler_ret

по приходу на cheduler_call сторим iy и переходим на ix
по приходу на cheduler_ret возвращаемся на последнее сохраненное

но у меня слов нет по такому извращению
проще и быстрее будет интерпретатор ЯВУ типа FORTH или тотже оберон

[Vitamin]

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

Условие кривых программистов, не умеющих пользоваться кооперативной многозадачностью?

[alone]

Как выглядит архиватор при кооперативной многозадачности?

[Vitamin]

Как выглядит архиватор при кооперативной многозадачности?

Вызвать yield на каждый процент прогресса, не? Или явно вызвать resсhedule при нехватке памяти не?

[alone]

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

[Vitamin]

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

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

[Advertiser]

[Barmaley_m]

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

Даже если программа содержит баг и не будет никогда вызывать упомянутый системный вызов - максимум, чем это грозит - это повышенной фрагментацией памяти. Это не крах системы. А с учетом того, что у Z80 нет защищенного режима, крах системы из-за бага в программе может произойти по тысяче других причин (DI/HALT, например).

[alone]

А если быть готовым, что программа будет прервана в любой момент, то на всех машинах будут абсолютно лишние затраты.

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

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

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

[Vitamin]

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

Под прерыванием программы я подразумеваю ее останов и релокацию.

[Barmaley_m]

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

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

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

Все равно, релокация программ не является критичной функцией системы. Она может подождать. Пока система ждет, что какая-нибудь программа позволит себя релоцировать, она может выполнять эту и другие программы, то есть эффективный прогресс работы ОС будет продолжаться.

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

Ситуация облегчается тем, что дефрагментация памяти по необходимости (а не фоновая) не требует обязательно релоцировать конкретную программу. Задача стоит освободить непрерывный блок, где бы он ни находился. Если одновременно работают несколько задач - то даже если одна из них не готова к релокации, то могут быть готовы другие. Их и релоцировать.

---------- Post added at 23:46 ---------- Previous post was at 23:33 ----------

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

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

А еще эффективнее - не по килобайту, а по заранее рассчитанному объему работы, который даже на медленных компьютерах не будет выполняться дольше секунды. Тем самым минимизируется количество даже проверок таймера.