Формат EXE/DLL для новой ОС

[Alex/AT]

Обновил спецификацию - учел кое-какие пожелания...

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

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

[acidrain]

Стасик, разве ты не понял ещё? Тут пцшно-линухово-виндозный заговор, искусно организованный засланцами с пц =) Так что амижные идеи в спекооси не пройдут =))))

Надежда, Вадик, умерает последней! =)

[acidrain]

Цитата:
Сообщение от lvd
А вообще ничто не мешает взять winUAE и с некоторой помощью других амижников разобраться до любого уровня =)

каких других? у нас в городе ни одной амиги насколько я знаю нету.

А кроме Таганрога есть еще крд мск и прочие города России. если есть нужда - поможем всей тольпой =)

[GriV]

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

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

[GriV]

2Alex/AT> однако та информация, которую ты привёл в начале треда мне абсолютно ничего не говорит. Лучше бы ты привёл полноценное описание и прикрепил это чтобы каждый мог посмотреть. Одни условные обозначения (типа segment adress) мало о чём говорят...

[lvd]

каких других? у нас в городе ни одной амиги насколько я знаю нету.

Для винуае амижники под рукой не необходимы (в отличие от случая, когда с дискет надо оживить реальную амигу - тут все клоны вг93 в пц отдыхают =).

если орг по круглому адресу- нет проблем. а гарантировать такое для приложений- вполне реально

Вопрос был в том, если вы уж городите релоцируемые ехешники, то в них блоки с выравниванием по хотя бы 256 байт будут?

__extern "diff",diff
ldh_ a,diff
;ldl_ a,diff

;somewhere in other module
__public "diff",constant,microtable-megatable
;__public "diff",constant,'microtable-'megatable

Ууу...

сказывается разница менталитета. для спектрумиста ассемблер- это неразлучная парочка компилятор+редактор. и для полной шведской семьи +отладчик %)

Раз так, то заявляю, что у меня для спектрума, для амиги и для пц менталитет разный (всего 3 варианта). =) А у тебя?

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

Никто не мешает, вопрос в том, кому он нужен. Аласм и то, несмотря на интегрированность с редактором, довольно-таки коматозен. Что будет, если каждый раз надо будет прибить редактор, записать на диск текст, загрузить с диска компайлер (==командная строчка?), откомпилировать с диска на диск, линкануть, не дай бог, с диска на диск, загрузить результат с диска в память, убедиться, что повисло наглухо, 5 минут терпеть загрузку оси, и всё с начала... Нее, лучше уж аласм! =)

[Advertiser]

[Vitamin]

Для винуае амижники под рукой не необходимы (в отличие от случая, когда с дискет надо оживить реальную амигу - тут все клоны вг93 в пц отдыхают =).

неюзабельно по причине отсутствия
-опыта
-времени
-эмулятора %)

Вопрос был в том, если вы уж городите релоцируемые ехешники, то в них блоки с выравниванием по хотя бы 256 байт будут?

ну стартовый адрес образа процесса если выровнен по границе, от него можно и плясать дальше

Ууу...

тада расскажи как эта проблема решается в предложенной структуре. авось каку идею хорошую можно будет слямзить %)

Раз так, то заявляю, что у меня для спектрума, для амиги и для пц менталитет разный (всего 3 варианта). =) А у тебя?

у меня 3 менталитета- для спека, для винды и для линуха %) хотя последние два довольно тесно склеены (причем результат близок к первому). во загнул! %)

Никто не мешает, вопрос в том, кому он нужен. Аласм и то, несмотря на интегрированность с редактором, довольно-таки коматозен. Что будет, если каждый раз надо будет прибить редактор, записать на диск текст, загрузить с диска компайлер (==командная строчка?), откомпилировать с диска на диск, линкануть, не дай бог, с диска на диск, загрузить результат с диска в память, убедиться, что повисло наглухо, 5 минут терпеть загрузку оси, и всё с начала... Нее, лучше уж аласм! =)

зачем прибивать редактор? многозадачная система вообщето может позволить запуск нескольких процессов. туда же и зависание. от бесконечных циклов спасет опять же многозадачность, от порчи памяти только не убережет....

[Alex/AT]

Раз уж пошла такая пьянка, дам небольшие пояснения к приведенному описанию:

1. Оно опирается на структуру памяти, приведенную мной в разделе "менеджер памяти".

2. Вся память кода и данных делится на т.н. сегменты. Предельный размер сегмента кода в "стандартной" архитектуре - 16 кб (страница), данных - для статических сегментов данных (возможно, вместе с кодом) - до 16кб минус код при размещенни вместе с кодом, до 8 кб - при произвольном размещении, для динамических сегментов данных - до 8 кб. При повышенных возможностях архитектуры (замена #8000-#BFFF) эти лимиты возрастают.

3. Сегмент представляет из себя просто блок в памяти. Блоки кода и связанные блоки данных располагаются между #C000-#FFFF, статические несвязанные данные и динамические данные - в свап-области.

4. "Связанность" сегментов - это нахождение сегментов в одной странице (есть флаг, позволяющий указать именно такое расположение).

5. Несвязанные сегменты кода для вызовов между ними требуют использования процедуры ISC (Intersegment call). Она выглядит как CALL #xxxx; DW #yyyy, где xxxx - это процедура переключения страницы, yyyy - адрес в странице.

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

7. Segment index - системный номер сегмента (в файле - номер сегмента ZE/ZL). Internal address/Offset - смещение от начала сегмента.

8. Кроме всего прочего, существует набор системных вызовов (обсуждался ранее) и переменных, адресуемых по номерам (вместо номера подставляется реальный адрес).

Думаю, это прояснит некоторые моменты.

[lvd]

неюзабельно по причине отсутствия
-опыта
-времени
-эмулятора %)

Ну - а я что говорю? -
http://zx.pk.ru/showpost.php?p=9265&postcount=5

тада расскажи как эта проблема решается в предложенной структуре. авось каку идею хорошую можно будет слямзить %)

В какой ещё предложенной структуре? В формате hunk'ов? Там эта проблема решается очень просто - применением 680x0 процессора =)

зачем прибивать редактор? многозадачная система вообщето может позволить запуск нескольких процессов. туда же и зависание. от бесконечных циклов спасет опять же многозадачность, от порчи памяти только не убережет....

Да - зачем прибивать? А если всё в памяти сидит, то причём тут командная строка? Или у тебя IPC такое - через командную строку? =)
Далее. В памяти сидит редактор, ассемблер, линкер, куча сорцов. Ассемблер компилит в объектники - тоже в память. Объектники линкуются в ехешник - тоже в память. При этом тексты остаются ещё в памяти. Так? =) Или своп на диск? Если второе, то тогда чем эта ось лучше аласма получается? %)

[random]

два слова:
рам диск.