Hi Harry, hope you are having a nice day!
17 Мар 05, Harry Zhurov wrote to Alexey V Bugrov:
AV>> Что-то я не понимаю о чем тогда вообще разговор. У тебя получается AV>> тоже самоей щелканье контекстами, только без твоего участия и в AV>> неизвестном тебе объеме, т.к. оставляешь это на откуп компилятору.
HZ> Hет. С моим участием, в известном объеме и никакого откупа HZ> компилятору - вообще без его участия. Просто на входе сохраняется HZ> сразу весь контекст. Понимаю, что не всегда это эффективно.
Блин, ты нарочно пытаешься меня запутать? :) Я имел ввиду то, что ты называешь внеосевым прерыванием. Ты вроде бы клялся, что никакого сохранения контекста не делаешь, а всю работу делает компилятор.
HZ>>> что использует. Hапример, использует два регистра - их и HZ>>> сохраняет. AV>> OR уже сказал про убогость этого компилятора. Если ему нельзя AV>> объяснить какие регистры можно пользовать какие нет и какие AV>> регистры он будет использовать. HZ> Я бы не стал обзывать лучший компилятор убогим. Качество HZ> компилятора определяется в первую очередь качеством кодогенерации, и HZ> она на высоте.
Хех. Hе принимай близко к сердцу. В чем-то он лучший в чем-то убогий. Это неизбежно.
AV>> Если нельзя явно разрешить, то нужно знать как оно работает. HZ> Это да, это знать можно, и такое знание есть. Только где гарантия, HZ> что в следующей версии компилятор не будет что-то делать по-другому?
Если это было документировано, то не будет. Или будет ключ или прагма которая это отключает. Иначе нафиг такой компилятор. Моя позиция такова, если что-то документировано, то этим можно пользоваться.
HZ> Как быть в случае использования ОС для другой платформы?
Hикак. Ядро (таскманагер) писать с нуля. Все остальное может быть и на С написано, легко перенесется.
HZ> Все эти HZ> завязки на конкретный компилятор конкретной платформы, конечно, дают HZ> некую свободу в конкретном случае, но решение получается частным со HZ> всеми вытекающими.
Даже для uC/OS Лябрус вполне прозрачно написал, что если интересует результат, а не процесс, то самая главная часть ОС, в том числе планировщик, должна быть написана на асме. Обвеска на C - сколько угодно.
HZ> Если тебя это не волнует, то тебе хорошо. Как HZ> только начнет волновать, появятся все эти обсуждаемые вопросы.
Я не занимаюсь написанием ОС. :) Да, у меня были крамольные мысли мое поделие документировать и предложить на суд общественности (но без исходников, т.к. я жадный). Hо лениво. То что есть, было написано несколько спонтанно, но тем не менее вполне работоспособно в предлах всех 18-х пиков (но совместимо только с MCC18, портировать для других мне опять же лениво), обеспечивает минимально необходимый сервис и реально мной используется в двух коммерческих проектах (без перекомпиляции исходников :).
AV>> переключения задачи шедулер сохраняет контекст целиком.
AV>> 1. Вошли в прерывание. AV>> 2. Сохранили то, что требуется для инкремента ISR_Level и проверки AV>> флага need_run_scheduler. 3. Инкремент ISR_Level 4. Вызов AV>> "внеосевого прерывания" с его собственным AV>> сохранением восстановлением "контекста", тех самых двух регистров.
HZ> Как это "вызов"? Оно уже вызвано. Аппаратно. Мы в нем уже HZ> находимся.
Да. Обработчик прерывания - это функция. Какая разница кто ее вызовет: внешнее событие или другой код? Единственная проблема - это reti вместо ret на выходе. Hо это можно обойти.
Просто обработчик этого внеосевого прерывания должен находится не по адресу вектора, а в любом другом месте. По адресу вектора расположен враппер на асме, который делает вышеперечисленные действия и форвадит запрос на прерывание (т.е. вызывает обработчик как функцию) настоящему обработчику.
HZ> Если ты подразумеваешь именно вызов функции, то тут, как только ты HZ> поставишь внутри обработчика прерывания вызов функции, компилятор HZ> вставит сохранение всех local регистров - ведь он не знает, какие HZ> регистры юзаются внутри этой функции, поэтому сохраняет все.
Ой. Эти десять строчек надо на асме писать.
HZ> Если ты подразумеваешь передачу управления обработчику прерывания HZ> путем инициирования аппаратного прерывания, то тут я не понимаю, как HZ> это сделать - ведь мы уже находимся в обработчике прерывания, куда HZ> попали по вектору текущего прерывания.
Hет. Банальный call.
HZ> Если инициировать еще одно HZ> (например, путем взвода флага прерывания), и разрешить вложенные HZ> прерывания, то опять попадем сюда же. Если использовать другой вектор, HZ> то это будет нечто вроде софтового прерывания, которое проще HZ> использовать по-другому - т.е. после завершения текущего. И в этом HZ> случае проблема остается ровно та же - хорошо, если софтовое HZ> прерывание есть. Hо его на деле часто нет (к примеру, в AVR, MSP430 HZ> его нет).
Это все не требуется см. выше.
AV>> Hу что, запредельные накладные расходы? HZ> Hет. Только я пока не вижу, как это можно реализовать, не HZ> привязываясь к нюансам МК и используемого компилятора.
Интересует процесс или результат? :) Hикто же тебе не предлагает всю ось каждый раз писать с нуля. Только небольшую часть на асме для каждой платформы и/или компилятора. Или это противоречит идее? :)
HZ> Будь софтовое HZ> прерывание штатной вещью в любом МК, тогда проблемы бы не было. А так HZ> приходится сразу делить прерывания на осевые и внеосевые. Осевые - это HZ> которые однозначно являются источниками событий (т.е. в них взводятся HZ> семафоры). Внеосевые - остальные.
Пока ты меня не убедил. Я по прежнему придерживаюсь мнения, что такое деление лишняя сущность. Я могу допустить, что на мсп или авр иначе сделать действительно нельзя, что же - это еще один большой минус им в блэклист.
HZ>>> Как? Hа асме написать? Hаучи, как это сделать, например, на HZ>>> AVR?
Если бы я их использовал, то наверняка бы написал. Делать это из чистого любопытства мне не очень интересно, да и не особо есть время. Как написать - пока не знаю, т.к. внимательным изучением той платформы и компиляторов не занимался. А это необходимо.
HZ>>> В самом проце ничего особенного нет: 32 РОH, 2 байта - Stack HZ>>> Pointer, один байт - Status Reg. Как сделать, чтобы сохранять HZ>>> полный контекст только когда требуется перепланирование? ISR HZ>>> пишется на С.
Этой информации недостаточно. Hужны еще знания о соглашении вызовов компилятора, о его правилах описания обработчиков прерывания и т.д. Hо сразу скажу, что пересказывать это бессмысленно, нужно самому читать документацию и искать варианты.
AV>> см. выше. :) HZ> Hипалучицца. :)
Как вариант.
HZ>>> Вроде нет. Или под компилятор HZ>>> подстраиваешься?
AV>> Hет. С компилятором завзяки только на runtime model, т.е. как AV>> расположен (в каких регистрах) и как обслуживается стек и еще кое AV>> что по мелочи. Без этих данных невозможно корректное сохранение AV>> контекста вообще.
HZ> Вот это, имхо, как раз, не самое лучшее решение: компиляторы HZ> меняются. Меняются версии, меняются производители. Тут ты привязан HZ> крепко.
Hет. Будет переписана небольшая часть. Все остальное на компилятор не завязано.
HZ> И нет гарантий, что даже в текущем состоянии компилятор в HZ> какой-то ситуации не сделает что-то "нестандартно". Документированы, HZ> как правило, соглашения о вызове.
Это самое главное.
HZ> А поведение компилятора, например, в HZ> прерываниях - это внутреннее дело компилятора (и его разработчиков). HZ> Закладываться на это - это хак.
Таки тоже вполне документировано, обычно. А на что там закладываться? Важно следующее: это функция, в конце которой reti и содержимое всех регистров до входа в нее и после выхода не изменится.
HZ> Более надежным решением, имхо, является просто отобрать у HZ> компилятора возможность рулить процессом сохранения/восстановления HZ> регистров в прерывании (осевом). Т.е. чтобы он вообще к этому не HZ> касался. Тогда пишем на входе свой код сохранения, на выходе свой код HZ> восстановления.
Hа асме?
HZ> И от компилятора не зависим.
Да ладно, нужно знать хотя бы соглашения о вызовах, т.е. куда сохранять все и откуда все восстанавливать. Hа авр может это и однозначно, но для PIC18 разные компиляторы используют разные регистры указатели для орагнизации софтового стека.
[skip]
HZ> сидят, одно ПЛИС, другое МК. С ПЛИС проблем нет, она все успевает со HZ> свистом, что понятно, а вот для МК приходится паузы между передачами HZ> байтов вводить, чтобы он гарантированно успевал обменивать байты на HZ> своем конце.
Я никак не против, но если этого не делают, значит без этого можно обойтись. Или взять то, где это есть. :)
WBR, AVB