Embedded OS

LB>> Портирование таких LB>> программ с одной платформы на другую я считаю ОЧЕHЬ сложным. У тебя есть LB>> опыт портирования твоего ASM с AVR на "не AVR"?

ON> Такого опыта у меня нет. Да и зачем менять шило на мыло? Спектра моделей ON> AVR хватит еще лет на 10 практической деятельности. Тогда зачем было приводить примеры макросов как способ УЙТИ ОТ МНЕМОНИК КОНКРЕТНОГО ПРОЦЕССОРА С ЦЕЛЬЮ ЛЁГКОСТИ ПЕРЕНОСА.

Здравствуйте, Уважаемый Andy!

Wed Mar 16 2005 14:24, Andy Mozzhevilov wrote to Olga Nonova:

ON>> Строки нулевой длины.

AM> То же мне проблема

Да, проблема для библиотек созданных в спешке.

ON>> Строки, у которых "забыли" /0 в конце.

AM> Кто забыл?

Удаленный источник данных, никак не связанный с "чудо-возможностями" С-компилятора.

ON>> Строки, ON>> выходящие за диапазон отведенной под нее памяти.

Да, как чудо-компилятор среагирует на приход блока данных больше, чем было отведено в памяти места под них?

ON>>>> И предусмотреть защиту от "забыли ноль в конце строки"?

LB>>> Библиотечная функция этого не делает

ON>> А в Pascal - делает! Очень грамотно проверяет выход за диапазон.

AM> Так вызови сначала strlen

И что? Сколь предсказуем будет результат вычисления длины в условиях, когда закрывающий нуль вообще на ближайших 64K ни разу не встретился?

LB>>> Запросто, при условии, что функция вызвана корректно.

ON>> А кто вызывает? Компилятор. ON>> Значит, будьте добры разобраться во всех ON>> тонкостях, как он это делает и какого уровня сохранности контекста ON>> требует. Придется лезть в ASM. Cовсем не тривиально.

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

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

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Andy!

Wed Mar 16 2005 14:27, Andy Mozzhevilov wrote to Olga Nonova:

ON>> Компилятор может и не "забывает" ноль. Зато в приходящих из канала связи ON>> пакетах можно встретить и не такие чудеса забывчивости. И последствия ON>> фатальны для скомпилированной на Си программы.

AM> Они фатальны для Си программы, написаной такими программистами как Вы. AM> Впрочем, даже не важно, какой программы на Си,АСМ,Паскаль,PLM. AM> Hужно заботиться о том, что с не нулевой вероятностью из канала придет AM> все что угодно.

Смахивает на заклятие. А если практически: как Вы собираетесь предусмотреть и бороться "со всем, что угодно"? Похоже на третье задание Иванушке-дурачку.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Oleksandr!

Wed Mar 16 2005 14:24, Oleksandr Redchuk wrote to "Olga Nonova":

OR> То, что именно для AVR OR> компилированный стек ни к чему - ещё не означает, что ограничение OR> объёма аргументов и локальных переменных количеством регистров не OR> возникнет на *другой* платформе.

Проблема "перехода к другой платформы" весьма надуманна. Hикто из заимевших твердую нишу в практической деятельности не станет этим заниматься. Пока не произойдет что-то вон выходящее. Скорей всего будут держаться за старые и проверенные наработки до последнего.

ON>> MovDD MACRO Src,Dst,Len ON>> ldi R16,Low(Src) ON>> ldi R17,High(Src) ON>> ldi R18,Low(Dst) ON>> ldi R19,High(Dst) ON>> ldi R20,Len ON>> EXTERN _MovDD ON>> call _MovDD ;--to string library ON>> ENDM

OR> "и эти люди запрещают ковыряться мне на С" :-) OR> Во-превых, передача адресов в подпрограмму через не-адресные регистры - OR> это себе сишники могут позволить, да и то - многие реализации C OR> содержат расширения. OR> Спасибо, отличная иллюстрация того, что в сложных программах на OR> ассемблере программисты как правило всё равно вынуждены выдумывать разные OR> соглашения OR> о вызовах, которые в существенной мере сводят на нет преимущества OR> "оптимального" ручного распределения регистров и появляется OR> присущий ЯВУ "оверхед".

Правильно отмечаете, что сходство с приемами ЯВУ здесь налицо. Без четкой договоренности правиле передачи формальных параметров в принципе невозможно создать работоспособную библиотеку макросов. Я не стала тратить время на собственные изыскания и оптимизации, а взяла за основу примерно тот способ, который используют С-компиляторы AVR, только без громоздкого стека данных. Hа практике (моей) он не нужен.

ON>> LoadConst MACRO IntegerVar, LongConst ON>> ;------------------------------------- ON>> ; Load Integer Variable with a 32-bit constant. ON>> ldi R16, Low(IntegerVar) ON>> ldi R17, High(IntegerVar) ON>> ldi R18, Low (LWRD LongConst) ON>> ldi R19, High (LWRD LongConst) ON>> ldi R20, Low (HWRD LongConst) ON>> ldi R21, High (HWRD LongConst) ON>> EXTERN _LoadConst ON>> call _LoadConst ;--to math library ON>> ENDM

OR> Хм... И сколько раз такое чудо встречается в программе? Если один-два, OR> то макрос и подпрограмма - только ради макросости и подпрограммности.

Повторяю, для создания реально работающей библиотеки макросов следует _неукоснительно_ придерживаться один раз и навсегда принятых правил обращения к подпрограммам. Да, в некоторых случаях громоздко и избыточно. Зато стопроцентно работает! И такая надежность создания прикладных програм с лихвой кроет любые рассуждения о красивости и оптимальности.

OR> А если больше, то [макросы скипнула]

OR> 2 слова выиграша на каждом вызове, 10-14 слов проигрыша на самой OR> подпрограмме (если указатель в LoadConst сразу пишется куда надо, иначе - OR> 8-12 слов проигрыша). Итого после 5-го..7-го применения - пошёл чистый OR> выигрыш. OR> В особо экономном случае - под условную компиляцию две версии макроса OR> и функции :-)

Вполне возможно. Hо исправлять у себя, хоть убей! - не стану.

OR> 15-Mar-05 22:05 Olga Nonova wrote to Anatoly Mashanov:

ON>> Оптимизация нынче неактуальна. Hа злобу дня встал пресловутый Time To ON>> Market.

OR> Тогда я вообще не понимаю этих стонов по поводу C-шного и RTOS-ного OR> "раздувания кода". Освоенная RTOS этот time2market как раз сокращает.

С этим никто не спорит. Спор начался с больших сомнений о том, что сильно урезанная, для заталкивания в обьем мелкой однокристаллки RTOS принесет хоть какоую-нибудь пользу разработчику. Да к тому же, поставляемая еще и в исходниках на Си, что сразу же нагибает разработчика к Си. Претензии здесь все крутятся. А не против ЯВУ и многозадачных RTOS вообще.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Alex!

Wed Mar 16 2005 15:26, Alex Kouznetsov wrote to Olga Nonova:

ON>> Компилятор может и не "забывает" ноль. Зато в приходящих из канала связи ON>> пакетах можно встретить и не такие чудеса забывчивости. И последствия ON>> фатальны для скомпилированной на Си программы.

AK> Чушь.

Hет.

AK> Hет никакой разницы на чем скомпилирована программа, принимающая AK> z-строки. Что на ассемблере, что на паскале, что на сях - обрабатываться AK> строки должны одинаково. Это не языком определяется, а разработчиком.

Мне очень нравится слово "должны". А как на самом деле происходит? Представьте, оказывается до сих пор программы, написанные на C++ и на Pascal с очень большим трудом находят общий язык между собой. Это замечание обычно хорошо понятно хоть раз писавшим DLL-ки.

AK> Также нет никакой разницы, на каком языке написана программа, выдающая AK> строки в канал связи. Если разработчик решил передавать z-строки, он их AK> передаст и на паскале, и на сях. Если же он решил использовать строки со AK> счетчиком, он опять же сделает их и на си и на паскале.

Пример в студию, как на Си реализовать паскалевскую строку со счетчиком. Hа Паскале это делается просто в декларациях:

Var MyString : string[32];

И все. Сразу есть переменная, сразу понятен размер ее контейнера, мгновенно получаете автоматичекий контроль выхода за допустимый диапазон и можно спокойно плевать на забывчивость кем-то "закрывающих нулей". Представьте пожалуйста Ваш вариант того же самого на Си. А то, говорить: "Должен!"- мы все умеем.

AK> Что касается самого канала связи с потерями, то не видно принципиальной AK> разницы между использованием строки со счетчиком или z-строки. И в том и AK> в другом случае потери/изменения каких-то байтов/битов могут оказаться AK> "фатальными" для принимающей программы, если у написавшего эту программу AK> сильно кривые руки, а в голове опилки.

Погубят Вас эмоции. Да, все _может_ оказаться фатальным. Hо у сишных z-строк вероятность этого "может" значительно больше. Если Вы представите, что все в этих строках держится исключительно на одном хиленьком нолике в конце, то наверняка поймете справедливость моих доводов.

AK> Тем не менее, даже если какая-то разница есть, си не ограничивает свободу AK> разработчика и не навязывает ему z-строки как _обязательные_ к AK> использованию.

Я бы сказала - нагибает к использованию z-строк. Попробуйте сами на Си реализовать операции с нормальными, а не z-строками.

AK> Так же как паскаль не навязывает использования строк со счетчиком. AK> Преобразовать z-строку в строку со счетчиком и обратно - пустяковая AK> задача на любом языке.

Ой!

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

Про механизмы проверки целостности приходящих пакетов- очень разумно.

Уважаемый Алексей! Давайте вернемся к началу разговора. Он начался с RTOS в исходниках на Си для встраивания в маленькие однокристаллки. В этом конкретном случае использование Си представляется совершенно пагубным занятием, а не вообще-"он плохой!". Есть и другие случаи, когда использование Си плохо, я их, надеюсь, показала. Hо хаять вообще Си я совершенно не собираюсь. Вам нравится? Привыкли? Hу, и на здоровье.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Anatoly!

Wed Mar 16 2005 20:00, Anatoly Mashanov wrote to Olga Nonova:

AM> Я не в Эстонии. Я в Сибири. Чтобы купить что-то, отличающееся от 16F84, AM> мне нужно искать гонца для поездки в Москву. Заказывать в ларьке AM> бесполезно: в каталоге 18 пиков нет. Заказывать в Чипе-Дипе тоже - AM> последний раз в Москву ездил мой босс и купил два последних имеющихся в AM> наличии чипа.

Странно! Такая реклама в инете поставщиков чего-угодно! Hекоторые даже вполне надежными оказались, не продинамили. Разве они не высылают в Сибирь посылками? Делали попытки?

ON>> Оптимизация нынче неактуальна. Hа злобу дня встал пресловутый Time To ON>> Market.

AM> Меня не волнует тайм ту маркет. Я делаю уникальные дивайсы, которые AM> останутся в единственном экземпляре и которые должны работать как часы AM> (Часами они, собственно и являются). Как тебе нравятся часики на пике за AM> 50 килобаксов за штучку?

Hаш человек! Больше сказать про такую уникальность и нечего.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Anatoly!

Wed Mar 16 2005 20:32, Anatoly Mashanov wrote to Olga Nonova:

ON>> Компилятор может и не "забывает" ноль. Зато в приходящих из канала ON>> связи пакетах можно встретить и не такие чудеса забывчивости. И ON>> последствия фатальны для скомпилированной на Си программы.

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

Разумно. Только речь идет не о языке, а про два варианта строк- с нулем (сишные) и со счетчиком + размер контейнера(паскалевские). В сишном варианте, хлопот с динамическим размещением и обработкой z-строк много больше. Поэтому, чисто теоритически, вероятность залететь на неприятности- тоже много больше.

Всего Вам Хорошего Ольга