Embedded OS

Thu Mar 17 2005 19:42, Andy Mozzhevilov wrote to Harry Zhurov:

AM> Как я думаю, более оптимально с точки зрения компилятора перекладывать AM> сохранение регистров на вызываемую функцию.

В большинстве случаев экономнее получается, когда вызывающий сохраняет только те регистры, которые ему нужны. AM> В таком случае можно было бы определить соглашение AM> по регисрам, которые вызываемая функция может портить и не обязана AM> восстанавливать по выходу, а которые нет.

См. IAR C для AVR.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Reply to
Vladimir Vassilevsky
Loading thread data ...
Reply to
Alexander Torres
Reply to
Alexander Torres
Reply to
Andy Mozzhevilov
Reply to
Alexander Torres
Reply to
Alexander Torres

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

Reply to
Alexey V Bugrov
Reply to
Alexander Torres

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.