Board.KolibriOS.org

Да, вот еще. Позволил я себе перетащить несколько "исключений" из под макроса exc_wo_code в exc_w_code
Если помните, и в букварях опечатки бывают, проверьте, коллеги
Тут лучше бы обойтись без шуток и неожиданностей
У меня Гук+Юров, бумажное издание (в таких, на удивление - опечаток меньше)
Естественно, я проверил внутреннюю непротиворечивость: стоят не только "галочки" в таблице, но и словами, русским языком, написано - "При обработке исключений 8-14, 17 и 18 в защищенном режиме процессор сохраняет в стеке слово кода ошибки EC (Error Code)"

Я совсем не против рефакторинга. Если код не используется лучше его удалить или явно закомментировать, а не прятать в макрос у которого совсем другая смысловая нагрузка. Для этого есть if 0 ... end if

Да без проблем.

Кстати, if 0 заметить тоже не просто - я уже накалывался
И думал, между прочим, что это все естественно и понятно
Пример: programs\develop\libraries\libs-dev\.test\dll.inc
Делаю я этот include, но у меня всего одна либа в проекте. Грубо говоря - dll.Load я не использую.
Так она и не будет включена в мои коды.
Написано не мной, ну я и считал это давно понятным и естественным

Не знаю точно как в gcc, кажется там все, что написано в файле - будет тупо включено в коды...
А вот в Дельфях, к примеру - ТОЛЬКО используемое. У них это правда называется smart-linkig, и жутко этим гордятся.
Афигенный smart, конечно же... Доросли до возможностей встроенных макросов fasm-а

Кстати, if 0 заметить тоже не просто - я уже накалывался

Поэтому чаще всего код просто комментируют
;
;
;
;

Serge wrote:Исключения POSIX подробно описаны в gnu libc manual

http://www.gnu.org/software/libc/manual/pdf/libc.pdf - раздел 24 (Signal Handling)
Правильно попал

Ещё стоит посмотреть описание posix.1b posix.1c - стандарты для rtos.

Блин, ну очень не хотел... Но, видимо -- не отвертишься
Ну ладно, закачал я это добро отсюда http://www.opengroup.org/onlinepubs/000 ... /susv3.zip
Вот только понять не могу, чего из них 1b, а чего 1c
там примерно такой выбор в менюхе слева
Batch Services
Development
Headers
Legacy Interfaces
Math Interfaces
Networking
Realtime
Threads

И плюс такое - Select a volume: [ XBD | XCU | XSH | XRAT ]
Что примерно расшифровывается как: [Base Definitions|Shell & Utilities|System Interfaces|Rationale]

Serge, направьте на путь истинный... А то, с моим-то английским, это все год читать можно...

В общем, поизучал я немного систему сигнализации в posix и libc
Дошел до перехода из ощущения, что "знаешь почти все" - в понимание, что процесс познания в данной области видимого конца не имеет.
Пора принимать какое-то решение, и заканчивать дело конкретными кодами.

Что я вижу в programs\develop\open watcom\trunk\clib\process\signl.c (имя файла - понравилось)
Что из сигналов, порождаемых исключениями: SIGFPE, SIGILL, SIGSEGV - поддерживается только SIGFPE. Надо полагать, что к таковым же относятся SIGIOVFL и SIGIDIVZ, но таких определений я не нашел ни в стандарте libc, ни в posix.
Вопрос - почему не поддерживатся. Ответ - потому-что таковых возможностей не предоставляет ось.
Далее, про SIGFPE буквари рассказывают такое: The SIGFPE signal reports a fatal arithmetic error. Although the name is derived from “floating-point exception”, this signal actually covers all arithmetic errors, including division by zero and overflow
Вопрос - почему сделано не так. Ответ - прежний.

Далее, вопросы в порядке приоритетов

1) Надо ли делать, чтобы ось такие вещи все-таки поддерживала? Если - "не очень-то и хотелось", то дальнейшее обсуждение бессмысленно. Поэтому исхожу в дальнейшем из - "надо, и обязательно"

2) Надо ли сохранять при этом совместимось с нашими хуками исключений по FPU и SSE?
Если сохранять, то все таковые сигналы мы должны обслужить адресами соответствующих обработчиков в APPDATA. Грубо говоря - на каждое исключение.
И есть у меня ощущение, что это не очень рациональная трата ресурсов. Место в структуре закончится очень быстро.

3) Если не сохранять, то надо выкинуть поля APPDATA.fpu_handler/sse_handler и заменить их на адрес единого для всех хэндлера и dword маски на все допустимые исключения проца. Интерфейс хэндлера при этом меняется - в стеке идет номер исключения, который надо снимать по выходе из хэндлера (зачем выходить - тоже интересный вопрос).
Сопровождение. Гляжу в коды fpe387.asm::__Init_FPE_handler и fpeinth.asm::__FPE2Handler_ - вполне подъемная задача.
Естественно, я оставлю старую функциональность - реагирование только на FPE
Но, у С-developer-ов появится возможность реагировать (созданием соответствующих сигналов) на любые события из вышеперечисленных.
Ну а KoOS - это просто пара десятков байтов кодов в sys32.inc, делов на вечер.

=================================================================
Крутилась у меня интересная мысль - полностью обратиться в веру сигналов/событий
Долго крутилась...
Т.е., к сигналам относятся как наши хуки исключений, так и ожидаемые нами события как "от драйвера", так и по f10/23.
Грубо говоря - ничего в мире не существует кроме сигналов.
Типа последние - это просто заблокированные сигналы, которые, в отличие от исключений, пользователь принимает чем-то похожим на sigwait. А исключения - это такие сигналы, которые блокировать глупо, мягко говоря.
А вот иметь дополнительную возможность "захендлить" IRQ-сигналы - вовсе и не глупо...
Да и "захэндленное" рисование - тоже можно обсуждать...

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

Про обратную совместимость с текущим обработчиком исключений ftp/sse думаю "не очень-то и надо".
Если делать сигналы, то пусть все будет там, хоть и IRQ (может мы таки прийдем к микроядру?).
В общем если есть желание, думаю стоит занятся, а люди готовые помочь / пообсуждать думаю есть, как и интерес.

/может перейдем на AMD64 ? т.к. сейчас выпускают процессоры с поддержкой AMD64/EMT64./
PS мои познания в особенностях этих режимов скудны.

А давайте и на асм забъем? Все равно ведь ядро уже почти одни сплошные макросы... ну, его к черту этот муторный ассемблер. Вот понимаешь все пишут на Си, все пишут используя L4, и ваапще зачем оно ведь уже есть Линупс в котором есть все, даже то что нужно. А может вообще сразу на Яве ваять? И вообще просить у Гугла исходники Андройда? Ну, епть ну зачем нам это гребанй асм? А?!

Не млин, давай те лучше оставим сталые костыли, и ещё придумаем новые???

О чем это ВЫ: /может перейдем на AMD64 ? т.к. сейчас выпускают процессоры с поддержкой AMD64/EMT64./
Мои познания в этих технологиях еще более скудны. Поэтому не понял как связи с "обработкой исключений", так и смысла последовавших ответов.

Расшифруйте, пожалуйста.

<Lrz> "— Обязательно бахнем! И не раз — весь мир в труху!.. Но потом."... ДМБ
Galkov не обращай внимания

Вот чего я думаю.
Для большинства прикладных программистов, все это словеса умные и непонятные....
Наверное.

Может где-то как-то выложить простенький пример.
Типа 2 основых ф-ии: Хотя бы простейший однопроходный вариант, объемом так строк на 20 asm-а

Простенькая вещь в стиле Forth: __TRY запускает func в режиме перехвата исключений
Если вернулся 0 - все было тип-топ. Иначе - номер исключения. Если это "не твое" -- делай __RISE, и не напрягайся. Получится вложенная сруктура.