В SysFn09 (информация о потоке) имеются зарезервированные слова и байты:
+8: word:
+21 = +0x15: byte:
+52 = +0x34: word:
По этому поводу у меня вопросы:
1) В чём причина резервирования? (подозреваю, что это просто выравнивание на 4 байта, но хочу убедиться)
2) Меняется ли значение зарезервированных слов и байтов? (особенно это касается +8)
3) Есть ли в планах (когда-нибудь в будущем) использовать эти зарезервированные слова и байты?
4) Возможно ли использовать зарезервированные слова и байты? (например, для битовой маски привилегий потоков)
P.S.
Вообще-то есть ещё один вопрос общего характера:
В документации рекоментдуется выделять 1024 (= 1кб) байта для буфера. Пока реально используется только 75 байт. В чём причина более чем десятикратного запаса?
Зарезервированные слова в SysFn09 (информация о потоке )
Могу точно ответит на последний вопрос - наличие зарезервированного места хорошо по умолчанию, есть куда расширять и не надо ломать мозг как добавить новое поле - добавляешь и все.
Насчет зарезервированных могу предложить - лучше не трогать. Неизвестно когда и кем было зарезервировано, но раз написано значит нужно. Есть другие поля в старшей части и можно писать в них. Свободного места полно.
Насчет зарезервированных могу предложить - лучше не трогать. Неизвестно когда и кем было зарезервировано, но раз написано значит нужно. Есть другие поля в старшей части и можно писать в них. Свободного места полно.
Спасибо, Mario.
Но я не совсем удовлетворён ответом насчёт более чем десятикратного запаса:понятно, что зарезервированное место - это необходимо, но почему, например, не 256 байт (тройной запас)? Вот если есть далеко идущий стратегический план, который потребует около 400 - 500 байт, тогда всё становится понятно ...
Но я не совсем удовлетворён ответом насчёт более чем десятикратного запаса:понятно, что зарезервированное место - это необходимо, но почему, например, не 256 байт (тройной запас)? Вот если есть далеко идущий стратегический план, который потребует около 400 - 500 байт, тогда всё становится понятно ...
Кто-то подумал и решил, что 1Кб в самый раз. Это очень в духе Колибри, посмотри memmap.inc .
Serge
При чем тут "дух Колибри"? Это унаследовано еще с Menuet.
При чем тут "дух Колибри"? Это унаследовано еще с Menuet.
Mario
В этом плане не вижу никакой разницы. Там один байт сэкономили, тут с запасом зарезервировали.
В этом плане не вижу никакой разницы. Там один байт сэкономили, тут с запасом зарезервировали.
Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?
Должно быть, тот грустный факт, что в статической области ядра чрезвычайно плотные структуры данных перемешаны с пустыми дырами (в десятки килобайт) и совершенно неуместными там таблицами и резервированными полями.Mario wrote:Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?
имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Насколько я понимаю такая работа велась, потому что некоторые структуры были описаны в виде логических структур, без непосредственного указания смещений относительно общей и глобальной базы, но ее так и не довели до логического финала.art_zh wrote: имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.
Насчет впихнуть в 1 Мб и менее с сохранением всей функциональности - я в это несколько не верю. Либо такая система будет работать ощутимо медленней.
ИМХО, 1024 килобайт вполне нормальный размер для буфера. Во-первых, в той же долбанной Windows, например, есть такая структура - PEB (Process Environment Block) размером ~500 байт. Во-вторых, функция 9 возвращает пока очень мало сведений о процессе - нельзя узнать полное имя исполняемого файла, командную строку, PID/TID родителя, информацию о используемых библиотеках, об IPC, открытых шаред-мемори блоков, открытых TCP/UDP портах, дочерних потоках и т.д. и т.п. .
Если же жажда экономии всё-таки вас не покидает, можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).
Если же жажда экономии всё-таки вас не покидает, можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).
ушёл...
Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).Nasarus wrote:...можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Не совсем понял, как таким образом можно избежать правок существующих программ..art_zh wrote: Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).
ушёл...
Тех которые резервируют менее 1 Кб не получится не править. Впрочем большинство программ используют выделенный буфер в 1 Кб - ибо большинство программистов все-же читают документацию, так как научены горьки опытом.
Mario
art_zh замечательно ответил за меня. Я знаю что это тянется от Менуэт, но сваливать всё только на "темное царское прошлое" неправильно. Было достаточно времени на наведение порядка в данных ядра.
P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?
art_zh замечательно ответил за меня. Я знаю что это тянется от Менуэт, но сваливать всё только на "темное царское прошлое" неправильно. Было достаточно времени на наведение порядка в данных ядра.
P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?
Я бы ответил встречным вопросом - "так чего же сам не навел порядок?", но будет это по аналогии "драк - сам дурак". Надо учитывать что каждый занимается тем чем умеет и главное тем что ему самому нравиться - "Just for fun". Тыкать пальцем во всех и каждого бессмысленно.Serge wrote:Было достаточно времени на наведение порядка в данных ядра.
Вообще-то ты скромно умалчиваешь сколько лет назад это было (мы ведь не рождаемся многомудрыми?), а также не менее скромно что я уже два года как минимум ядром не занимаюсь. Я конечно понимаю чужие недоработки видней - со стороны оно всегда видней.Serge wrote: P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?
И никого не трогает, что когда это делалось менеджер памяти был еще совсем "не торт", он конечно и сейчас не особо "торт" - скорее пирожок или эклер.
Но может не будем сейчас заниматься выискиванием насекомых в головах и мозгах друг-друга?
Я стараюсь придерживаться одного принципа: Можешь сделать лучше другого - делай, а не сокрушайся как все плохо. Последнее контрпродуктивный подход.
Who is online
Users browsing this forum: No registered users and 28 guests