Embedded OS

Reply to
Anatoly Mashanov
Loading thread data ...
Reply to
Anatoly Mashanov
Reply to
Alexey V Bugrov
16-Mar-05 10:33 Olga Nonova wrote to Leha Bishletov:

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

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

Reply to
Oleksandr Redchuk
Reply to
Alexander Torres
Reply to
Dmitriy Cherkashin
Reply to
Alexander Torres
Reply to
Dmitriy Cherkashin

Здравствуйте, Уважаемый 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> правильно делается, а не пеняйте на компилятор.

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

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

Reply to
Olga Nonova

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

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

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

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

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

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

Reply to
Olga Nonova

Здравствуйте, Уважаемый 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 вообще.

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

Reply to
Olga Nonova

Здравствуйте, Уважаемый 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у, и на здоровье.

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

Reply to
Olga Nonova

Здравствуйте, Уважаемый 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аш человек! Больше сказать про такую уникальность и нечего.

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

Reply to
Olga Nonova

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

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

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

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

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

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

Reply to
Olga Nonova

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.