Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Ср ноя 22, 2017 1:57 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 35 сообщений ]  На страницу 1 2 3 След.
Автор Сообщение
СообщениеДобавлено: Чт окт 21, 2010 8:54 pm 
Не в сети

Зарегистрирован: Ср сен 15, 2010 7:22 pm
Сообщения: 101
В SysFn09 (информация о потоке) имеются зарезервированные слова и байты:

+8: word:
+21 = +0x15: byte:
+52 = +0x34: word:


По этому поводу у меня вопросы:
1) В чём причина резервирования? (подозреваю, что это просто выравнивание на 4 байта, но хочу убедиться)
2) Меняется ли значение зарезервированных слов и байтов? (особенно это касается +8)
3) Есть ли в планах (когда-нибудь в будущем) использовать эти зарезервированные слова и байты?
4) Возможно ли использовать зарезервированные слова и байты? (например, для битовой маски привилегий потоков)

P.S.

Вообще-то есть ещё один вопрос общего характера:

В документации рекоментдуется выделять 1024 (= 1кб) байта для буфера. Пока реально используется только 75 байт. В чём причина более чем десятикратного запаса?


Вернуться к началу
СообщениеДобавлено: Чт окт 21, 2010 9:30 pm 
Могу точно ответит на последний вопрос - наличие зарезервированного места хорошо по умолчанию, есть куда расширять и не надо ломать мозг как добавить новое поле - добавляешь и все.

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


Вернуться к началу
   
СообщениеДобавлено: Сб окт 23, 2010 3:33 pm 
Не в сети

Зарегистрирован: Ср сен 15, 2010 7:22 pm
Сообщения: 101
Спасибо, Mario.

Но я не совсем удовлетворён ответом насчёт более чем десятикратного запаса:понятно, что зарезервированное место - это необходимо, но почему, например, не 256 байт (тройной запас)? Вот если есть далеко идущий стратегический план, который потребует около 400 - 500 байт, тогда всё становится понятно ...


Вернуться к началу
СообщениеДобавлено: Сб окт 23, 2010 4:53 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Кто-то подумал и решил, что 1Кб в самый раз. Это очень в духе Колибри, посмотри memmap.inc .


Вернуться к началу
СообщениеДобавлено: Сб окт 23, 2010 5:10 pm 
Serge
При чем тут "дух Колибри"? Это унаследовано еще с Menuet.


Вернуться к началу
   
СообщениеДобавлено: Сб окт 23, 2010 5:38 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Mario

В этом плане не вижу никакой разницы. Там один байт сэкономили, тут с запасом зарезервировали.


Вернуться к началу
СообщениеДобавлено: Сб окт 23, 2010 9:08 pm 
Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?


Вернуться к началу
   
СообщениеДобавлено: Вс окт 24, 2010 1:29 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Mario писал(а):
Serge
Я честное слово не понял что ты подразумевал - можешь развернуто изложить?


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

имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
СообщениеДобавлено: Вс окт 24, 2010 1:56 pm 
art_zh писал(а):
имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.

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


Вернуться к началу
   
СообщениеДобавлено: Вс окт 24, 2010 2:03 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср янв 27, 2010 10:59 am
Сообщения: 269
ИМХО, 1024 килобайт вполне нормальный размер для буфера. Во-первых, в той же долбанной Windows, например, есть такая структура - PEB (Process Environment Block) размером ~500 байт. Во-вторых, функция 9 возвращает пока очень мало сведений о процессе - нельзя узнать полное имя исполняемого файла, командную строку, PID/TID родителя, информацию о используемых библиотеках, об IPC, открытых шаред-мемори блоков, открытых TCP/UDP портах, дочерних потоках и т.д. и т.п. :) .
Если же жажда экономии всё-таки вас не покидает, можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).

_________________
ушёл...


Вернуться к началу
СообщениеДобавлено: Вс окт 24, 2010 3:30 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Nasarus писал(а):
...можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).

Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
СообщениеДобавлено: Вс окт 24, 2010 3:39 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср янв 27, 2010 10:59 am
Сообщения: 269
art_zh писал(а):
Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).

Не совсем понял, как таким образом можно избежать правок существующих программ.. :?:

_________________
ушёл...


Вернуться к началу
СообщениеДобавлено: Вс окт 24, 2010 3:43 pm 
Тех которые резервируют менее 1 Кб не получится не править. Впрочем большинство программ используют выделенный буфер в 1 Кб - ибо большинство программистов все-же читают документацию, так как научены горьки опытом.


Вернуться к началу
   
СообщениеДобавлено: Вс окт 24, 2010 7:25 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Mario

art_zh замечательно ответил за меня. Я знаю что это тянется от Менуэт, но сваливать всё только на "темное царское прошлое" неправильно. Было достаточно времени на наведение порядка в данных ядра.

P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?


Вернуться к началу
СообщениеДобавлено: Вс окт 24, 2010 7:49 pm 
Serge писал(а):
Было достаточно времени на наведение порядка в данных ядра.

Я бы ответил встречным вопросом - "так чего же сам не навел порядок?", но будет это по аналогии "драк - сам дурак". Надо учитывать что каждый занимается тем чем умеет и главное тем что ему самому нравиться - "Just for fun". Тыкать пальцем во всех и каждого бессмысленно.
Serge писал(а):
P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?

Вообще-то ты скромно умалчиваешь сколько лет назад это было (мы ведь не рождаемся многомудрыми?), а также не менее скромно что я уже два года как минимум ядром не занимаюсь. Я конечно понимаю чужие недоработки видней - со стороны оно всегда видней. :lol:

И никого не трогает, что когда это делалось менеджер памяти был еще совсем "не торт", он конечно и сейчас не особо "торт" - скорее пирожок или эклер. :mrgreen:

Но может не будем сейчас заниматься выискиванием насекомых в головах и мозгах друг-друга?

Я стараюсь придерживаться одного принципа: Можешь сделать лучше другого - делай, а не сокрушайся как все плохо. Последнее контрпродуктивный подход.


Вернуться к началу
   
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 35 сообщений ]  На страницу 1 2 3 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB