Всем привет. Сейчас выложу описание формата ZE/ZL (ZX Executable/ZX Library) для новой ОС. Еще не закончено, некоторые моменты отсутствуют. Просьба комментировать, модифицировать и дополнять.
Вид для печати
Всем привет. Сейчас выложу описание формата ZE/ZL (ZX Executable/ZX Library) для новой ОС. Еще не закончено, некоторые моменты отсутствуют. Просьба комментировать, модифицировать и дополнять.
Описание:
Не сделано: Import/Export.Цитата:
ZE/ZL (ZX Executable/ZX Library) structure (as defined for version 1.00):
02 'ZE' or 'ZL' signature
02 ZX Executable version (0112h means 1.12)
04 File length
02 Number of segments (A)
04*A Segment descriptors
02 Number of imported functions (B)
??*B Imported function descriptors
02 Number of code modifications (C)
??*C Code modifications
?? Segment data (sequential, by descriptors)
------------- ZL extensions begin
02 Number of exported functions (D)
??*D Exported function descriptors
Segment descriptor:
02 Segment length
01 Flags
0: 0 = code segment, 1 = data segment
1: for code: 0 = near segment (must be placed in the same page with
previous segment), 1 = far segment (may be placed anywhere)
for data: 0 = static segment (must be swapped to certain location),
1 = dynamic segment (may be located anywhere)
2: for code: 0 = frequent ISCs (active participant of intersegment
calls), 1 = rare ISCs (rarely called by intersegment call)
for data: 0 = swappable segment (may be swapped), 1 = must be
placed with previous segment)
3: 0 = normal segment, 1 = shared memory segment (in common RAM)
4: 0 = normal segment, 1 = empty segment (filled with 0s, no real
data in ZE image present)
5-6: alignment (00 = 1 byte; 01 = 16 bytes; 10 = 256 bytes; 11 =
4096 bytes)
7: reserved
Code modification:
01 Modification type
0: internal call/data access
1: intersegment call
2: intersegment data access
3: intersegment pagination (swap)
4: internal high byte
5: internal low byte
6: intersegment high byte
7: intersegment low byte
8: imported function (intersegment)
9: imported data (intersegment)
10: imported pagination (intersegment)
11: imported high byte (intersegment)
12: imported low byte (intersegment)
13: system call
14: system variable
15: two addresses difference
16: two addresses difference high byte
17: two addresses difference low byte
18-255: reserved
Modification 0:
02 Segment index
02 Internal address (+0/1: added to segment start)
Modification 1:
02 Segment index
02 Internal address (+0/1: replaced by call pointer,
+2/3: added with segment start)
Modification 2:
02 Segment index
02 Internal address (+0/1: added to segment start)
02 Target segment index
Modification 3:
02 Segment index
02 Internal address (+0/1: replaced by page number)
02 Target segment index
Modification 4:
02 Segment index
02 Internal address (+0: added to high result byte)
02 Target internal address
Modification 5:
02 Segment index
02 Internal address (+0: added to low result byte)
02 Target internal address
Modification 6:
02 Segment index
02 Internal address (+0: added to high result byte)
02 Target segment index
02 Target offset
Modification 7:
02 Segment index
02 Internal address (+0: added to low result byte)
02 Target segment index
02 Target offset
Modification 8:
02 Segment index
02 Internal address (+0/1: replaced by segment index (call ptr),
+2/3: added to offset or replaced by 2xNOP)
02 Imported function index
Modification 9:
02 Segment index
02 Internal address (+0/1: added to target address)
02 Imported function index
Modification 10:
02 Segment index
02 Internal address (+0/1: replaced by page number)
02 Imported function index
Modification 11:
02 Segment index
02 Internal address (+0: added to high byte of the target address)
02 Imported function index
Modification 12:
02 Segment index
02 Internal address (+0: added to low byte of the target address)
02 Imported function index
Modification 13:
02 Segment index
02 Internal address (+0/1: replaced by segment index (call ptr),
+2/3: added to offset or replaced by 2xNOP)
02 System call index
Modification 14:
02 Segment index
02 Internal address (+0/1: added to target address)
02 System variable index
Изменения: учел кое-какие пожелания из ответов ниже.
так, для информации =)
частично перевел, но простите - не все =( - времени не хватило =)
предлагаю делать Exported Function и в обычных EXE. Простейший пример start, autostart.
Стасик, разве ты не понял ещё? Тут пцшно-линухово-виндозный заговор, искусно организованный засланцами с пц =) Так что амижные идеи в спекооси не пройдут =))))Цитата:
Сообщение от acidrain
Да, вполне реально. EXE тоже сможет экспортить функции, которые, к тому же, могут быть подключены дочерними DLL. Обязательно учту при дальнейшем описании.Цитата:
предлагаю делать Exported Function и в обычных EXE. Простейший пример start, autostart.
Блин. Тут не то что амижные, тут вообще никакие не пройдут. Ибо адресное пространство у спека - всего лишь 16 бит... Вот поэтому приходится изголяться. А в доках по ханкам меня порадовала надпись "Неизвестная структура" =)Цитата:
Так что амижные идеи в спекооси не пройдут =))))
мля... вдарились в винду- подпихиваем линух. стали глядеть в сторону линукса- тоже не так, подавай амигу. а у многих она есть? я лично видел ее всего один раз в работе так что абсолютно ничего не знаю насчет принципов работы.Цитата:
Сообщение от lvd
а насчет доки. довольно интересно. Hunks == Chunks? ;) они же секции в файлах PE-формата? всетаки надо стараться чтобы количестви лишней информации в бинарниках стремилось к минимуму- поэтому нет особого смысла в символьных названиях секций (насколько я понял, они присутствуют). если рассматривать то, что я до этого предлагал (модульную структуру), то можно также сказать, что она состоит из четырех ханков- таблица релокации, таблица символьных имен экспортируемых точек, таблица символьных имен импортируемых точек, код. в исполняемом файле можно оставить только первую и последнюю точки. для динамических библиотек еще нужна таблица экспортируемых точек, чтобы искать адреса во время исполнения. плюс к тому, структура таблицы релокации позволяет корректировать не только 16, но и 8-битные адреса (ld a,.metka:ld h,'font etc).
Принципы работы такие же, как у любого компа - процессор + периферия =)Цитата:
Сообщение от Vitamin
А вообще ничто не мешает взять winUAE и с некоторой помощью других амижников разобраться до любого уровня =)
Неа! =)Цитата:
а насчет доки. довольно интересно. Hunks == Chunks? ;)
Они присутствуют, если это объектник. А если 'эхешник', то отсутствуют. Формат файлов остаётся таким же.Цитата:
всетаки надо стараться чтобы количестви лишней информации в бинарниках стремилось к минимуму- поэтому нет особого смысла в символьных названиях секций (насколько я понял, они присутствуют).
Цитата:
плюс к тому, структура таблицы релокации позволяет корректировать не только 16, но и 8-битные адреса (ld a,.metka:ld h,'font etc).
Код:add a,a
add a,a
ld l,a
ld h,'font/8
add hl,hl
add hl,hl
add hl,hl
Код:org #какой_попало
;some stuff
ld h,'megatable
;more stuff
org ($+255)&#FF00
megatable
db #xx,#yy,... ;256 bytes
Всё подобное, как я понимаю, пойдёт на север? =)Код:
ld h,'megatable
; stuff
inc h
;stuff
dec h
;etc.
;stuff
ld a,'microtable-'megatable
add a,h
ld h,a
...если честно, я вообще с трудом представляю, что в результате того, что вы задумали, выйдет. Сможет ли там существовать приложение уровня аласма, например? С какой скоростью оно будет работать?...
ну да. и че гнать на закос под винду или юних- не понимаю. что есть, то и изучаем.Цитата:
Сообщение от lvd
каких других? у нас в городе ни одной амиги насколько я знаю нету.Цитата:
Сообщение от lvd
а похоже- как по названию, так и по смыслу %)Цитата:
Сообщение от lvd
ld h,'fontЦитата:
Сообщение от lvd
srl h
srl h
srl h
другого варианта пока не вижу. это модули ис-доса могли в себе хранить выражения в ОПЗ. область применения не настолько высока чтоб изза них городить довольно сложную систему.
если орг по круглому адресу- нет проблем. а гарантировать такое для приложений- вполне реальноЦитата:
Сообщение от lvd
__extern "diff",diffЦитата:
Сообщение от lvd
ldh_ a,diff
;ldl_ a,diff
;somewhere in other module
__public "diff",constant,microtable-megatable
;__public "diff",constant,'microtable-'megatable
сказывается разница менталитета. для спектрумиста ассемблер- это неразлучная парочка компилятор+редактор. и для полной шведской семьи +отладчик %)Цитата:
Сообщение от lvd
кто мешает сделать компилятор через командную строку? он тебе может через системные функции или библиотеки в нижней памяти что угодно компилить.
что если вы собираетесь писать чтото новое (в частности ОСь) то вообще говоря прям счаз оно даст одни сплошные минусы:
- Скорость работы приложений отнесённая к чистой производительности процессора будет ниже
- Всё, что невозможно реализовать аппаратно будет реализовываться программно (читай - всё будет реализовано программно)
- Всё потенциальные и реальные плюсы будут для этой системы существовать только после достаточно продолжительного периода времени, когда будет написано много приложений, драйверов и произведена достаточная отладка
Исходя из этого мне непонятно, как вообще можно горить "это будет потреблять много ресурсов", если с самого начала все программные ресурсы будут отдаваться на откуп того, что в других системах реализовано аппаратно?
Обновил спецификацию - учел кое-какие пожелания...
Вообще - да, сам в написании ос вижу много минусов для реальных приложений. Но для работы с текстами + в это время слушания музыки + в это время обсчета чего-нибудь вполне пойдет. Плюс - хорошая практика низкоуровнего программирования в условиях полного зада...Цитата:
Исходя из этого мне непонятно, как вообще можно горить "это будет потреблять много ресурсов", если с самого начала все программные ресурсы будут отдаваться на откуп того, что в других системах реализовано аппаратно?
Надежда, Вадик, умерает последней! =) ;)Цитата:
Сообщение от lvd
А кроме Таганрога есть еще крд мск и прочие города России. если есть нужда - поможем всей тольпой =)Цитата:
Сообщение от GriV
Для таких систем, где нужна полная производительность системы вводится монопольный режим. В этом режиме система сносит все свои блоки в верхнюю память, оставляет лишь самые необходимые трапы. однако в таком случае все положительные моменты, реализуемые системой будут грубо говоря "затыканы" монопольным режимом.Цитата:
Сообщение от Alex/AT
Вот основные трапы, которые нужны для программ в монопольном режиме:
- Загрузка/выгрузка данных на носитель
- Переключение банков памяти
- Получение информации о памяти
- Восстановление системы
2Alex/AT> однако та информация, которую ты привёл в начале треда мне абсолютно ничего не говорит. Лучше бы ты привёл полноценное описание и прикрепил это чтобы каждый мог посмотреть. Одни условные обозначения (типа segment adress) мало о чём говорят...
Для винуае амижники под рукой не необходимы (в отличие от случая, когда с дискет надо оживить реальную амигу - тут все клоны вг93 в пц отдыхают =).Цитата:
Сообщение от Vitamin
Вопрос был в том, если вы уж городите релоцируемые ехешники, то в них блоки с выравниванием по хотя бы 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 минут терпеть загрузку оси, и всё с начала... Нее, лучше уж аласм! =)Цитата:
кто мешает сделать компилятор через командную строку? он тебе может через системные функции или библиотеки в нижней памяти что угодно компилить.
неюзабельно по причине отсутствияЦитата:
Сообщение от lvd
-опыта
-времени
-эмулятора %)
ну стартовый адрес образа процесса если выровнен по границе, от него можно и плясать дальшеЦитата:
Сообщение от lvd
тада расскажи как эта проблема решается в предложенной структуре. авось каку идею хорошую можно будет слямзить %)Цитата:
Сообщение от lvd
у меня 3 менталитета- для спека, для винды и для линуха %) хотя последние два довольно тесно склеены (причем результат близок к первому). во загнул! %)Цитата:
Сообщение от lvd
зачем прибивать редактор? многозадачная система вообщето может позволить запуск нескольких процессов. туда же и зависание. от бесконечных циклов спасет опять же многозадачность, от порчи памяти только не убережет....Цитата:
Сообщение от lvd
Раз уж пошла такая пьянка, дам небольшие пояснения к приведенному описанию:
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. Кроме всего прочего, существует набор системных вызовов (обсуждался ранее) и переменных, адресуемых по номерам (вместо номера подставляется реальный адрес).
Думаю, это прояснит некоторые моменты.
Ну - а я что говорю? -Цитата:
Сообщение от Vitamin
http://zx.pk.ru/showpost.php?p=9265&postcount=5
:p
В какой ещё предложенной структуре? В формате hunk'ов? Там эта проблема решается очень просто - применением 680x0 процессора =)Цитата:
тада расскажи как эта проблема решается в предложенной структуре. авось каку идею хорошую можно будет слямзить %)
Да - зачем прибивать? А если всё в памяти сидит, то причём тут командная строка? Или у тебя IPC такое - через командную строку? =)Цитата:
зачем прибивать редактор? многозадачная система вообщето может позволить запуск нескольких процессов. туда же и зависание. от бесконечных циклов спасет опять же многозадачность, от порчи памяти только не убережет....
Далее. В памяти сидит редактор, ассемблер, линкер, куча сорцов. Ассемблер компилит в объектники - тоже в память. Объектники линкуются в ехешник - тоже в память. При этом тексты остаются ещё в памяти. Так? =) Или своп на диск? Если второе, то тогда чем эта ось лучше аласма получается? %)
два слова:
рам диск.
мда... и после таких заявлений еще возникают фразы о заговоре %)Цитата:
Сообщение от lvd
если уж на то пошло, то лучше сразу по x86 писать и не зарабатывать себе геморрой, благо свобода доступа больше
ты сам так и сказал- прибивать.Цитата:
Сообщение от lvd
а ты собираешься все держать в памяти? редактор-компилятор-отладчик?
первое и последнее вполне могут одновременно сосуществовать в памяти, а компилятор- это прикладная утилита однократного действия.
а насчет рамдиска (см. след. пост)- реальный способ. все утилы обращаются к системе через операции с файлами, а где эти файлы расположены- их абсолютно не касается. вот ты ругаешься на многократность обращений к диску. да, неприятно. а ты пробовал компилять большой проект в аласме на 128к? сколько раз к диску обращается? ;)
Вообще-то это констатация фактов =)Цитата:
Сообщение от Vitamin
На 680x0, ввиду его архитектуры, теряют смысл таблички, выровненные по 256 байт.
Ну - кому геморрой амига и амигаос, а кому - х86 и пц, а также размахивание кем-то горой книжек по линуху с криками 'даёшь форк на спеке!', 'даёшь маппинг файлов на память!' etc. =)=)=)Цитата:
если уж на то пошло, то лучше сразу по x86 писать и не зарабатывать себе геморрой, благо свобода доступа больше
Прибивать==грузить заново с диска (2random - рамдиск конечно хорошо, но зачем грузить из рамдиска, когда можно просто НЕ прибивать? =).Цитата:
ты сам так и сказал- прибивать.
Это как же так? День сидишь редактируешь, потом на вечер оставил компиляться, весь следующий день сидишь отлаживаешь? =)Цитата:
а ты собираешься все держать в памяти? редактор-компилятор-отладчик?
первое и последнее вполне могут одновременно сосуществовать в памяти, а компилятор- это прикладная утилита однократного действия.
Нет. Потому что не мазохист =). Но к диску он обращается исключительно за сорцами и инкбинами, в твоём же случае ещё и за эхешниками лазить будет, и на диск свопить промежуточные результаты (линкер), и грузить эхешники обратно в память для запуска (релоцируемый код).Цитата:
а ты пробовал компилять большой проект в аласме на 128к? сколько раз к диску обращается? ;)
это все хорошо, конечно. только у нас идет разговор об архитектуре z80, о выигрышах выравнивания по границам, обо всех реализациях ОС на других других архитектурах, точнее обо всем полезном, что можно оттуда взять.Цитата:
Сообщение от lvd
%)Цитата:
Сообщение от lvd
я не говорю что мне амига в геморрой- я слишком мало о ней знаю. а мои размахивания (если честно, представил эту картину, обхохотался %) ) ни что иное как попытка поделиться тем, что узнал из книг.
ну я за то и говорю- редактор остается в памяти == не прибивается.Цитата:
Сообщение от lvd
как вариант- передача параметров так, чтоб он файл из памяти компилял в память ну или чтото подобное
типа того %)Цитата:
Сообщение от lvd
if (disk == ramdisk) speed *= 5;Цитата:
Сообщение от lvd
%)
Товарищи, про рамдиск - это бред... полнейший. Ибо придем к обсуждавшемуся уже разок где-то в тредах про ОС "TRDOS+все-все-все". ОС и надо создавать ради того, чтобы отойти от структуры "свап на диск + 32к памяти". Я понимаю, почему это так предлагается - вроде как привычно. Но смею заметить, что тем, у кого есть память на RAM-диск, простое кеширование физического диска, допустим, для компилятора, даст результаты не хуже, чем сам RAM-диск.
P.S. Если такая пьянка - может и правда нуегонафиг. Добавить кеширование в TRDOS, и свапиться на диск...
2LVD: нет реальных предложений по теме - не пиши, это опять из оперы: "нафиг спек, даёшь пц/амигу и проч.". Есть реальные предложения, хорошо, объясни непонимающим пцюзерам как амижные технологии можно без особенностей амижного порца юзать на спеке. А вообще людям интересно вот они и делают. Чего знают из других платформ, до которых имеют доступ, то и применяют, примеривают, так сказать подходы к Спеку. Жалко чтоли, пущай?
Что касается рам-диска, зачем он будет нужен, если память можно будет использовать и без него, если в ОС будет возможность межпорцессного взаимодействия помимо записи на диск? Но это тогда когда это уже будет, пока этого ничего нет, идёт просто обсуждение как это можно было бы реализовать на Спеке. Понятное дело ОС может корректным образом реагировать и на KAY-евский рам-диск и на рам-диск рил командера, но это, ещё раз повторюсь не тема данной ветки, я прав?
По теме:
Тема вроде бы о формате DLL/EXE...
проскакивала тут мысль о том, что можно в exe/dll хранить символические названия вызовов и прочего, для облегчения программирования. Я думаю именно в запускаемых модулях этого делать нет необходимости, лучше, если коэффициент (размер полезного кода)/(размер загружаемого модуля) будет максимальный, а описания вызовов будут описываться в отдельном файле вроде lib или tlb (для COM-объектов). В этих файлах можно сопоставлять текстовые описания либо с номером дескриптора в DLL/exe, либо даже со смещением относительно начала кодового блока - у кого на что фантазии хватит. Вон в MS VB как сделано, он грузит в память все TLB-шки всех ком-объектов, которые собирается использовать, а потом компилит эти слова в соответствующие вызовы. Или в MFC можно сделать Import from Type Library, в результате - класс-оболочка для вызова кода ком-объекта через его интерфейсы. Такую приблуду моно и для аласма написать, которая будет генерить исходник с кучей EQU-шек вроде этого:
; Imported interfaces/calls from blablabla.dll
; Calls
[метка из lib/tlb] EQU [соответствующее значение]
; Static varialbles
[метка из lib/tlb] EQU [соответствующее значение]
; DLL internal enums (например принятые в коде DLL соглашения по обозначению каких-то данных какими-то значениями)
[метка из lib/tlb] EQU [соответствующее значение]
Я собственно всеми силами пытаюсь. Даже доки выкладывал - но их очевидно никто не читал.Цитата:
Сообщение от Corpsegrinder
Да нет, не жалко, но пардон, как назвать предложение сделать форк и маппинг файлов на память на спеке? =)Цитата:
А вообще людям интересно вот они и делают. Чего знают из других платформ, до которых имеют доступ, то и применяют, примеривают, так сказать подходы к Спеку. Жалко чтоли, пущай?
А в амигаоси почему-то рамдиск есть. Вот дураки, зачем-то сделали, когда IPC есть!? =)Цитата:
Что касается рам-диска, зачем он будет нужен, если память можно будет использовать и без него, если в ОС будет возможность межпорцессного взаимодействия помимо записи на диск?
Вадик, не распинайся - им не понять, как удобно жить с рам диском, как на амиге. Не хотят много кайфа на спеке - их дело. мы себе могем и сами его забацать ;) Или еще проще наслаждаться амигой 8)Цитата:
Сообщение от lvd
именно так и назвать: "предложение сделать форк и маппинг файлов". почему-то предложение "сделать многозадачность" не вызывает нареканий, а вот что создание новых процессов именно почкованием- вызывает. странная логика по меньшей мере... эдак можно докатиться и до вопроса "как назвать предложение программировать под спек если в сотовике и то процессор мощнее?" =)Цитата:
Сообщение от lvd
Вот например, главная либла. Найду - вышлю точки входа (смещения) к этой либле...
Дело вовсе не в рамдиске, который конечно же имеет свои плюсы и недостатки.Цитата:
Сообщение от acidrain
Дело в том, что подменять системную память и системный кэш несколько странно...
А вообще, рамдиск это по сути кусок памяти организованный системой как внещний носитель. При едином подходе системы к любым носителям не будет проблем с общением ли рамдиском, ли ROMдиском и т.д.
Проблема будет только в драйвере...
P.S. Так споришь за RAMдиск, как будто отсутсие рамдиска вызовет stack overflow и general protection fault :D
Вызывает нарекание маппинг файлов на память - который в случае отсутствия MMU сводится к обычному 'загрузил-поюзал-отписал', что прекрасно и прога сама сделает, и значит этот мапинг как функция оси не нужен. Форк клонирует весь процесс - всю его память, все данные и даже вроде все открытые файлы/whatsoever. Опять же это происходит не без помощи MMU и copy-on-write. В случае остутствия мму ты просто ничего не склонируешь - потому что 'клон' уже по другим адресам будет валяться и все его внутренние ссылки ты не поправишь.Цитата:
Сообщение от Vitamin
В то же время как multitasking совершенно для своего наличия не требует MMU. Хотя вот контроллер прерываний ОЧЕНЬ желателен, как показала практика =)
Ага, а очко в сотовике лажовее =)Цитата:
эдак можно докатиться и до вопроса "как назвать предложение программировать под спек если в сотовике и то процессор мощнее?" =)
маппинг файлов был продемонстрирован как побочная функция, реализация которой не потребует абсолютно никакиих переделок структуры системы.Цитата:
Сообщение от lvd
далее. форк не обязательно клонирует весь процесс. в минимальном варианте копируется стек и все структуры, предварительно меняя нужные параметры. все остальное- по желанию. зачем копировать всю память для рабочей нити, которая может использовать только часть кодового сегмента?
без мму ты ничего хорошего не сделаешь. есть ресурсы- надо их разделять, руководить ими. если это процессор- есть диспетчер задач, если это память- есть диспетчер памяти. нельзя отделять одно от другого. даже в SOS, которую и операционкой назвать нельзя по большому счету имеются средства выделения памяти (это я про clear)Цитата:
Сообщение от lvd
не знаю. не ковырялся. работаю с тем что есть. к сведению, a51 чип еще труднее в программировании, хотя там есть и контроллер и умножение с делением. так что у нас все козыри на рукахЦитата:
Сообщение от lvd
Угу, до этого не было системы и нафиг она счаз нужна? Как писали тяп ляп так и будем и нафиг нам мультитаскинг?....Цитата:
Сообщение от lvd