Колибри для встроенных систем?
-
Насчет табов еще когда-то Халявин (основатель свн-репозитория колибри) писал, что это зло и предлагал все делать пробелами, но потом как-то подзабили на это дело, да и стиль написания кода у каждого свой и порой очень разный. Наводить порядок и приводить все к единому виду с написанием рекомендаций как-то некому - одним лень, другие против этого, у третьих нет времени... как-то так вроде.
не, ну это понятно, что строем все ходить не будут
но, по-крайней мере, сказать, что "предпочтительней именно так-то" - неплохо было бы
В общем, выкладываю commit - смотрите на стилистику. А переделать - мне и не лень
Наверняка ошибки-то не все выкосил...
2serge: извини, stdcall не получается как-то... взгляни на коды - ну криво он там сидеть будет
но, по-крайней мере, сказать, что "предпочтительней именно так-то" - неплохо было бы
В общем, выкладываю commit - смотрите на стилистику. А переделать - мне и не лень
Наверняка ошибки-то не все выкосил...
2serge: извини, stdcall не получается как-то... взгляни на коды - ну криво он там сидеть будет
Да кстати этот пост тоже нах!
Last edited by Mario on Tue Apr 07, 2009 4:45 pm, edited 2 times in total.
Основные мотивы: разборки с целью понимания происходящяго
Попутно: оптимизация кодов по принципу: "если нет разницы, то зачем платить больше" (ну, собственно, и снял около 1К из 2-2.5)
Естественно, проводилось устранение мелких и не значительных багов (например: "32-битное переполнение" на таймауте ожиданий, и при определении момента для "next_usage_update")
Поскольку, возникли проблемы с "правильным ожиданием" event-ов, пришлось попутно "изобрести" эту технологию правильного ожидания
На что, кстати говоря, и призываю коллег обратить внимание: ф-я Wait_events_ex из event.inc предназначена (собственно, она для этого и задумана) для замены всех call change_task в цикле. Да хоть бы и в том же wait_mutex...
P.S. shed на предмет RT еще не правил. Это не сложно, НО, в моем понимании, для этого мне следует предварительно и серьезно разобраться с технологией прерываний и исключений.
Чем и занимаюсь...
P.P.S. Да вот, забыл... Изменения в checkidle не связаны логически с рефракторингом event.inc+shed.inc
Они возникли как бы мимоходом, и сделаны "с листа". И впервые были предложены здесь
P.P.P.S. Еще одна вещь...
Да, все это писалось по принципу: "если нет разницы, то зачем платить больше"
Т.е., если в коды и закралась бага, то ее устранение восстанавливает функциональную эквивалентность с предыдущими версиями, и проблем с совместимостью быть просто не должно
Кроме одного момента
Последовательность приема событий в f10 / f11 / f23 - изменена на обратную
Здесь, теоретически, возможны проблемы с совместимостью.
Мне такие вещи пока не попадались...
НО если у коллег возникнут непонятки с приемом событий в некой проге, то - от этого ли они возникли, можно легко проверить, вернув прямой порядок приема событий ((это достигается элементарной заменой bsr на bsf в event.inc#line=422))
И потом уже думать, чего делать дальше... Больно уж не правильным мне представляется "прямой порядок".
Опять же, события с "автосбросом" должны БЫ приниматься с более высоким приоритетом, чем требующие для этого сброса неких иных не тривиальных действий.
Для IRQ я это обязательно сделаю, но чуток по-позже... И нечто похожее на систему обрисуется: старшие биты маски - с автосбросом (они же и принимаются в первую очередь), младшие (которых сегодня 3) - нет, и требуют специальных мероприятий для сброса.
К этому моменту можно будет и sysfuncr.txt дополнить соответствующим образом...
Попутно: оптимизация кодов по принципу: "если нет разницы, то зачем платить больше" (ну, собственно, и снял около 1К из 2-2.5)
Естественно, проводилось устранение мелких и не значительных багов (например: "32-битное переполнение" на таймауте ожиданий, и при определении момента для "next_usage_update")
Поскольку, возникли проблемы с "правильным ожиданием" event-ов, пришлось попутно "изобрести" эту технологию правильного ожидания
На что, кстати говоря, и призываю коллег обратить внимание: ф-я Wait_events_ex из event.inc предназначена (собственно, она для этого и задумана) для замены всех call change_task в цикле. Да хоть бы и в том же wait_mutex...
P.S. shed на предмет RT еще не правил. Это не сложно, НО, в моем понимании, для этого мне следует предварительно и серьезно разобраться с технологией прерываний и исключений.
Чем и занимаюсь...
P.P.S. Да вот, забыл... Изменения в checkidle не связаны логически с рефракторингом event.inc+shed.inc
Они возникли как бы мимоходом, и сделаны "с листа". И впервые были предложены здесь
P.P.P.S. Еще одна вещь...
Да, все это писалось по принципу: "если нет разницы, то зачем платить больше"
Т.е., если в коды и закралась бага, то ее устранение восстанавливает функциональную эквивалентность с предыдущими версиями, и проблем с совместимостью быть просто не должно
Кроме одного момента
Последовательность приема событий в f10 / f11 / f23 - изменена на обратную
Здесь, теоретически, возможны проблемы с совместимостью.
Мне такие вещи пока не попадались...
НО если у коллег возникнут непонятки с приемом событий в некой проге, то - от этого ли они возникли, можно легко проверить, вернув прямой порядок приема событий ((это достигается элементарной заменой bsr на bsf в event.inc#line=422))
И потом уже думать, чего делать дальше... Больно уж не правильным мне представляется "прямой порядок".
Опять же, события с "автосбросом" должны БЫ приниматься с более высоким приоритетом, чем требующие для этого сброса неких иных не тривиальных действий.
Для IRQ я это обязательно сделаю, но чуток по-позже... И нечто похожее на систему обрисуется: старшие биты маски - с автосбросом (они же и принимаются в первую очередь), младшие (которых сегодня 3) - нет, и требуют специальных мероприятий для сброса.
К этому моменту можно будет и sysfuncr.txt дополнить соответствующим образом...
Народ, выручайте...
Не понимаю
А тестовый пример для проверки правильности показаний show_error_parameters при debug_exception и отсутствии самого отладчика - как-то сразу в голову и не приходит...
Вот: debug.inc#line=438
Мне здесь, главное - знать степень своей тупости.
Если же я таки прав, и это просто бага, то вопрос - снят. Сам поправлю...
Все одно, это дело надо объединять с совершенно аналогичным в sys32.inc
Не понимаю
А тестовый пример для проверки правильности показаний show_error_parameters при debug_exception и отсутствии самого отладчика - как-то сразу в голову и не приходит...
Вот: debug.inc#line=438
Code: Select all
; not debuggee => say error and terminate
add esp, 0x20+4 ; <----- ??????
mov [error_interrupt], 1
call show_error_parameters
Если же я таки прав, и это просто бага, то вопрос - снят. Сам поправлю...
Все одно, это дело надо объединять с совершенно аналогичным в sys32.inc
Нах этот пост!
Last edited by Mario on Tue Apr 07, 2009 4:42 pm, edited 1 time in total.
Четверка не напрягает, она понятна: есть pushd - есть 4-ка, нет (что легко достижимо) - нету и 4-ки
Напрягает именно 20-ка (в смысле 32), и именно в сравнениии с sys32.inc
Пока подозреваю, что это бага, на которую в здравом уме наступить крайне затруднительно....
Напрягает именно 20-ка (в смысле 32), и именно в сравнениии с sys32.inc
Пока подозреваю, что это бага, на которую в здравом уме наступить крайне затруднительно....
И этот нах!
Last edited by Mario on Tue Apr 07, 2009 4:43 pm, edited 1 time in total.
А этот сам Бог велел нах!
Last edited by Mario on Tue Apr 07, 2009 4:43 pm, edited 1 time in total.
Вьюноша, позволю себе открыть Вам великую тайну.
Ошибки, это постоянное состояние разработчика. Просто потому, что не ошибается тот, кто ничего не делает
И профессионалом становится вовсе не тот, кто не делает ошибок, а тот кто умеет их исправлять, и не делает их в количестве, превышаюшем некоторую критическую массу, после которой приходится переделывать все заново
Ну а уж если указания, даже предположительные, на ошибку, коллега воспринимает как личное оскорбление, то медицина тут бессильна.
Он никогда не будет профессиналом ((здесь должен быть смайлик выражающий Великое Презрение))
Собственно, без "помощи", выражающейся в копировании с кодов тел одно-двух строчных макросов - можно и обойтись.
Помощь - это свежая идея, указание на ошибку наконец.
То, что приводит к улучшению (в данном случае - кодов)
Ну например...
Сейчас два хука исключений вынесены в одно понятное и, как мне кажется, правильное место.
Можно было бы обсудить расширения этих хуков на другие типы исключений - 0, 3, 4, 5...
И как это сделать, чтобы не иметь проблем с совместимостью...
Вот это была бы помощь
А вовсе не вещание с броневичка прописных истин с видом Великого Гуру
Ошибки, это постоянное состояние разработчика. Просто потому, что не ошибается тот, кто ничего не делает
И профессионалом становится вовсе не тот, кто не делает ошибок, а тот кто умеет их исправлять, и не делает их в количестве, превышаюшем некоторую критическую массу, после которой приходится переделывать все заново
Ну а уж если указания, даже предположительные, на ошибку, коллега воспринимает как личное оскорбление, то медицина тут бессильна.
Он никогда не будет профессиналом ((здесь должен быть смайлик выражающий Великое Презрение))
Собственно, без "помощи", выражающейся в копировании с кодов тел одно-двух строчных макросов - можно и обойтись.
Помощь - это свежая идея, указание на ошибку наконец.
То, что приводит к улучшению (в данном случае - кодов)
Ну например...
Сейчас два хука исключений вынесены в одно понятное и, как мне кажется, правильное место.
Можно было бы обсудить расширения этих хуков на другие типы исключений - 0, 3, 4, 5...
И как это сделать, чтобы не иметь проблем с совместимостью...
Вот это была бы помощь
А вовсе не вещание с броневичка прописных истин с видом Великого Гуру
Начиная с #1055 перестал работать звук в Doom. Жалуется на event code = 0 a должно быть 0xFF000001. И событие сигнализируется только один раз.
serge, поподробнее пожалуйста
event code, это EVENT.code, или что-то другое
Если это, то зона узкая, будем внимательно сравнивать кода на предмет эквивалентности......
И еще, я пока вообще плохо себе представляю как работет dosbox (речь о нем ???), средства v86 вроде никуда и не экспортируется....
А в v86 тоже есть одна заморочка, связанная с вызовом do_change_task... Типа было не правильно, осталось не правильно (но чуток по-другому), да и вообще, само использование do_change_task кем ни попадя - уже само по себе не правильно...
serge, расскажите все что знаете, что-бы хоть определиться с направлением раскопок
event code, это EVENT.code, или что-то другое
Если это, то зона узкая, будем внимательно сравнивать кода на предмет эквивалентности......
И еще, я пока вообще плохо себе представляю как работет dosbox (речь о нем ???), средства v86 вроде никуда и не экспортируется....
А в v86 тоже есть одна заморочка, связанная с вызовом do_change_task... Типа было не правильно, осталось не правильно (но чуток по-другому), да и вообще, само использование do_change_task кем ни попадя - уже само по себе не правильно...
serge, расскажите все что знаете, что-бы хоть определиться с направлением раскопок
Я про портированный Дум. Исходники на свн а на фтп готовый exe-шник. Тестить удобно в VirualBox с драйвером sb16.
Это код
Это код
Code: Select all
typedef struct
{
unsigned int code;
unsigned int sender;
unsigned int stream;
unsigned int offset;
unsigned int size;
unsigned int unused;
}SND_EVENT;
SND_EVENT evnt;
GetNotify(&evnt); // 68.14
if(evnt.code != 0xFF000001)
{
printf("invalid event code %d\n\r", evnt.code);
continue;
}
if(evnt.stream != hBuff)
{
printf("invalid stream %x hBuff= %x\n\r",
evnt.stream, hBuff);
continue;
};
serge, ты меня совсем запутал
Ей богу, я никогда не играл в Doom (ну случилась такая беда), и даже не знаю ДОС-вская это фича, или виндячая.
Чисто для интереса - что такое портированный, кем портированный....
Далее, ищу, что же такое sb16
Нахожу у тебя, в Kolibri_pe
Обнаруживаю, что экспортные имена ядра "немного другие"
А ведь я, честно-благородно, поискал в репозитории использование имен create_event, raise_event, wait_event, destroy_event, clear_event, send_event - и не найдя, успокоился.
И воспользовался твоим советом про "второе счастье", меняя интерфейс под себя.
Ну типа подумал, что это дело For Further Features
Пытаюсь искать "правильные" имена в твоей папке Driver
В sb16.asm - не нахожу, но нахожу в infinity.asm, и mixer.asm
Ну да, интерфейсы для CreateEvent и RaiseEvent - не состыкованы
Ощущение такое, что CreateEvent и со старым (до меня) не очень стыкуется...
Дальше, я не очень понимаю, как это дело с интерферировало с "штатными кодами".
Тут я упустил какой-то момент. Колелги, растолкуйте мне этот механизм, пожалуйста...
Да, и еще один момент... Я же увеличил длину поля code.
Может это неправильно
serge, ведь в приведенном Вами коде уже возможен криминал (запись ЗА пределы SND_EVENT)
Ну давайте подумаем, как надо делать правильно....
А пофиксить под договоренность - минутное дело
Ей богу, я никогда не играл в Doom (ну случилась такая беда), и даже не знаю ДОС-вская это фича, или виндячая.
Чисто для интереса - что такое портированный, кем портированный....
Далее, ищу, что же такое sb16
Нахожу у тебя, в Kolibri_pe
Обнаруживаю, что экспортные имена ядра "немного другие"
А ведь я, честно-благородно, поискал в репозитории использование имен create_event, raise_event, wait_event, destroy_event, clear_event, send_event - и не найдя, успокоился.
И воспользовался твоим советом про "второе счастье", меняя интерфейс под себя.
Ну типа подумал, что это дело For Further Features
Пытаюсь искать "правильные" имена в твоей папке Driver
В sb16.asm - не нахожу, но нахожу в infinity.asm, и mixer.asm
Ну да, интерфейсы для CreateEvent и RaiseEvent - не состыкованы
Ощущение такое, что CreateEvent и со старым (до меня) не очень стыкуется...
Дальше, я не очень понимаю, как это дело с интерферировало с "штатными кодами".
Тут я упустил какой-то момент. Колелги, растолкуйте мне этот механизм, пожалуйста...
Да, и еще один момент... Я же увеличил длину поля code.
Может это неправильно
serge, ведь в приведенном Вами коде уже возможен криминал (запись ЗА пределы SND_EVENT)
Ну давайте подумаем, как надо делать правильно....
А пофиксить под договоренность - минутное дело
Все, доехало... Во балбесGalkov wrote:Дальше, я не очень понимаю, как это дело с интерферировало с "штатными кодами"
Плохой моя охотник, однако
Who is online
Users browsing this forum: Google [Bot] and 21 guests