abivan (03.12.2020 10:31, просмотров: 477) ответил Dingo на Появился зуд, хочу попробовать написать что-нибудь вытесняющее,
дабы лучше понять как работают OS. В связи с чем вопросы к донам и
дуэньям.-
- Эти смотрели? CoOS и прототреды Дункелса. Dingo(519 знак., 04.12.2020 19:34, ссылка, ссылка)
- Полно их - Ruslan(06.12.2020 21:02, ссылка)
- Очевидно, что без механизма ожидания -- получается полная ерунда, которая ничем не лучше биглупа. Когда
событий станет много (типов событий, происходить им не обязательно)
-- всё время только и будет уходить на такие циклы проверки, как и
в биглупе. Зачем тогда сущность с громким названием "операционка"? fk0(7411 знак., 06.12.2020 14:41, ссылка, ссылка)
- Если вы про мой планировщик, то это скорее способ организации исходного текста (потому и sheduler), нежели претензия на кооперативную ОС. Dingo(1342 знак., 06.12.2020 21:29, ссылка, ссылка)
- Заглянул в причесанное Vit(149 знак., 06.12.2020 10:00)
- а напомните пожалуйста порядок вычисления аргументов для функции Zoro(58 знак., 06.12.2020 17:35)
- ЕМНИП, порядок любой. По чётным дням один, по нечётным другой. - SciFi(06.12.2020 17:41)
- Для конструкторов при этом -- строго слева-направо. - fk0(06.12.2020 18:46)
- ЕМНИП, порядок любой. По чётным дням один, по нечётным другой. - SciFi(06.12.2020 17:41)
- Во-первых p_tsk = &tasks[++i]. Во-вторых надоели идиоты:
оператор "запятая" ничем не плох, даже хорош по сравнению с
вариантами вроде ++*i-- так как порядок очевиден -- слева направо.
Оператор "запятая" от "точки с запятой" отличается только временем
жизни временных переменных (до "точки с запятой") и возможностью
использования в контексте выражения (а не оператора). В языке C
полезные применения: как раз избавление от ++*i--, возможность
записать последовательность fk0(247 знак., 06.12.2020 14:33)
- От идиота слышу. Твоё "во-первых" при выполняемой перед этим
проверке if ( i>=TAB_SZ ) break; вызывает обращение за границу
массива и это нужно вылечить, а не тут говном исходить. По логике
действительно нужен преинкремент. По тексту правильнее инкремент
делать до проверки на маскимальный индекс, а присваивание указателя
после. Работа с задачами не из списка, а из массива, в этой
интерпретации делается пробежкой по всему массиву, до первой
"задачи-пустышки". Обычно это Vit(601 знак., 06.12.2020 15:16)
- Спасибо за найденную ошибку. Начинал как вариант со списками,
сейчас склоняюсь к мысли вообще выкинуть этот изврат, ибо там, где
уместно применить "это-вот-всё", там списки лишние. Тогда будет
возможность дёргать задачу по номеру (из прерываний удобней,
например), а не по функции. - Dingo(06.12.2020 18:33)
- Считаю списки более удобным решением. Как минимум для отладки.
Невключение модуля - просто коммент строки, а не застирывание
массива, правка каких-то конфигов... Vit(936 знак., 06.12.2020 19:37)
- Если в реализации на списках из прерывания что-то делать, то мы
пошли обходить список, а с таблицей - номер N, обработай!( в свой
приоритет). Dingo(174 знак., 06.12.2020 20:35)
- Насчет "из прерывания что-то делать" - если говорим о добавлении задачи в список, то если не бояться дидлоков, для собственно быстрой операции добавления хранится указатель на хвост. Насчет дидлоков тоже можно решать быстрее, чем пробежать по списку, но это отдельный вопрос. Насчет соотношения приоритетов не понял. Наверно речь об идее с вытеснением. - Vit(06.12.2020 22:08)
- Списки хотят выделения/освобождения памяти, Dingo(959 знак., 06.12.2020 20:29)
- Что-то намешалось Vit(1765 знак., 06.12.2020 21:51, ссылка)
- Блин, не отпускает... Я ещё и о существовании XMACRO вспомнил. Dingo(1155 знак., 10.12.2020 08:31)
- ХЗ. Но в TASKLIST не видно запятых. Дальше не смотрел - Vit(10.12.2020 09:38)
- Вы правы, списки можно хранить и в таблице, например. Dingo(704 знак., 07.12.2020 07:59)
- Блин, не отпускает... Я ещё и о существовании XMACRO вспомнил. Dingo(1155 знак., 10.12.2020 08:31)
- Что-то намешалось Vit(1765 знак., 06.12.2020 21:51, ссылка)
- Если в реализации на списках из прерывания что-то делать, то мы
пошли обходить список, а с таблицей - номер N, обработай!( в свой
приоритет). Dingo(174 знак., 06.12.2020 20:35)
- Считаю списки более удобным решением. Как минимум для отладки.
Невключение модуля - просто коммент строки, а не застирывание
массива, правка каких-то конфигов... Vit(936 знак., 06.12.2020 19:37)
- Вот я и говорю про идиотов, ы которых набор каких-то догматических правил, мол "оператор запятая использовать нельзя" ("goto использовать нельзя") и т.п. Обосновывать свои догматы, конечно, они не могут, нечем. Мы о профессиональном программировании или о кружке пионеров? - fk0(06.12.2020 16:01)
- Приоритет во всех языках примерно одинаковый. Козырять несклерозом
не надо, но основные приоритеты знать надо. Иначе из-за количества
скобок код будет нечитаемый глазами. Надо знать про то, что
операторы взятия адреса и дереференса указателя выше по приоритету
арифметики (а ++ и -- ещё выше), и что логические операторы ниже
арифметики, и ниже оператора сравнения (который ниже арифметики). И
оператор присваивания -- ниже всех (кроме запятой). А тернарный
оператор выше fk0(66 знак., 06.12.2020 15:57)
- Представь, что знать-то знаю, а вот доверять не могу:) - Vit(06.12.2020 16:03)
- Спасибо за найденную ошибку. Начинал как вариант со списками,
сейчас склоняюсь к мысли вообще выкинуть этот изврат, ибо там, где
уместно применить "это-вот-всё", там списки лишние. Тогда будет
возможность дёргать задачу по номеру (из прерываний удобней,
например), а не по функции. - Dingo(06.12.2020 18:33)
- От идиота слышу. Твоё "во-первых" при выполняемой перед этим
проверке if ( i>=TAB_SZ ) break; вызывает обращение за границу
массива и это нужно вылечить, а не тут говном исходить. По логике
действительно нужен преинкремент. По тексту правильнее инкремент
делать до проверки на маскимальный индекс, а присваивание указателя
после. Работа с задачами не из списка, а из массива, в этой
интерпретации делается пробежкой по всему массиву, до первой
"задачи-пустышки". Обычно это Vit(601 знак., 06.12.2020 15:16)
- а напомните пожалуйста порядок вычисления аргументов для функции Zoro(58 знак., 06.12.2020 17:35)
- Кому нужна? С компилятором такого качества уже никакая ОС не нужна,
на мой взгляд. Да и вообще компилируемый стек и ОС --
малосовместимые понятия: как спрашивается в двух задачах исполнять
один и тот же код? (вытесняющая ОС или кооперативная не важно) Это
будет недоос с массой идиотских ограничений. Такая на мой взгляд не
нужна. Программируй автоматы. - fk0(03.12.2020 13:05)
- автоматы ну их нахер. У меня проект на осе на пик 18 прекрасно
работает с HT-PICC std abivan(345 знак., 03.12.2020 17:24)
- См. ниже. Суть не в том, что "для меня блаблбла..." что переводится
как "мне нравится...", а в том, что компилятор накладывает
СУЩЕСТВЕННЫЕ И ПРИНЦИПИАЛЬНЫЕ ОГРАНИЧЕНИЯ НА АРХИТЕКТУРУ ПО,
настолько серьёзные, что практически не может идти и речи о том,
чтобы переключить задачу в какой-то какой попало функции. Только
биглуп. Где у каждой задачи своя функция и она может переключать
задачи, в ней цикл. А всё что вызывается ничего уже переключать не
может. Без вариантов. Ты fk0(170 знак., 03.12.2020 17:32)
- да как хочешь назови хоть 10 задач, хоть 10 биглупов. Мы все понимаем о чем речь Приоритеты задач есть, сервисы имеются (задержки очереди таймеры). Код в приделах задачи линейный, поддерживать легко. Задачи временные создаются и удаляются. Мне не требуется вытеснение. "ОСИ" для новых пик16 и pic18Q нет поэтому я не рассматриваю их применение в моей реальности. - abivan(03.12.2020 17:51)
- См. ниже. Суть не в том, что "для меня блаблбла..." что переводится
как "мне нравится...", а в том, что компилятор накладывает
СУЩЕСТВЕННЫЕ И ПРИНЦИПИАЛЬНЫЕ ОГРАНИЧЕНИЯ НА АРХИТЕКТУРУ ПО,
настолько серьёзные, что практически не может идти и речи о том,
чтобы переключить задачу в какой-то какой попало функции. Только
биглуп. Где у каждой задачи своя функция и она может переключать
задачи, в ней цикл. А всё что вызывается ничего уже переключать не
может. Без вариантов. Ты fk0(170 знак., 03.12.2020 17:32)
- а в чём проблема исполнения одного кода в двух задачах? - Mahagam(03.12.2020 13:57)
- В компилированном стеке. Когда каждая переменная каждой функции по
сути -- static. - fk0(03.12.2020 14:05)
- а, это из-за особенностей архитектуры? - Mahagam(03.12.2020 14:14)
- Для PIC18 и i8051 -- да. Можно было бы их пытаться обойти, но
эффективность кода была бы очень низкая, а объём кода -- огромный. - fk0(03.12.2020 14:27)
- Ну для 8051 есть микроос от кейла. Вроде не сильно тяжелая. - LightElf(03.12.2020 15:16)
- Ты не можешь заблокироваться в функции, передать управление другому
потоку и вызвать эту же функцию. Т.е. деревья вызовов разных задач
должны быть полностью непересекающимися. Т.е. библиотечных функций
не должно быть по сути. Это нормальное программирование? И здесь
нужна теперь операционка? Чем это лучше автоматов? (хуже). - fk0(03.12.2020 17:28)
- 1) совсем не все библиотечные функции Кейла требуют стека. LightElf(199 знак., 04.12.2020 14:41)
- Ты не можешь заблокироваться в функции, передать управление другому
потоку и вызвать эту же функцию. Т.е. деревья вызовов разных задач
должны быть полностью непересекающимися. Т.е. библиотечных функций
не должно быть по сути. Это нормальное программирование? И здесь
нужна теперь операционка? Чем это лучше автоматов? (хуже). - fk0(03.12.2020 17:28)
- Ну для 8051 есть микроос от кейла. Вроде не сильно тяжелая. - LightElf(03.12.2020 15:16)
- Для PIC18 и i8051 -- да. Можно было бы их пытаться обойти, но
эффективность кода была бы очень низкая, а объём кода -- огромный. - fk0(03.12.2020 14:27)
- а, это из-за особенностей архитектуры? - Mahagam(03.12.2020 14:14)
- В компилированном стеке. Когда каждая переменная каждой функции по
сути -- static. - fk0(03.12.2020 14:05)
- автоматы ну их нахер. У меня проект на осе на пик 18 прекрасно
работает с HT-PICC std abivan(345 знак., 03.12.2020 17:24)
- Зачем в микроконтролллерной кооперативке ассемблерный код?... Я в
вытесняющей его избегать стараюсь. - Dingo(03.12.2020 11:53)
- Для функций сохранения и восстановления контекста в основном. В принципе можно использовать setjmp/longjmp но у многих эти функции либо вовсе не работают, либо сделаны абы как. Может потребоваться их переписать. Кроме того, структура jmp_buf не прозрачна и непонятно как запустить новую задачу. Можно через alloca() конечно... Но если C++ и исключения, то возникают проблемы с размоткой стека. Нужно нормально инициализировать стек, без трюков. - fk0(03.12.2020 13:14)
- Спасибо, посмотрю при случае. Но пока это интересней ковырять. - Dingo(03.12.2020 10:42)
- Эти смотрели? CoOS и прототреды Дункелса. Dingo(519 знак., 04.12.2020 19:34, ссылка, ссылка)