я бы предположил: hl=адрес буфера откуда копировать, de=адрес буфера куда копировать, оба буфера вне страницы. sys_readblock заполняет source-буфер новыми данными, когда они кончатся, sys_writeblock - сохраняет destination-буфер, когда он заполнится. т.о., подобным методом можно сильно экономить время на переключении банков.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
>обновляются через LDIR
Да можно и не мелочиться, а передавать буфер параметром через стек, тут это вполне себе легитимно =)
буфер, да еще и известного размера - конечно можно. а тот код был, в основном, для файлов/пайпов.
Просто взять и подключить требуемую стр. в первую банку(#4000) допустим. Указатель трех байтовый должен быть, байт на стр. и два на смещение.С многобанковостью есть одна единственная закавыка - как обрабатывать память в другой странице, на которую передан указатель.
И под глобальные переменные,аргументы и под глобальный стек использовать только одно адресное пространство для всех прог, те же #4000-#7FFF(Я так и делаю впрочем).
Но такой фокус прокатит на малом количестве клонов(АТМ, пентева и т.п. "спектрум-несовместимые").
---------- Post added at 12:24 ---------- Previous post was at 12:12 ----------
Одна(как минимум) пейджа потребуется для таблицы текущих загруженных библиотек, но это уже фундаментальная философия.
---------- Post added at 12:32 ---------- Previous post was at 12:24 ----------
Насчёт регистров очень не согласен, в некоторых случаях может не хватить. Лучше использовать стек. Один фиг часть аргументов, при попадании в функцию, тут же сохраняются на стеке. В регистрах можно передавать номер либы и номер функции в ней. Результат, согласен, однозначно в HL (HLDE если DWORD).Вызов всех процедур libc через диспетчер (0008h) осуществляется с передачей параметров (и результата) в регистрах
Последний раз редактировалось DimkaM; 01.08.2011 в 12:14.
Это все понятно. Так я и делаю в Орионе, с учетом различий в расположении и размере некоммутируемых областей (и очевидно - это решение только для ASM). Итог, как и писано парой постов выше, при интенсивном IO имеем замедление в 1,5-2 раза в сравнении с ограниченной по памяти классической 64к-шной моделью. Тут наверное просто надо подойти философски, и заведомо отсечь в игнор выкрики с мест типа "вот! у вас медленно! а мы говорили!", которые совершенно очевидно последуют позже.Сообщение от alone
---------- Post added at 15:50 ---------- Previous post was at 15:40 ----------
Большое количество параметров процедур чаще всего говорит о неструктурированности кода. Если есть нужда, можно использовать структуры и указатель на них. Т.е. опять мы возвращаемся к "а что делать с указателем на страницу, которая не дай т.н. б-г не включена в 64к адресного пространства", или "а как быть если С-стек или куча после переключения диспетчера остались в страничке, не включенной в 64к адресного пространства" и подобными.
Я вижу решение в разделении кода на модули, сокращении передаваемых между ними параметров и передаче их в регистрах, а при необходимости (когда надо обрабатывать указатели на struct, array) - таки да, межстраничные пересылки во временный буфер (а если надо, то и обратно). Таких мест не будет много, КМК.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Если есть нужда, можно использовать структуры и указатель на них.
Интересное замечание. Надо попробовать использовать в своём коде.
По сути достаточно одного аргумента с указателем на переменные."а что делать с указателем на страницу, которая не дай т.н. б-г не включена в 64к адресного пространства", или "а как быть если С-стек или куча после переключения диспетчера остались в страничке, не включенной в 64к адресного пространства" и подобными.В приказном порядке.под глобальные переменные,аргументы и под глобальный стек использовать только одно адресное пространство для всех прог, те же #4000-#7FFF(Я так и делаю впрочем).
Прочитал немного, смотрю оживление и сдвиги, но наткнулся на срачь ))), промотал. К чему пришли опорные стандарты машин для ОС всё же ? Было множество предложений, из которых, как мне показалось нужно учесть максимум ).
128 к например 1е ядро кода... Самое нижнее, минималочка... Держит именно одно окно, и именно со стеком в нижней памяти (именно как прозвучало где то на 16й странице). Главная задача (цель поддержки) - успешный запуск образов хранимых на винте. И манипуляции ими. Пусть будет некоторая медлительность, минимум функций, но по сравнению с тапе лодером это ничто ))). Почему то мне кажется, что и запуск с винтов виртуальных TRD будет не намного медленнее, чем с реальных дискет. Даже пусть в 2 раза, это приемлимо. Однако, что важно - пользователи разных пентагонов 128, которых однако немало, и других клонов 128, имея минимальную память СМОГУТ юзать ось, если подключат винт и сменят пзу.
Под более серьезные машины Ось ПРИ УСТАНОВКЕ ) определит карту памяти под конфигурацию с несколькими фреймами (профи, атмки и более новые атм2, пентева) Возможности машины, в частности обьем памяти и скорость сохранения - чтения данных (ведь именно это будет слабым местом оси+128к) возрастут, откроется платформа для написания серьезных приложений, которые не пойдут на 128к возможно, но на пц тоже есть минимальные требования у софта и это нормально.
Расширения и назначения - придерживаюсь всё того же мнения. trd - это 640к образ, который может запускаться как exe, tap это ленточный образ, который тоже может запускаться как exe, в обоих случаях после сброса (физического) нам нужно возвращаться в ось в то же самое состояние откуда мы ушли. Мы нажав так сказать "Закрыли" приложение и продолжаем работу. exe сделать запускаемым файлом в асме со строго регламентированым адресом начала. (естественно выгружаем предварительно ось из памяти в область на винте что бы подготовить к возврату после сброса). И главное - эти приложухи могут юзать абсолютно всё и иметь собственную длинну хоть 200 метров. Но следует жёстко ограничить допуск приложению к областям винта вне области тела приложения. Как это сделать я пока не додумался (((...
Не стоит забывать про виртуальную память, которую необходимо просто (особенно потребуется 128к машинам) регламентировать на винте и использовать и приложениями и осью...)))))))
Последний раз редактировалось Splinter; 28.11.2011 в 22:46.
>>Не стоит забывать про виртуальную память
Не стоит также путать виртуальную память и подкачку. Если с подкачкой при переключении страниц всё ок, то с остальными плюшками совсем грусть, MMU то полноценного нету.
Не всё ок. При подкачке нельзя пользоваться физическими номерами страниц (типа запросил страницу, и тебе дали номер). То есть при каждом обращении к диспетчеру страниц будет ацкий пересчёт по таблице, тактов на 200, а то и 300.
имхо, 200-300 тактов для ос - это вполне нормально. просто нужно на это рассчитывать и проги писать соответственно, уж не копировать 1 байт на 1 переключение странички. да и, так-то, убыстрить можно таблицами, на сколько это вообще возможно.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
