Да даже если бы и удалось - это никак не решает проблему malloc(65536). И нафига компьютер с мегабайтами памяти, если там нужно на ассемблере возиться с кусочками памяти? А если malloc(65536) нерешаем, то городить диспетчеры и не имеет смысла: в СР/М с 48к ОЗУ TPA уже 25 лет как половина компиляторов умеет работать с так называемыми "оверлеями" - перекрывать область кода/данных кодом из дисковых файлов. Загоняем эти файлы на быстрый электронный диск (любой конструкции) - и получаем решение на стандартной базе.Сообщение от The Exploited
Это было лирическое отступление. На самом деле, соглашусь - диспетчер по 16к годится только на организацию электронного диска из "лишнего ОЗУ", больше он мало на что годится. Страничный диспетчер по 64к менее удобен для эл. диска (медленнее), но он позволяет легко организовывать "коммутируемую многозадачность" - проще простого переключать "целые" странички по NMI. Имея такой диспетчер и кучу ОЗУ впихнуть, к примеру, UZI - проще простого: будет не очень тормозно - проблема со свопом на медленный дисковод не будет такой проблемой, какой она стала для автора UZI в условиях недостатка ОЗУ. Т.е. полезно наличие обоих типов диспетчеров, и не только (а может, и вовсе не для того), чтобы эмулировать расширение адресного пространства.
Еще одна вытекающая мысль: эффективный компилятор (например, С) для недокомпьютеров, способный компилировать компактный код - вещь абсолютно необходимая, имея его может и 64к хватить... И вот парадокс- до сих пор нет такого, а диспетчеров разных вариантов - море. Кстати, и переключением страничек может заниматься сам компилятор, не нужно будет городить аппаратную обвязку (достаточно будет простейшего диспетчера на регистре и мультиплексоре), да и вообще вспоминать про диспетчеры.
Ответить с цитированием