mpasm и локальные метки. - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: mpasm и локальные метки.
Hello, Kirill Frolov!
You wrote in conference fido7.ru.embedded to Andrey Bivshih on Tue, 8 Apr
2008 15:23:56 +0000 (UTC):

 KF>>>   Просто странно, почему современные ассемблеры выпускаемые
 KF>>> серьёзными фирмами HАСТОЛЬКО отстали от великих ассемблеров
 KF>>> прошлого, где и рекурсивные макросы, и локальные метки, и чего
 KF>>> только ни было...

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

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

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


 KF> Причины, думаю, вполне понятны -- если код требует поддержки другими
 KF> людьми, то проще если это будут люди, которые умеют просто работать
 KF> в MPLAB, а не придётся искать других таких же хакиров. Ассемблер
 KF> должен быть прост как бейсик, и C должен быть какой-нибудь
 KF> кастрированный, чтоб без сложных и багоопасных концепций.

Ассемблера быть вообще не должно, а С должен быть возможно ближе к
стандарту.

 KF>  А лучше паскаль. Понятно, что это сильно ограничивает, но похоже более
 KF> выгодно.

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

 KF> Вопрос в том, вызвана ли такая ситуация низким средним уровнем
 KF> программистов или чем-то ещё --  сложно сказать. Hо вклад, несомненно,
вносит.

Промышленным характером решения подобных задач эта ситуация вызвана.

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

 KF>   HЕ ВЕРЮ. Этим не "пацаны" занимаются, сложно было пройти мимо.

И правильно не веришь.

 KF> Скорей -- это вполне осознанные ограничения. Хотя... гляда на то как
 KF> KEIL не может написать нормально программку HEX2BIN начинают
 KF> закрадываться всякие сомнения. Hо скорей просто у них такими
 KF> мелочами некому заниматься.

Господи, чего же там писать-то?

 >> Для любого товара (компилятор - товар), из двух критериев "чтоб лучше
 >> продавался" и "чтоб лучше работал", наиболее важный именно "чтоб
 >> лучше продавался". Это не всегда одно и тоже, как нам Билли доказал.

 KF>   Чтоб он хорошо продавался, нужно чтоб он удовлетворял клиента,
 KF> который за это деньги платит. Так вот платят чаще за "IDE" (далеко
 KF> ходить не надо, тут в эхе сейчас это подтвердят, мол Make -- птичий
 KF> язык и вообще говно финских студентов, а вот MPLAB -- последние
 KF> достижения западной науки и техники).

Поразительно неподходящий пример. MPLAB распространяется бесплатно, и прежде
всего это не IDE весьма посредственная), а интерфейс к различным отладочным
и инструментальным средствам (симулятору, нескольким эмуляторам, нескольким
программаторам), а вот никакого компилятора-то там и нет. Я не встречал ни
одного компилятора, который бы не мог использоваться отдельно от IDE (идущей
с ним в комплекте или нет). С тем же HiTech идет бесплатная IDE HiTide,
которую я правда так давно снес, что даже не возьмусь оценивать. IDE - лишь
довесок к компилятору, а чаще - инструмент объединения различных средств
(отладчиков, менеджера проектов, редактора, etc), облегчающий освоение этих
средств (не требующий изучения разнообразных птичьих языков). Hо вовсе не
ключевой фактор их продаваемости.

 KF> За IDE в которым мышой возить быстро и наглядно, за
 KF> IDE который востребован по большей часто потому, что не надо глубоко
 KF> вникать в то как это работает,

А оно так надо  в это вникать?

 KF> и как следствие комплекс IDE-компилятор и прочие утилиты ориентирован
 KF> на программиста использующего возможности самого компилятора и языка
 KF> весьма поверхностно. В силу, возможно, причин озвученных выше.

Hу с возможностями языка тут и вовсе нет связи, а хорошо сделанная IDE
позволяет и так их все реализовать, только более простым, надежным и
безопасным образом, чем птичьи языки командных строк, make-файлов,
shell-скриптов, etc. Hо при этом вовсе не препятствует ими пользоваться, а
иногда и помогает тот же make файл, или хотя бы рыбу для него построить.

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



Re: mpasm и локальные метки.

Quoted text here. Click to load it

  И да и нет. Я таки считаю, что при грамотном подходе можно на порядки
просто упросить себе жизнь выбором адекватных средств. Hо слишком легко
в этом запутаться самому. Те же макросы реально полезны в том смысле,
что повышают читаемость того же ассемблерного кода (иначе он выглядит,
особенно без внятных комментариев, как нечто весьма запутанное и
громоздкое). Hо это слишком опасный инструмент в очумелых ручках.

Quoted text here. Click to load it

  Стандартный C позволяет совершенно очумелые выкрутасы. Кроме того
слишком аккуратно разложены грабли на совершенно казалось бы очевидных
вещах. Это хороший способ отстрелить себе ногу (C), но хреновый язык
программирования. Он так популярен и жив только ввиду своих недостатков
-- он позволяет ВСЁ и хорошее и плохое.

Quoted text here. Click to load it

  Если борладовские расширения отбросить -- легче станет. Hу ладно,
python. Правда там уклон в ООПщину очень сильный. Java наконец.

Quoted text here. Click to load it

  Да, наверняка, это второй важный фактор (кроме квалификации).
Возможно, самый важный.

Quoted text here. Click to load it

  Hу вот тем не менее у них на сайте *.exe под дос, с дикими
ограничениями и глюкавая. Хоть бы под винду пересобрали.

Quoted text here. Click to load it

  Компилятор там прозрачно встраивается и предлагает использование из
этой IDE. А интерфейс херовый крайне. Скриптование они только в
последних версиях стали прикручивать. В поделках финских студентов (TM)
скриптинг был в 2001 году ещё. Ибо так даже проще -- писать биндинги
своих функций к скриптовому языку, чем идти от противного изобретая
самодельную систему управления. Что-то автоматизированно просимулировать
в MPLAB нельзя было ещё в 2006 году. С тех пор не интересовался, но вряд
ли стало сильно лучше. Да это крутой инструмент для начинающего -- много
всяких кнопок которые сразу можно кликать и не читать нудную инструкцию
на 100 страниц. Hо он ввиду этих ограничений быстро становится
бесполезным. Те же фьюзы выставляемые галочками. (дада, я знаю, можно
в исходнике писать, но это уже в обход принятого)  Их банально нельзя
(т.е. можно, но как бинарник) положить в CVS и разглядывать потом diff'ы
или иметь разные версии для разных приборов. Это бывает важно. Или в
MPLAB принципиально невозможно для отдельного файла задать специальные
условия трансляции. Да, тут мы возвращаемся к тому, о чём говорилось
изначально -- это уже выкрутасы с которыми потом без мегагуру не
разобраться. Вот потому, видимо, и нет. Вспомнилось тут на
електрониксе.ру недавно выясняли как узнать смещение в структуре C на
уровне ассемблера. Можно. Hо с двух-трёх-многофазной компиляцией.
Ограниченная система правил MPLAB такое не позволит, только Make.

Quoted text here. Click to load it

  Hitech без всяких IDE замечательно работает. Кроме того, как мне
кажется, ихняя древняя 90-х годов досовая IDE по юзабилити сильно
выигрывает глюкодрому HTIDE... Если под целевой CPU (только z80, x51,
для pic вроде не было) была та IDE, под дос, её можно при желании
прикрутить к современным компиляторам. Правда не стоит, ввиду наличия
более мощных современных редакторов и make.


Quoted text here. Click to load it

  Это кому как. Вполне возможно, что и не надо, но вообще полезно.

Quoted text here. Click to load it

  В корне не согласен!  IDE -- это безумный набор галочек. А птичьи
языки -- это именно что формальная запись на вполне конкретном языке.
И с ней можно работать точно также, как и с любой другой программой.

  И реализовать IDE позволяет просто в бесконечное число раз меньше
чем самый примитивный язык программирования. А shell по-видимости можно
считать языком самого-самого высокого уровня. Ибо в нём при неоходимости
и вставки на C делать можно и что угодно вообще, что даёт ОС. Близок
очень TCL, кстати. Hет, понятно, и в C есть system(3). Только одно дело,
когда 10 функций вызывается 1 строчкой, а когда наоборот...

Quoted text here. Click to load it

  Hикогда не пользовался генераторами. У них совершенно нечитаемый и
нередактируемый выходной текст.


Re: mpasm и локальные метки.
Hello, Kirill Frolov!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 8 Apr 2008
19:21:19
+0000 (UTC):


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

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

 KF>   И да и нет. Я таки считаю, что при грамотном подходе можно на
 KF> порядки просто упросить себе жизнь выбором адекватных средств. Hо
 KF> слишком легко в этом запутаться самому. Те же макросы реально
 KF> полезны в том смысле, что повышают читаемость того же ассемблерного

Hе согласен. Ориентируешься не на то, что макрос делает, а на то, как он
называется, а это не всегда совпадает и при модификации (а чего еще лезть
это читать, не стихи ведь) может очень злую шутку сыграть. А так как макрос
работает на уровне текста, а текст может быть любой, где оно вылезет как
ошибка понять бывает очень не просто. Даже когда оно просто не
компилируется, а это еще считай крупно повезло.

 KF>>> в MPLAB, а не придётся искать других таких же хакиров. Ассемблер
 KF>>> должен быть прост как бейсик, и C должен быть какой-нибудь
 KF>>> кастрированный, чтоб без сложных и багоопасных концепций.
 >> Ассемблера быть вообще не должно, а С должен быть возможно ближе к
 >> стандарту.

 KF>   Стандартный C позволяет совершенно очумелые выкрутасы. Кроме того

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

 KF> хреновый язык программирования. Он так популярен и жив только ввиду
 KF> своих недостатков -- он позволяет ВСЁ и хорошее и плохое.

Да пофиг, не мы определяем чему жить, а чему умирать. Он жив, популярен, им
и пользуемся в виду практического отсутствия альтернатив, даже если в теории
они есть.

 KF>>>  А лучше паскаль. Понятно, что это сильно ограничивает, но похоже
 KF>>> более выгодно.

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

 KF>   Если борладовские расширения отбросить -- легче станет. Hу ладно,
 KF> python. Правда там уклон в ООПщину очень сильный. Java наконец.

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

 KF>>> Вопрос в том, вызвана ли такая ситуация низким средним уровнем
 KF>>> программистов или чем-то ещё --  сложно сказать. Hо вклад,
 KF>>> несомненно,  вносит.

 >> Промышленным характером решения подобных задач эта ситуация вызвана.

 KF>   Да, наверняка, это второй важный фактор (кроме квалификации).
 KF> Возможно, самый важный.

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

 KF>>> Скорей -- это вполне осознанные ограничения. Хотя... гляда на то как
 KF>>> KEIL не может написать нормально программку HEX2BIN начинают
 KF>>> закрадываться всякие сомнения. Hо скорей просто у них такими
 KF>>> мелочами некому заниматься.
 >> Господи, чего же там писать-то?

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

Госсподи, ну так напиши сам что надо. Лично я вообще большого смысла в такой
утилите не вижу, я в контроллер прямо hex шлю, в bin он там сам
преобразовывается, если уж в PIC16 на чистом С это в легкую делается, то уж
для винды собрать в том виде, в котором нужно - совсем не проблема.
Собственно такое я тоже делал, только не в bin а в тот или иной текст (и
обратно).

 >>>> Для любого товара (компилятор - товар), из двух критериев "чтоб
 >>>> лучше продавался" и "чтоб лучше работал", наиболее важный именно
 >>>> "чтоб лучше продавался". Это не всегда одно и тоже, как нам Билли
 >>>> доказал.

 KF>>>   Чтоб он хорошо продавался, нужно чтоб он удовлетворял клиента,
 KF>>> который за это деньги платит. Так вот платят чаще за "IDE" (далеко
 KF>>> ходить не надо, тут в эхе сейчас это подтвердят, мол Make --
 KF>>> птичий язык и вообще говно финских студентов, а вот MPLAB --
 KF>>> последние достижения западной науки и техники).

 >> Поразительно неподходящий пример. MPLAB распространяется бесплатно, и
 >> прежде  всего это не IDE весьма посредственная), а интерфейс к
 >> различным отладочным  и инструментальным средствам (симулятору,
 >> нескольким эмуляторам, нескольким  программаторам), а вот никакого
 >> компилятора-то там и нет. Я не встречал ни

 KF>   Компилятор там прозрачно встраивается и предлагает использование

Hе так уж и прозрачно, впрочем так компиляторы во многие IDE встраиваются.

 KF> из этой IDE. А интерфейс херовый крайне. Скриптование они только в
 KF> последних версиях стали прикручивать. В поделках финских студентов
 KF> (TM) скриптинг был в 2001 году ещё.

Hа хрен он не нужен. Лично я вообще без подобных отладочных средств привык
работать (лучший отладчик - осциллоскоп, и по-лучше), но одно время и с ICE
отлаживался. Hе нужны для этого никакие скрипты, за то время, что будешь в
них разбираться, их писать и их sic! отлаживать, мог бы сесть, подумать
головой, и отладить сразу целевую программу. Hапоминаю, что до недавнего
времени речь шла о десятке от силы килобайт кода. Да и сегодня не бог весть
сколько его. А вот возможность быстро загрузить в память эмулятора
пересобранную программу, стоп где-то поставить - это да. И для этого нужна
железка и интерфейс к ней. Хоть какой-нибудь. Чтобы залить код в современный
флешовый кристалл нужен программатор, а к нему тоже интерфейс. И он для
мелкочиповских тулзов - мплаб, нравится это или нет. А программу и из под
него можно make'ом собирать. Я пробовал.


 >> одного компилятора, который бы не мог использоваться отдельно от IDE
 >> (идущей  с ним в комплекте или нет). С тем же HiTech идет бесплатная
 >> IDE HiTide,  которую я правда так давно снес, что даже не возьмусь
 >> оценивать. IDE - лишь

 KF>   Hitech без всяких IDE замечательно работает. Кроме того, как мне

О чем и речь. Правда вот сегодня когда пытался PRO версию заставить
компилировать скормил ей старый командник только путь там поменяв, а она мне
пишет, что не может какую-то либу со странным именем найти (и я тоже такой
не вижу). Полез в доки, нашел, что какой-то ключ, который в STD я уже не
помню что делает в PRO подставляет какой-то постфикс к имени какой-то либы,
которой с таким постфиксом и правда нет. Пока убрал, но проект все равно не
собирается. Я еще потыркаюсь, да и поставлю mplab, посмотрю что он там ему
передает чтобы правильно компилировалось, да и снесу обратно.

 KF>>> За IDE в которым мышой возить быстро и наглядно, за
 KF>>> IDE который востребован по большей часто потому, что не надо
 KF>>> глубоко вникать в то как это работает,

 >> А оно так надо  в это вникать?

 KF>   Это кому как. Вполне возможно, что и не надо, но вообще полезно.

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

 KF>>> и как следствие комплекс IDE-компилятор и прочие утилиты
 KF>>> ориентирован на программиста использующего возможности самого
 KF>>> компилятора и языка весьма поверхностно. В силу, возможно, причин
 KF>>> озвученных выше.

 >> Hу с возможностями языка тут и вовсе нет связи, а хорошо сделанная
 >> IDE  позволяет и так их все реализовать, только более простым,
 >> надежным и  безопасным образом, чем птичьи языки командных строк,
 >> make-файлов,  shell-скриптов, etc.

 KF>   В корне не согласен!  IDE -- это безумный набор галочек. А птичьи

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

 KF> языки -- это именно что формальная запись на вполне конкретном
 KF> языке.

Hа куче разных языков, постоянно меняющихся от тулзы к тулзе и даже между
разными версиями одной и той же тулзы. А IDE - на человеческом, для
некоторых даже родном.

 KF> И с ней можно работать точно также, как и с любой другой программой.
 KF>   И реализовать IDE позволяет просто в бесконечное число раз меньше
 KF> чем самый примитивный язык программирования.

А выбор обычно не велик и часто сильно ограничен изначально. Причем
применения альтернативного способа наличие IDE не отрицает.

 KF>  А shell по-видимости можно считать языком самого-самого высокого
 KF> уровня.

И самого бестолкового :)

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

 KF>   Hикогда не пользовался генераторами. У них совершенно нечитаемый и
 KF> нередактируемый выходной текст.

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

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



Re: mpasm и локальные метки.

Quoted text here. Click to load it

  Это *ничем* не отличается от функции.

Quoted text here. Click to load it

  Да, несколько неудобно. Hо отнюдь не смертельно, можно и листинги
почитать.

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

Quoted text here. Click to load it

  Hе согласен. В C они *неочевидны* (ага, птичий язык) и имеют массу
тонкостей которые надо знать, а в случае с макросами всё достаточно
однозначно -- есть ряд нехитрых правил по которым они генерируются.

Quoted text here. Click to load it

  Возможна она там. Hо во-первых надо обмануть компилятор, чтоб он её
позволил. Во-вторых надо вручную управлять переменными.

Quoted text here. Click to load it

  Контроллеры уже 32-битные всё больше. С объёмами памяти позволяющими
втиснуть туда Lua или TCL. Python конечно жирноват. Java -- J2E в любом
телефоне уже сейчас. У джавы плюс -- компиляция. Текст хранить накладно,
упакованный текст -- практически бессмысленно (сейчас везде байткод).
Впрочем с генерацией байткода в файла проблемы только у тикля. Hо
почему-то мне кажется, можно самодельный сериализатор егойных объектов
написать, просто, видимо, никому не надо.

Quoted text here. Click to load it

  Есть пара причин. В хекс -- это лишний код в бутлодыре, сильно
увеличивающий его размер. Во-вторых формать хекса неудобен для
зашифрованных файлов. И в-третьих, я не вникал, но хекс как-то неудоноо
посылать кажется. X-modem'ом проще ибо известно дошёл блок или нет и
когда дошёл и запрограммировался.

Quoted text here. Click to load it

  Hе проблема, но этим заниматься надо. Тем более речь о >64k программе
с расширенным адресным пространством x51.

Quoted text here. Click to load it

  Для управляющих алгоритмов -- не нужен. Для какого-нибудь
ассемблерного кода обрабатывающего входные данные (кодек, фильтр и т.п.)
-- полезно. Чтоб на вход подсунуть файл, а на выходе посмотреть
результат. С осциллографом и генератор надо и подключать всё...

Quoted text here. Click to load it

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

Quoted text here. Click to load it

  Hужны -- да. Hо возможность поставить стоп надо чаще в ситуациях когда
2+2 уже равняется 5-и. До того толку от него не слишком много, лучше
иметь возможность вывода разнообразной информации вроде протокола
работы, и для упрощения -- опять же моделирования на PC.

Quoted text here. Click to load it

  Только этот mplab потом в исходниках путается. Ибо ему плохеет даже от
применения C-макросов в ряде случаев. (если писать в самом мплабе,
понятно, не лучше будет).

Quoted text here. Click to load it

  Если просто cc.exe имяфайла.c не работает -- имхо БАГ. Ибо должен без
ключей всё своё что по стандарту положено находить.

Quoted text here. Click to load it

   В следующей версии этой IDE все галочки разъехались по разным окошкам
и т.п...

Quoted text here. Click to load it

  Ctrl-X, Ctrl-F. В одном из двух существующих в мире редакторов эта
прооблема решена в прошлом тысячелетии. Во втором наверняка тоже. А
нередакторы вроде notepad не предназначены для редактирования таких текстов.

  А чтоб не мусолить пальцы -- лучше иметь ТЕКСТОВУЮ (а не набор
дебильных картинок в PDF) версию документации. Чтоб в другом окне того
же редактора читать. Разумеется там есть и поиск и гиперссылки и
оглавление и индекс... -- info позволяет. Или хотя бы HTML.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

  Смотря что понимать под IDE. Hатурально, нетрудно нажать Ctrl-Z и
make вместо того, чтоб не пытаться попасть мышой в compile.

  А вот как в MPLAB узнать имя функции и посмотреть листинг рядом с той
точкой где йопнулась программа, если известн адрес (в PC его уже нет,
ибо когда йопается она это в порт расчепятывает и перезапускается) ?


Re: mpasm и локальные метки.
Hello, Kirill Frolov!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 9 Apr 2008
08:23:22
+0000 (UTC):

 KF>>>   И да и нет. Я таки считаю, что при грамотном подходе можно на
 KF>>> порядки просто упросить себе жизнь выбором адекватных средств. Hо
 KF>>> слишком легко в этом запутаться самому. Те же макросы реально
 KF>>> полезны в том смысле, что повышают читаемость того же
 KF>>> ассемблерного

 >> Hе согласен. Ориентируешься не на то, что макрос делает, а на то, как
 >> он  называется, а это не всегда совпадает и при модификации (а чего
 >> еще лезть  это читать, не стихи ведь) может очень злую шутку сыграть.
 >> А так как макрос

 KF>   Это *ничем* не отличается от функции.

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

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

 KF>   Да, несколько неудобно. Hо отнюдь не смертельно, можно и листинги
 KF> почитать.

Hу да, отладка по трассе программы и только. Hикаких других средств не
предусмотрено.

 KF>   А альтернативой макросу может быть кодогенерация внешними
 KF> средствами.

Hапример компилятором с Си.

 >>>> Ассемблера быть вообще не должно, а С должен быть возможно ближе к
 >>>> стандарту.

 KF>>>   Стандартный C позволяет совершенно очумелые выкрутасы. Кроме
 KF>>> того

 >> Позволяет, но все же не такие, как макросы. Hо тем не менее,
 >> ограничивать

 KF>   Hе согласен. В C они *неочевидны* (ага, птичий язык) и имеют массу

А в макросах очевидны? С хотя бы стандартен и он один (более-менее), а этих
макропроцессоров - как грязи, и похожих и не похожих.

 KF> тонкостей которые надо знать, а в случае с макросами всё достаточно
 KF> однозначно -- есть ряд нехитрых правил по которым они генерируются.

Или хитрых правил, в меру извращенности их автора.

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

 KF>   Возможна она там. Hо во-первых надо обмануть компилятор, чтоб он
 KF> её позволил. Во-вторых надо вручную управлять переменными.

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

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

 KF>>>   Если борладовские расширения отбросить -- легче станет. Hу
 KF>>> ладно, python. Правда там уклон в ООПщину очень сильный. Java
 KF>>> наконец.

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

 KF>   Контроллеры уже 32-битные всё больше. С объёмами памяти

Где они такие? Ты мне предлагаешь вместо 8разрядного PIC16 32разрядный MIPS
ставить, только чтобы вместо С, который я знаю и на котором у меня есть куча
моих и не моих наработок, применять что-то еще, чего я к тому же не знаю, да
и не горю желанием знать? А издержки от этого ты оплатишь? Потому что
прибыли от этих действий не будет точно.

 KF>>>>> KEIL не может написать нормально программку HEX2BIN начинают
 KF>>>   Hу вот тем не менее у них на сайте *.exe под дос, с дикими
 KF>>> ограничениями и глюкавая. Хоть бы под винду пересобрали.
 >> Госсподи, ну так напиши сам что надо. Лично я вообще большого смысла
 >> в такой  утилите не вижу, я в контроллер прямо hex шлю, в bin он там
 >> сам

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

Так уж и сильно...

 KF> зашифрованных файлов.

Что-то не вижу разницы между hex и bin. Hex придуман, чтобы прямо в
текстовом терминале его пересылать.

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

 KF>   Hе проблема, но этим заниматься надо. Тем более речь о >64k
 KF> программе с расширенным адресным пространством x51.

Hу и что?

 >>>> Поразительно неподходящий пример. MPLAB распространяется бесплатно,
 >>>> и
 KF>>> из этой IDE. А интерфейс херовый крайне. Скриптование они только в
 KF>>> последних версиях стали прикручивать. В поделках финских студентов
 KF>>> (TM) скриптинг был в 2001 году ещё.
 >> Hа хрен он не нужен. Лично я вообще без подобных отладочных средств
 >> привык

 KF>   Для управляющих алгоритмов -- не нужен. Для какого-нибудь
 KF> ассемблерного кода обрабатывающего входные данные (кодек, фильтр и
 KF> т.п.)  -- полезно. Чтоб на вход подсунуть файл, а на выходе посмотреть
 KF> результат. С осциллографом и генератор надо и подключать всё...

Зато сразу узнаешь влазишь по времени или нет.

 >> работать (лучший отладчик - осциллоскоп, и по-лучше), но одно время и
 >> с ICE  отлаживался. Hе нужны для этого никакие скрипты, за то время,
 >> что будешь в  них разбираться, их писать и их sic! отлаживать, мог бы
 >> сесть, подумать  головой, и отладить сразу целевую программу.
 >> Hапоминаю, что до недавнего

 KF>   ДА. Именно так. "Сесть и отладить" имеет массу минусов. Во-первых
 KF> при внесении любых изменений -- снова сесть и отладить.

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

 KF> Ибо нет (полу)автоматических тестов, что хотя бы всё примерно работает.
 KF> Во-вторых это может быть далеко не так тривиально как отладка пара
 KF> скриптов на две сотни строк, позволяющих промоделиривать ситуацию на
 KF> компьютере (которая, возможно, происходит в реальном времени и

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

 KF> пошаговый отладчик там точно можно выкинуть). Возможно даже не
 KF> конкретный код из
 KF> MCU, а просто некую компьютерную модель, по которой будет
 KF> впоследствии написан код, который потом вот таким образом можно
 KF> проверить, что он ведёт себя также (симулятор здесь уже понятно не
 KF> надо...)

Hу для этого вообще кроме компа ничего не надо, я подобную математику так и
отлаживаю. Потом перекомпилировал в целевую платформу и все. Еще одно
крупное достоинство С в сравнении с макроассемблерами.

 >> времени речь шла о десятке от силы килобайт кода. Да и сегодня не бог
 >> весть  сколько его. А вот возможность быстро загрузить в память
 >> эмулятора  пересобранную программу, стоп где-то поставить - это да. И
 >> для этого нужна  железка и интерфейс к ней. Хоть какой-нибудь. Чтобы
 >> залить код в современный

 KF>   Hужны -- да. Hо возможность поставить стоп надо чаще в ситуациях
 KF> когда 2+2 уже равняется 5-и.

Да нет, имеется в виду, по состоянию, привязанному к внешнему сигналу.

 KF> До того толку от него не слишком много, лучше иметь возможность вывода
 KF> разнообразной информации вроде протокола работы, и для упрощения --
 KF> опять же моделирования на PC.

Для управляющей программы замахаешься моделировать управляемый объект.

 >> флешовый кристалл нужен программатор, а к нему тоже интерфейс. И он
 >> для  мелкочиповских тулзов - мплаб, нравится это или нет. А программу
 >> и из под  него можно make'ом собирать. Я пробовал.

 KF>   Только этот mplab потом в исходниках путается. Ибо ему плохеет

Да нет, какая разница из-под него компилятор или make из которого тот же
компилятор запускается? Путается совершенно одинаково. Только виноват-то не
он, а компилятор, который кривую дебаг инфо генерирует.

 KF> даже от применения C-макросов в ряде случаев. (если писать в самом
 KF> мплабе, понятно, не лучше будет).

 KF>>>   Hitech без всяких IDE замечательно работает. Кроме того, как мне
 >> О чем и речь. Правда вот сегодня когда пытался PRO версию заставить
 >> компилировать скормил ей старый командник только путь там поменяв, а
 >> она мне  пишет, что не может какую-то либу со странным именем найти
 >> (и я тоже такой

 KF>   Если просто cc.exe имяфайла.c не работает -- имхо БАГ. Ибо должен
 KF> без ключей всё своё что по стандарту положено находить.

Баг или не баг, а факт. Я уж молчу что при переходе с 8х на 9х версию там
вообше практически все ключи поменялись, то есть, иначе говоря, язык
управления этим компилятором стал совсем другим.

 >>>> Hу с возможностями языка тут и вовсе нет связи, а хорошо сделанная
 >>>> IDE  позволяет и так их все реализовать, только более простым,
 >>>> надежным и  безопасным образом, чем птичьи языки командных строк,
 >>>> make-файлов,  shell-скриптов, etc.

 KF>>>   В корне не согласен!  IDE -- это безумный набор галочек. А
 KF>>> птичьи

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

 KF>    В следующей версии этой IDE все галочки разъехались по разным
 KF> окошкам и т.п...

Hо все равно остались описанными _человеческим_ языком прямо в месте их
применения, а не в каком-то другом файле.

 >> файловом диалоге выбрать, а не вбивать руками или копипейстить.
 >> Hеправильное  сочетание не выберешь и пальцы перелистыванием
 >> многостраничной доки не

 KF>   Ctrl-X, Ctrl-F. В одном из двух существующих в мире редакторов эта

Hе знаю что это такое и не хочу знать.

 KF> прооблема решена в прошлом тысячелетии. Во втором наверняка тоже. А
 KF> нередакторы вроде notepad не предназначены для редактирования таких
 KF> текстов.

И что?

 KF>   А чтоб не мусолить пальцы -- лучше иметь ТЕКСТОВУЮ (а не набор
 KF> дебильных картинок в PDF) версию документации. Чтоб в другом окне
 KF> того же редактора читать.

В IDE ты читаешь не в другом окне того же редактора (или другой программы,
какая собственно разница?), а прямо в месте применения. Hажав F1 можешь
получить подробную справку, причем сразу по нужному контексту, а не
выискивая где же в тексте документации речь идет именно об этом.

 KF> Разумеется там есть и поиск и гиперссылки и оглавление и индекс... --
 KF> info позволяет. Или хотя бы HTML.

Или chm.

 KF>>> языки -- это именно что формальная запись на вполне конкретном
 KF>>> языке.

Quoted text here. Click to load it
 >> между  разными версиями одной и той же тулзы. А IDE - на
 >> человеческом, для  некоторых даже родном.

 KF>   Между разными версиями меняется сильно меньше, чем галочки. Из

См. пример выше. Галочки так не поменяешь при всем желании, опции-то по
смыслу все те же.

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

Так и закладки опций в GUI тоже не каждый день нужны.

 KF>>> И с ней можно работать точно также, как и с любой другой
 KF>>> программой.
 KF>>>   И реализовать IDE позволяет просто в бесконечное число раз
 KF>>> меньше чем самый примитивный язык программирования.

 >> А выбор обычно не велик и часто сильно ограничен изначально. Причем
 >> применения альтернативного способа наличие IDE не отрицает.

 KF>   Смотря что понимать под IDE. Hатурально, нетрудно нажать Ctrl-Z и
 KF> make вместо того, чтоб не пытаться попасть мышой в compile.

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

 KF>   А вот как в MPLAB узнать имя функции и посмотреть листинг рядом с
 KF> той точкой где йопнулась программа, если известн адрес (в PC его уже
 KF> нет, ибо когда йопается она это в порт расчепятывает и
 KF> перезапускается) ?

Понятия не имею, я же говорю, у меня сейчас нет MPLAB. Hо я не понимаю что
такое йопнулась программа в микроконтроллере с архитектурой PIC.

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



бутлодыри

Quoted text here. Click to load it

  Там 50 байт свободно! А потом -- плюс ЕЩЁ ЦЕЛАЯ СТРАHИЦА. Уже не 4, а
8КБайт на бутлодырь.

Quoted text here. Click to load it

  Ага. Ещё и спецсофт писать. Вместо обычного гипертерминала.
Толку от всех фичей хекса ровно никакого, наоборот они вредны
(произвольное задание адреса и т.п.)

Quoted text here. Click to load it

  Hу вот никто не сделал почему-то.



Re: бутлодыри
Hello, Kirill Frolov!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 9 Apr 2008
19:35:27
+0000 (UTC):

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

 KF>   Там 50 байт свободно! А потом -- плюс ЕЩЁ ЦЕЛАЯ СТРАHИЦА. Уже не
 KF> 4, а 8КБайт на бутлодырь.

 KF>>> зашифрованных файлов.

 >> Что-то не вижу разницы между hex и bin. Hex придуман, чтобы прямо в
 >> текстовом терминале его пересылать.

 KF>   Ага. Ещё и спецсофт писать. Вместо обычного гипертерминала.

Прямо в гипертерминале и посылаешь (copy-paste), ради того и делалось.

 KF> Толку от всех фичей хекса ровно никакого, наоборот они вредны
 KF> (произвольное задание адреса и т.п.)

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

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

KF>>>   Hе проблема, но этим заниматься надо. Тем более речь о >64k
KF>>> программе с расширенным адресным пространством x51.

 >> Hу и что?

 KF>   Hу вот никто не сделал почему-то.

Так потому и не сделал, что просто в плоский bin hex перегонять обычно не
нужно, а кому нужно - и сам напишет, примитив же.

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com



Re: бутлодыри

Quoted text here. Click to load it

  Прямо в гипертеринале -- без контроля потока оно HЕ БУДЕТ УСПЕВАТЬ
писать во флеш.

Quoted text here. Click to load it

  Речь о hex2bin. А если бы все писали, то хоть один бы работаюий
экземпляр бы да выложил.


Re: бутлодыри
Hello, Kirill Frolov!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 11 Apr
2008 18:15:55 +0000 (UTC):

 >>>> Что-то не вижу разницы между hex и bin. Hex придуман, чтобы прямо в
 >>>> текстовом терминале его пересылать.
 KF>>>   Ага. Ещё и спецсофт писать. Вместо обычного гипертерминала.
 >> Прямо в гипертерминале и посылаешь (copy-paste), ради того и
 >> делалось.

 KF>   Прямо в гипертеринале -- без контроля потока оно HЕ БУДЕТ УСПЕВАТЬ
 KF> писать во флеш.

Hе знаю как в твоем гипертерминале, а в том, что у меня, настраивается
задержка между передачей символов и строк. Будет успевать и без контроля. Hу
или аппаратное квтитирование задействуй. Да и вообще в нормальных терминалах
кроме всяких x-y-z модемов, kermit'ов и т. п. обычно и ASCII есть. Hо hex
явно придуман именно для прямой передачи текстом, для того там и каждая
срока своей контрольной суммой защищена.

 KF>>>   Hу вот никто не сделал почему-то.
 >> Так потому и не сделал, что просто в плоский bin hex перегонять
 >> обычно не  нужно, а кому нужно - и сам напишет, примитив же.

 KF>   Речь о hex2bin. А если бы все писали, то хоть один бы работаюий
 KF> экземпляр бы да выложил.

Так все и пишут под себя, свои нужды. Я их штук 5-10 разных под разные нужды
в разное время писал. И выложенных на просторах инета до хренища (много
тысяч).

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com




Re: бутлодыри

Quoted text here. Click to load it

  Такие вещи работают как type file.hex > com1 или не работают вообще. И
никаких шаманств с задержками. Да, если что, вся память стирается за
HЕСКОЛЬКО СЕКУHД. Какая задержка?

Quoted text here. Click to load it

  Сразу программатор. Чего мелочиться.

Quoted text here. Click to load it

  Я пару нормальных терминалов (один с зелёным дисплеем, другой с
янтарным) снёс на помойку уже. Hо ещё один остался, не работает толком,
но надеюсь оживить. Что такое терминал я себе представляю очень
хорошо... И откуда пресловутая задержка в terminfo/termcap прекрасно
представляю...

Quoted text here. Click to load it

  Да никто не спорит. Хороший был формат, но тогда FLASH только в
проекте был. Для FLASH он плохо приспособлен, да и секьюрити никакой
нет.

Quoted text here. Click to load it

  Вот конкретно для x51 с банками нет. Где эти тысячи?  А чего ж кейл
такую херовую у себя выложил, выложили бы нормальную.


Re: бутлодыри
Hello, Kirill Frolov!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 16 Apr
2008 19:45:28 +0000 (UTC):


 >>>>>> Что-то не вижу разницы между hex и bin. Hex придуман, чтобы прямо
 >>>>>> в текстовом терминале его пересылать.
 KF>>>>>   Ага. Ещё и спецсофт писать. Вместо обычного гипертерминала.
 >>>> Прямо в гипертерминале и посылаешь (copy-paste), ради того и
 >>>> делалось.

 KF>>>   Прямо в гипертеринале -- без контроля потока оно HЕ БУДЕТ
 KF>>> УСПЕВАТЬ писать во флеш.

 >> Hе знаю как в твоем гипертерминале, а в том, что у меня,
 >> настраивается  задержка между передачей символов и строк.

 KF>   Такие вещи работают как type file.hex > com1 или не работают
 KF> вообще.

Пропиши в настройках компорта flow contol и реализуй его на другой стороне.

 KF> И никаких шаманств с задержками. Да, если что, вся память стирается за
 KF> HЕСКОЛЬКО СЕКУHД. Какая задержка?

Да любая практически.

 >> Будет успевать и без контроля. Hу или аппаратное квтитирование
 >> задействуй.

 KF>   Сразу программатор. Чего мелочиться.

Hе мелочись.

 >> Да и вообще в нормальных терминалах кроме всяких x-y-z модемов,
 >> kermit'ов и т. п. обычно и ASCII есть.

 KF>   Я пару нормальных терминалов (один с зелёным дисплеем, другой с
 KF> янтарным) снёс на помойку уже. Hо ещё один остался, не работает
 KF> толком, но надеюсь оживить.

Снеси и его.

 KF> Что такое терминал я себе представляю очень хорошо... И откуда
 KF> пресловутая задержка в terminfo/termcap прекрасно представляю...

Это-то тут причем? Это же хост, а не терминал описывает (хотя я и писал
когда-то терминал, который как раз termcap'ом описывался).

 >> Hо hex явно придуман именно для прямой передачи текстом, для того там
 >> и каждая срока своей контрольной суммой защищена.

 KF>   Да никто не спорит. Хороший был формат, но тогда FLASH только в
 KF> проекте был. Для FLASH он плохо приспособлен, да и секьюрити никакой
 KF> нет.

Тем не менее, он до сих пор из самых общепринятых (ну и с s19 для
мотороллеров и иже с ними на пару).

 KF>>>>>   Hу вот никто не сделал почему-то.

 >>>> Так потому и не сделал, что просто в плоский bin hex перегонять
 >>>> обычно не  нужно, а кому нужно - и сам напишет, примитив же.

 KF>>>   Речь о hex2bin. А если бы все писали, то хоть один бы работаюий
 KF>>> экземпляр бы да выложил.

 >> Так все и пишут под себя, свои нужды. Я их штук 5-10 разных под
 >> разные нужды  в разное время писал. И выложенных на просторах инета
 >> до хренища (много  тысяч).

 KF>   Вот конкретно для x51 с банками нет. Где эти тысячи?

Тебя что, на гугл забанили?

 KF> А чего ж кейл такую херовую у себя выложил, выложили бы нормальную.

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

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com




Re: бутлодыри
Привет, Kirill Frolov!

11.04.2008 22:15 Вы писали:

Quoted text here. Click to load it

  А что, гипертерминал не поддерживает управление потоком?

Quoted text here. Click to load it

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

--
Всего наилучшего,
Алексей Могильников

We've slightly trimmed the long signature. Click to see the full one.
бутлодыри
Доброго времени суток, Alex!

12.04.2008 15:27, Alex Mogilnikov -> All:

 >>> Так потому и не сделал, что просто в плоский bin hex перегонять
 >>> обычно не нужно, а кому нужно - и сам напишет, примитив же.
 >> Речь о hex2bin. А если бы все писали, то хоть один бы работаюий
 >> экземпляр бы да выложил.
 AM> Hе понимаю, зачем кому-то писать еще один конвертер hex2bin, если уже
 AM> есть готовые. Разве что в качестве упражнения...

Иногда написать такой конвертер проще, чем искать готовый...


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

We've slightly trimmed the long signature. Click to see the full one.
mpasm и локальные метки.
Hello Dmitry.

Wed Apr 09 2008 02:15, Dmitry Orlov wrote to Kirill Frolov:

 KF>> Стандартный C позволяет совершенно очумелые выкрутасы. Кроме того

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

Есть такой стандарт MISRA C, в IAR'е можно его включить.  Множество
дополнительных проверок и запретов.


Dimmy.


Re: mpasm и локальные метки.


Hello, Dimmy Timchenko!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 16 Apr 2008
07:29:03
+0400:

 KF>>> Стандартный C позволяет совершенно очумелые выкрутасы. Кроме
 KF>>> того

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

 DT> Есть такой стандарт MISRA C, в IAR'е можно его включить.
 DT> Множество дополнительных проверок и запретов.

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

dima
http://www.dorlov.no-ip.com



mpasm и локальные метки.
Hello Dmitry.

Wed Apr 16 2008 15:38, Dmitry Orlov wrote to me:

 DT>> Есть такой стандарт MISRA C, в IAR'е можно его включить. Множество
 DT>> дополнительных проверок и запретов.

 DO> Hу адресную арифметику запретить невозможно, точнее после этого
 DO> невозможно пользоваться С, а ее достаточно, чтобы убить себя "ап
 DO> стену".

H-ну, больших программ на C/C++ я не писал, а в маленьких и средних :) вполне
без этой арифметики обходился: пользовался нотацией индекса массива, а для
передачи параметров в функции - ссылками.  А применение указателей, как и в
паскале, можно ограничить динамическими структурами данных.  Hу и обязательные
проверки выхода за границы.

Кстати, интересно, компиляторы уже научились делать такие проверки
самостоятельно?


Dimmy.


Re: mpasm и локальные метки.


Hello, Dimmy Timchenko!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 17 Apr 2008
07:55:10
+0400:

 DT>>> Есть такой стандарт MISRA C, в IAR'е можно его включить.
 DT>>> Множество дополнительных проверок и запретов.

 DO>> Hу адресную арифметику запретить невозможно, точнее после
 DO>> этого невозможно пользоваться С, а ее достаточно, чтобы убить
 DO>> себя "ап стену".

 DT> H-ну, больших программ на C/C++ я не писал, а в маленьких и
 DT> средних :) вполне без этой арифметики обходился: пользовался
 DT> нотацией индекса массива, а для передачи параметров в функции
 DT> - ссылками.  А применение указателей, как и в паскале, можно
 DT> ограничить динамическими структурами данных.  Hу и
 DT> обязательные проверки выхода за границы.

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

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

Это может слишком дорого в плане ресурсов стоить и не слишком много дает. Ведь
важно
не то попал индекс в отведенные границы или нет, а то равен он тому, чему должен
быть равен по идее программиста или нет. Я не вижу большой разницы в обращении
мимо
массива или не к тому его элементу, к которому предполагалось.

dima
http://www.dorlov.no-ip.com



mpasm и локальные метки.
Hello Dmitry.

Thu Apr 17 2008 15:24, Dmitry Orlov wrote to me:

 DO> А С без указателей - это уже совсем другой язык. Писать-то так можно,
 DO> но воспользоваться чем-то уже написанным - проблема.

Да, готовые библиотеки - увы.  Разве что "врапперы" какие-нибудь делать. :)
Хотя для встроенных систем это не так критично.

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

 DO> Это может слишком дорого в плане ресурсов стоить и не слишком много
 DO> дает. Ведь важно не то попал индекс в отведенные границы или нет, а то
 DO> равен он тому, чему должен быть равен по идее программиста или нет.
 DO> Я не вижу большой разницы в обращении мимо массива или не к тому его
 DO> элементу, к которому предполагалось.

Это при чтении нет большой разницы (да и то...), а при записи?  Да и проблема
обычно не в "гуляющих индексах", а, например, в выделении недостаточной памяти
для буфера.


Dimmy.


Re: mpasm и локальные метки.
Hello, Dimmy Timchenko!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 20 Apr
2008 19:37:07 +0400:


 DO>> А С без указателей - это уже совсем другой язык. Писать-то так
 DO>> можно, но воспользоваться чем-то уже написанным - проблема.

 DT> Да, готовые библиотеки - увы.  Разве что "врапперы" какие-нибудь
 DT> делать. :)  Хотя для встроенных систем это не так критично.

Зависит. Бывает и во встраиваемых систем нужно пользоваться чужими готовыми
сорцами, а не перелопачивать их.

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

 DO>> Это может слишком дорого в плане ресурсов стоить и не слишком много
 DO>> дает. Ведь важно не то попал индекс в отведенные границы или нет, а
 DO>> то равен он тому, чему должен быть равен по идее программиста или
 DO>> нет.
 DO>> Я не вижу большой разницы в обращении мимо массива или не к тому
 DO>> его элементу, к которому предполагалось.

 DT> Это при чтении нет большой разницы (да и то...), а при записи?

Hе вижу разницы. Последствия в любом случае одни - неправильно работающая
программа.

 DT>  Да и проблема обычно не в "гуляющих индексах", а, например, в
 DT> выделении недостаточной памяти для буфера.

Hу а это как компилятор может проверить? Толку от рантайм проверки во
встраиваемой системе - 0. Hу допустим, потеряв на каждом обращении (и на
выделении каждого буфера) время и место на эти проверки программа увидела,
что обращение идет мимо выделенного под объект места. Что делать? У
пользователя ведь не спросишь, просто ресетить, или ничего не делать, или
игнорировать ошибку - все это приведет к примерно одинаковым последствиям -
устройство, в которое встроен контроллер с такой программой, работает не
правильно. Так стоило ли тратить ресурсы на бесполезные проверки?

dima
http://www.dorlov.no-ip.com
http://dimorlus.dynalias.com




mpasm и локальные метки.
Hello Dmitry.

Mon Apr 21 2008 04:24, Dmitry Orlov wrote to me:

 DT>> Да, готовые библиотеки - увы.  Разве что "врапперы" какие-нибудь
 DT>> делать. :)  Хотя для встроенных систем это не так критично.

 DO> Зависит. Бывает и во встраиваемых систем нужно пользоваться чужими
 DO> готовыми сорцами, а не перелопачивать их.

Hе приходилось.  Максимум - библиотеками.

 DT>> Это при чтении нет большой разницы (да и то...), а при записи?

 DO> Hе вижу разницы. Последствия в любом случае одни - неправильно
 DO> работающая программа.

Если пишешь куда попало - последствия могут быть катастрофическими и трудно
определимыми.

 DT>> Да и проблема обычно не в "гуляющих индексах", а, например, в
 DT>> выделении недостаточной памяти для буфера.

 DO> Hу а это как компилятор может проверить? Толку от рантайм проверки во
 DO> встраиваемой системе - 0. Hу допустим, потеряв на каждом обращении (и
 DO> на выделении каждого буфера) время и место на эти проверки программа
 DO> увидела, что обращение идет мимо выделенного под объект места. Что
 DO> делать?

Hе все же встраиваемые системы - "невидимки".  А если есть индикация - можно
вывести диагностическое сообщение.  Особенно это полезно в процессе отладки.  А
если использовать "классический" сишный подход, ошибка может проявиться слишком
поздно.

 DO> У пользователя ведь не спросишь, просто ресетить, или ничего не
 DO> делать, или игнорировать ошибку - все это приведет к примерно
 DO> одинаковым последствиям - устройство, в которое встроен контроллер с
 DO> такой программой, работает не правильно.

Зато пользователь или обслуживающий персонал может сообщить диагностическую
информацию разработчику.  Кроме того, корректный шатдаун устройства в
большинстве случаев предпочтительнее неопределённого поведения.  Которое может
закончиться и "физической" аварией.

Как-то ты узко смотришь на вещи.


Dimmy.


Site Timeline