WINAVR

Reply to
George Shepelev
Loading thread data ...
Reply to
George Shepelev

^^^^^^^^^^^^^^ Тут уже вам и язык программирования не поможет. Который и не причем вовсе.....

думаю в этом выражении будет "ругань компилятора" на "c->", ну да ладно... Еще раз повторюсь, что подобную "кашу" вы можете "наварить" в любом языке... Си позволяет писать так, но не заставляет. Ассемблер тоже много чего позволяет делать. Всегда есть выбор - писать ясно и понятно или устроить "кашу" в которой концов не найдешь...

Знание одного языка мешает вам изучить и использовать другой? Мне - нет! Как другим - не знаю, за всех говорить не возьмусь....

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

"плохой стиль программирования" - характеристика человека, а не средства разработки, IMHO. Запись компактная - а места для комментария нет? Да комментируйте, кто вам не дает то. Или пишите, расписывая действия по шагам - язык вас не ограничивает.

Это верно для любой программы на любом языке. Человек должен заново погружаться в проблему о которой забыл уже давно. Комментарии помогают в этом, но они не сделают за человека его работу... Я разбирался в чужих программах на Си и на Асме, были прекрасно структурированные и оформленные экземпляры, а были и не очень - причем на обоих языках... т.е. пишется на одном языке одним человеком - все читается ОК, на том же языке пишется другим человеком - приходится напрягаться сильнее.

Прям таки и одна, а макросы? Что там получится из макроса знает только тот кто его написал. Тот кто впервые читает - должен посмотреть текст макроса, чтобы все понять - ничем не лучше... Листинг смотри, скажите вы, ну так и в Си есть листинг....

А много вы знаете Сишных и Асмовых программистов лично, чтобы оценивать такие соотношения.

Т.е. стремитесь перейти от мнемоник к более читаемым макросам. Очень хорошо, на асме я поступаю аналогично. В Си это уже сделано - ничего нового вводить не приходится: return - он и в обычной функции и в обрабочике прерывания пишется одинаково - не ошибешься.

^^^^^^ Т.е. в асме надо тоже обходить какие-то проблемы чтобы избежать ошибок. На самом деле эту проблему я сочинил глянув на список мнемоник одного из TMS320, думаю их еще можно найти... Решал я подобные проблемы - не надо приписывать мне лень или глупость...

Где же там глобальность ВСЕХ переменных? По моему для этого там COMMON-области служат. А область видимости переменных такая же как и в Си. Но он(фортран) и мне тоже не шибко нравиться, одно только автообъявление переменных чего стоит.....

Значит вы в конце концов признали, что Асм сам по себе не очень наглядный язык и программисту нужно потратить некоторые усилия чтобы сделать эту наглядность. На Си - достаточно писать соответствующим стилем.....

Выводы такие: 1. Асм - не является наглядным языком. 2. На _конкретном_ Асме можно написать наглядную и читаемую программу приложив для этого определенные усилия. 3. Сменив кристалл человеку приходится опять прилагать усилия для "очеловечивания" другого Асма. 4. Си по наглядности не хуже асма, сдобренного макросами. 5. Человек, один раз выработав стиль написания наглядных и удобочитаемых программ на Си, всегда сможет создавать наглядный и надежный код. 6. Смена кристалла не грозит пунктом 3.

Reply to
Basargin Konstantin
Reply to
George Shepelev
Reply to
George Shepelev

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 11 Oct 2005 17:32:41

+0400:

DT>>> Ты считаешь, что лучше пусть происходят _непредусмотренные_ DT>>> ни программистом, ни компилятором последствия?

DO>> Да. Программист на то и программист, чтобы предусматривать DO>> проверки там, где они нужны.

DT> Hе все такие умные, да и забыть что-то можно.

Забыть всегда можно. Можно и диапазон забыть указать или указать неправильно.

DT> А дырки должны быть все заткнуты. Особенно во встроенных приложениях.

Почему особенно?

DT>>> Hапример, знаменитое сишное переполнение массива и запись DT>>> данных поверх кода, применяемые в пресловутых "эксплойтах", DT>>> против которых микрософт выпускает заплатки раз в неделю?

DO>> Так как обычно переполняется не статический массив, а DO>> динамически выделенный буфер, все эти встроенные проверки все DO>> равно не работают.

DT> Вряд ли. Область динамической памяти, размещённая вперемешку DT> с кодом?

Видимо перемешанная с кодом область статической памяти или стека представляется тебе более естественным решением...

DT> Кстати, сегмент кода следовало бы защищать от записи...

Это вопрос организации ОС, а не языка программирования.

DT> Да и динамические объекты имеют определённый размер и их DT> переполнение можно проверять.

Можно. Причем в любом языке. Только это время...

DO>> Учитывая, что все популярные ОС написаны на C[++], а не на DO>> Аде и выполняются на имеющихся процессорах, а не на DO>> гипотетических, сравнить подходы по результату не DO>> представляется возможным.

DT> Hу, другой отмазки в данном случае и не может быть. :)

Причем не в пользу Ады...

DO>>>> Два, допустим вышла переменная за свои границы, что делать?

DT>>> В стандарте описано. Генерится, насколько я помню, DT>>> исключение.

DO>> И что дальше с ним делать?

DT> Обрабатывать, вестимо. По ситуации.

То есть вместо С++ класса, где все это в одном месте описано, получается рыхлый код, где программист должен думать об обработке этих исключительных ситуаций при каждом действии. Потому как полагаться на стандартный - получить бессмысленную для embedded остановку программы.

DT>>> Hо в нормально написанной программе такого выхода быть не DT>>> должно, это ситуация аварийная.

DO>> Если не должно, зачем проверки?

DT> Дома тоже не должны гореть, а мосты разваливаться. Часто DT> программист говорит "этой ошибки/ситуации не может быть" в DT> случаях, когда она просто маловероятна.

В детерминированной системе можно отличить невозможную (при исправном железе) ситуацию от маловероятной.

DT>>> Которая, конечно, тоже должна быть предусмотрена.

DO>> Или не должна, потому как в embedded весьма нередок случай, DO>> когда результат обработанной и необработанной ошибки в DO>> программе совершенно одинаков и пользы от этих исключений - DO>> 0.

DT> Программа не должна вести себя непредсказуемым, не DT> предусмотренным программистом (или, на худой конец, DT> компилятором) образом.

Семь бед - один ресет. В случае embedded - watchdog. Я не вижу на твоем примере чем задание типа с диапазоном и обработкой исключений лучше задания класса, в котором описаны допустимые действия и операторы. Или чем оно лучше простой переменной и ручной проверки ее значений там и тогда, где и когда это существенно. Кроме того, что в последнем случае оверхед минимален.

dima

formatting link

Reply to
Dmitry Orlov
Reply to
George Shepelev

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 11 Oct 2005 17:41:12

+0400:

DT>>> Для 18-x и dsPIC-а есть у IAR-а.

DO>> Hе думаю, что С для PIC18 у IAR лучше, чем HiTech,

DT> Может, и не лучше, но у IAR неплохой C.

В свое время я сравнивал, разница была существенная.

DT> Плюс :) C++.

Сам по себе он мне не особо нужен.

DO>> тем более, что удобней пользоваться и для PIC16 и для PIC18 DO>> одним инструментом.

DT> Hу это если вообще имеешь дело с PIC16. А если, наоборот,

Я преимущественно с ним и имею дело. PIC18 - это так, чтобы о ресурсах вообще не думать в несерийной продукции, где цена кристалла никакого значения не имеет вообще. И вместе с тем, чтобы не осваисать ради небольшой задачи что-то новое. А так только компилятор для pic18 купить. Весь остальной инструментарий тот же. И компилятор полностью совместимый.

DT> имеешь дело с разными кристаллами, но работаешь с IAR?

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

DT> И тут понадобилось работать с dsPIC-ом.

Мне пока не надобится...

dima

formatting link

Reply to
Dmitry Orlov
Reply to
Alexey V Bugrov
Reply to
Ruslan Mohniuc
Reply to
Nickita A Startcev
Reply to
Andrey Solomatov

Hello, Nickita A Startcev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 12 Oct 2005 14:55:44

+0400:

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

NA> Эта фишка документирована?

Не знаю...

dima

formatting link

Reply to
Dmitry Orlov
Reply to
Dmitry Lyokhin

Borland C++ Builder например спокойно отностится к такому { int x(34); // вызов конструктора класса int printf("%x", x); // "34" x.~int(); // <----------- правда здесь ничего не происходит :-) printf("%x", x); // "34" x = int(55); // создание нового экземпляра класса int // и вызов деструктора у объекта x, потом присвоение... printf("%x", x); // "55" }

а вот Microsoft Visual C++ ругается: "unexpected 'int ('" говорит на строчке "x.~int();"

:-)

Reply to
Basargin Konstantin

Hello, Ivan Melnikov! You wrote in conference fido7.ru.embedded to Igor Ulanov on Wed, 12 Oct 2005 19:54:32

+0400:

IU>> Это уже не ассемблер, это уже макроассемблер. Ты пользуешься IU>> макросами. Конечно макросами понятнее и нагляднее чем чистый IU>> ассемблер. Hо за использование макросами тебе так же пришлось IU>> заплатить цену, ты потерял в быстродействии и объеме кода.

IM> Мозги приятель не надо пудрить. За счет макросов не IM> теряется быстродействие работы программы. Я хотел бы знать это IM> каким образом можно добиться ? Пользуюсь постоянно и чего-то IM> не замечал.

Если макрос заменяет операторы структурного программирования, или какие-то часто используемые действия, объем кода растет из-за необходимости придерживаться соглашений о вызовах и некой универсальности этих макросов. Если это просто замена одной мнемоники другой (интересно зачем), то конечно лишнего кода это не порождает.

IM> И сколько лишнего кода ты добавляешь в программу при IM> использовании Си. Хотя я при программировании кристалла C167 IM> использую Си и макросы. Хочу отметить, при использовании IM> макросов, быстродейтсвие увеличилось, а не уменьшилось. Я с IM> помощью макросов делаю в Сишной программе ассемблерные IM> вставки.

Это как?

IM> Поэтому я за использование ассемблера, особенно во IM> встраиваемух системах.

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

dima

formatting link

Reply to
Dmitry Orlov
Reply to
Dimmy Timchenko
Reply to
Dimmy Timchenko

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.