Эксперимент

[SfS]

Просмотрел. Впечатляет.


Одно "но"! (Прошу не обижаться на критику.)

Выкинь нафиг интерфейсы пользователя из ОС.
Это должны быть внешние программы. Однозначно. Зачем юзеру, который пользуется ГУИ командный интерпретатор ? Зачем к ОСи присабачивать нортон-подобный довесок ? Пусть все это лежит на диске. Надо - загрузил. Надо - выгрузил.

В остальном - покритикую после подробного прочтения.

[acidrain]

Если не затруднит в будущем напишите поконретней, с чем не согласны, как лучше, чем хуже. Хочется для людей делать, а не как всегда не пойми для кого. Если этот проект дойдёт до какого-то логического завершения, то я скорее буду на спеке сидеть на 60% больше, нежели щас. И неплохо было бы к спеку FLASH или ещё что-нить из новых девайсов прикрутить, чтоб полноценно можно было работать.

Уважаемый спектрум!
=)

Как я уже говорил - не дочитал. Например, из двух вариантов вызова системных функций второй меня устроит больше, а rst #xx - утопия, хотя и экономия памяти (? зачем, спрашивается, если, например 256 кб?) по тому, что ограничиваем сами себя - потом будем нагромождать всякие патчи для оси тп лишь бы добавить либлу или еще чего. Потом многозадачность - это для меня основа оси. Резиденты -это что вообще такое? Процессы? Или скрытые части проги, тихо затаившиеся, как в мониторе стс, например =)? Зачем они нужны?
А остальное - после, как дочитаю

[axor]

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

А я все-таки за rst xx, db xx... Это структурирует программу, легче запоминается, легче воспринимается другими (на случай, если кто-то будет доделывать твою прогу).

[axor]

Скорость и размеры не смущают? А если ПЗУ не трогать, то делать перехват RST?...
А здесь в асме получается типа CALL function (здесь указываешь поимённое название, а не адрес), а после компиляции получишь уже вызов внутри таблицы JUMP-ов. Этот способ занимает 6 байт (типа - вызов, декодирование кода функции, переход). Сдесь только наверно важно договориться о правилах передачи, возврата параметров или всё будет зависеть от той области (уровня) с которым ты работаешь.

RST выглядит наглядно, только для кого? Или всё-таки смущают фиксированные адреса функций? Ты же когда пишешь игры ты же не используешь что-то типа RST, а делаешь CALL или JUMP. А для фиксированных адресов нужно делать резервацию для дальнейшего расширения.

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

А зачем тогда ОС, если все и так пишут CALL. Может возьмем кучу программ и будем использовать их возможности (CALL)?
Шутка конечно.
Но прямой CALL мне не нравится. Представь, сколько их будет? Даже если и будет отдельный файлик в котором они прописаны.
Да, и на счет расширения как поступать? Сделать таблицу на x байт длиннее на будущее? А если опять не хватит, что потом? Нужно все равно как-то ограничивать кол-во функций. Хотя бы по тем разделам, которые ты предлагаешь.

[acidrain]

RST выглядит наглядно, только для кого? Или всё-таки смущают фиксированные адреса функций? Ты же когда пишешь игры ты же не используешь что-то типа RST, а делаешь CALL или JUMP. А для фиксированных адресов нужно делать резервацию для дальнейшего расширения.

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

Опять 25. Я уже выкладывал по амижным библиотекам инфу? Так вот, умные люди там сделали так: В инклудах хранится смещение, которое перед вызовом функции записывается в виде (макрос) CALLINT LockPubScreen
Где:
callInt - макрос, на самом деле заменяется командой jsr /1(a6);
LockPubScreen - это смещение, заданное заранее (например, LockPubScreen EQU -277 - адрес от "фонаря" - не проверяйте ).

Результат этого макроса таков:

jsr -227(a6)

В итоге получается, что происходит вызов функции со смещением -277 от адреса прописанного в адресном регистре А6. При всем при этом, изменение адреса расположения функции в самой библиотеке не несет за собой переделку всех заранее установленных смещений.
Отсюда возникает вопрос - ЗАЧЕМ нужен подход (который пытался применить Shaos в разрабатываемой им для спринтера оси), когда идет вызов по НОМЕРУ функции, это ведь чистой воды бред. Или я опять не прав? Причем я пытался это разжевать И Shaos, но видимо мои речи не столь понятны окружающим, как мне самому ))

[acidrain]

Гибкое изменение - это возможность в области, где прописаны JUMP-ы, менять адрес перехода (или вообще например - RET поставить).
Эта область нужна только если будут меняться адреса функций уровней ОС от версии к версии, для обеспечения совместимости адресов вызовов.

Тут я, увы, вообще не понял о чем Вы говорите. Причем тут версии оси или либлы? Я говорил за общий подход по вызову библиотечных (или ядренных ) функций. Предложил упрощение.
И, пожалуйста, не называйте меня на Вы, ок? =)
Не стоит забывать, также, что амига ось полностью релоцируема, кроме жестко зафиксированного адреса $4.w.
Как тут обстоит дело с осью для спеки? Вообще, прорабатывались ли варианты релоцируемости?
Для разъяснения моих мысле по поводу системных вызовов напишу код:

            ld     hl,dosbase
            ld     a,-36          ; open file
            sbс  a,hl             ; к сожалению, не помню как это на z80 пишется =)
            call   (hl)            ; тоже самое =)
            ...

dos.library:
             ret
; library info
; -"-"-
             ...
openfile   jp      #26a0   ; тож фанарный адрес ;)
             ...
             ret
             ...
#26а0     ...
             ret

Принцип понятен? =)

[acidrain]

В соседнем форуме:

Mac Buster
PostPosted: 03 Feb 2004 16:43 Post subject:

Quote:
Все таки по поводу ОС несколько слов:
- стоит ли поддерживать фат для жестких дисков?


Очень не хочется, но в виде отдельного модуля файловой системы придется поддерживать эту fs.

Quote:
Может использовать какойнить другой формат попроще, что там в Амиге?


У Амиги свои файловые системы и большинство из них значительно сложнее fat.

Quote:
Ибо FAT мне важен если честно только на флопах, чтобы туда-сюда таскать проги...


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

Quote:
Обрисуй всетаки что там у тебя ожидается?


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

Есть идея сделать следующее - так как обращение к функциям связано с некоторыми затратами времени на копирование аргументов, можно сделать некоторые функции в виде релоцируемых модулей, которые по запросу приложения могут быть скопированы в 64К отведенных задаче для самостоятельного максимально быстрого использования. Но это дело далекого будущего Из раздела «а почему-бы не сделать».

Вот так-то =)
только не пойму, почему опять отдельно от мира спекки?

[acidrain]

;Программа CALL fun1 .......... .......... ;Область переходов fun1 JP _fun1 fun2 JP _fun2 fun3 JP _fun3 fun4 JP _fun4 .......... .......... ;Здесь сама функция fun1 .......... .......... Всего функций - неограничено Длина команд - 6 байт

Ну, а дальше - версия 1.11 ядра системы, прийдется все include менять? =)

Я когда писал - торопился на работу, в связи с чем ошибся там надо проще:
call dosbase+openfile ; что составляет три байта %) и количество ф-ций не ограничено (ну, скажем до 65536/3 ~ 22 тыс. ф-ций) Если кнечно асм реальные числа может считать - тогда вообще нет ограничений, теоретически

[acidrain]

Хм..я вообще предполагал делать сборку "для себя". Причём тут include? Они будут всегда на месте ведь адрес CALL то будет определён в качестве стандарта - навсегда. Как ты насчитал 3 байта если один CALL 3 байта занимает? В моём варианте вызов функции - это вызов в области перехода, где номер функции является смещением через 3 байта (потому, что там JUMP). По моему проще не бывает и регистры для определения номера функции (и вообще) не используются. Я сам на практике знаю, что если использовать регистры при вызове функций ядра то иногда просто не знаешь как передать параметры в функцию, чтобы это было не накладно. Если есть желание что обсудить, то пишите в приват, почту или в асю. А то тема так разрослась, что скоро людям не интересно читать будет.

А релоцируемость? Как ты собираешься адрес делать фиксированным? Поэтому и используют некую базу, прибавив/убавив от которой получим адрес фызова функции. А насчитал элементарно, как и ты, впрочем =)
Я не знаю скоко салл занимает в памяти (уж лет так 10 не писал для спеки ничего =)), а знаю, что jp addr - ровно 3 байта, так и посчитал. =)
Я постучался в аську

[axor]

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

Так как все-таки на счет расширения количества функций с применением прямого вызова?

Кстати в оправдание (может быть) call смотрите вложение.