[aaarrr 69]

Добавление к квалификации и молодежного сленга "глючный компилятор"

<{POST_SNAPBACK}>

 

И что Вы хотите этим сказать? Что GNU дОлжно рассматривать как референсный компилер что ли?

[Виктория 0]

Добавление к теме о квалификации (и против молодежного сленга "глючный компилятор" )

[aaarrr 69]

Добавление к теме о квалификации

 

Может быть поясните, что Вы имели в виду?

 

и против молодежного сленга "глючный компилятор"

 

Вечер перестает быть томным :angry2: Если уж так хочется цепляться к словам - хотя бы цитируйте точно.

[NickS 0]

А что, писание на асме это "западло"?

в общем да

 

<{POST_SNAPBACK}>

 

 

И это есть самый главный ответ.

Как я замечал в частных беседах об достоинствах и недостатках "С".

Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.

Как я понимаю этим они просто оправдывают свою не компитентность.

Ибо любому, кто писал на ASM просмотр ASM лиснинга С компилятора приводит в ужас.

 

Единственное оправдание написания программ на С - доступность для понимания программистами заказчика.

 

Потому, если планируется сопровождение передаваемой программы другими программистами, особенно если они не понимают ASM, то писать надо на С.

[Виктория 0]

Добавление к теме о квалификации

 

Может быть поясните, что Вы имели в виду?

 

и против молодежного сленга "глючный компилятор"

 

Вечер перестает быть томным :angry2: Если уж так хочется цепляться к словам - хотя бы цитируйте точно.

<{POST_SNAPBACK}>

 

:) :)

 

Aaarrr, давайте лучше другой пример

(а то скоро закроют тему из-за флейма)

[Andy_Mozzhevilov 0]

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

 

А кто ее будет так использовать? Ежели это моя функция, то вызывать её буду только я и правильно.

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

 

Например, в IAR memcpy написана нак inline функция в string.h

 

Ужасно! Всегда считал IAR кривым компилером.

IAR очень приличный компилятор. Если специально не пытаться залезть в бутылочное горло, пытаясь доказать неэффективность.

 

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

<{POST_SNAPBACK}>

 

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

<{POST_SNAPBACK}>

 

Понимать язык и уметь свободно на нем общаться - 2 большие разницы.

Вы изначально высказали мнение, что проекты для мелких микроконтроллеров должны писаться на асм:

Интересно, а на LPC2101 тоже на C будем писать?

Может быть и прекрасно, да только уж на мелких восьмибитниках ASM сам доктор прописал использовать

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

На данный момент мой опыт насчитывает работу как минимум с 7 различными семействами процессоров, не считая писишного x86. С 4 из них я работал довольно плотно. В том числе много проектов приходится сопровождать. Все написано на Ц, за исключением критических мест, которых очень не много.

Как вы считаете, насколько хорошо можно сопровождать проект, написанный на асм, если на данный момент этот процессор активно не используется?

Например, x51 мы не закладываем в новые разработки уже лет 5, а проекты сопровождать нужно. Каждый раз вспоминать асм и копаться в неструктурированном коде? Ради чего, мифического увеличения производительности и уменьшения объема кода на 30%-50%?

[AlexeyAS 0]

Ни кто не сопротивляется по поводу иногда маразма компиляции. Пиши на асме, перекладывать ДСП функции на АРМ и хвалится тем что выжимаем максимум скорости - я считаю маразмом, потому что есть ОМАП двухядерный, нет желания - внешний ДСП ставте.

С - повторное использование кода, ведь пользуетесь исли нет то горш цена. 

 

 

Что то как то все однобоко!

 

Си прежде всего инструмент, соответсвенно и пользоваться им можно по разному. Можно и гвозди заколачивать. Если желаете переносимиость с одной платформы на другую как можно меньшей кровью, то решение в пользу ЯВУ - однозначно.

 

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

 

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

 

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

 

Что в сухом остатке

1. Сравнение кода генерируемого компилятором

2. Флейм.

3. Совместное  использование асм и С.

 

Ну я же говорю однобоко. Можно тогда повсеместно на VM машины переходить или на FORTH процессоры, или на DSSP. Вопрос тогда сам собой отпадет последнии два выполненные на ASIC будут маш кодом автоматически являсь ЯВУ.

[AlexeyAS 0]

Например, x51 мы не закладываем в новые разработки уже лет 5, а проекты сопровождать нужно. Каждый раз вспоминать асм и копаться в неструктурированном коде? Ради чего, мифического увеличения производительности и  уменьшения объема кода на 30%-50%?

<{POST_SNAPBACK}>

 

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

 

А ради чего, вопрос риторический.

Следую вашей логике можно как и в мире CPU платить огромные деньги за 30% прибавку производительности, что бы писать на ЯВУ всем и как угодно, затем еще на 10% что бы писать было быстро и каждый год по 5% что бы еще быстрее. С некоторой стороны этот принцип оправдывается получением сверхприбыли, но сущесвтует момент времени до которого потребитель согласен терепеть постоянный отъем заработанных средств ;).

Что говорить что подобный путь развития ЭКСТЕНСИВЕН. ;(

[VladislavS 37]

То же от IAR. Оценивать хорошо это или плохо не бурусь.

 

<{POST_SNAPBACK}>

Это какой версией компилятора компилировалось? Какие опции оптимизации были установлены?

<{POST_SNAPBACK}>

 

Последней вестимо - 4.30a. Из опций - оптимизация по скорости или по размеру дает один и тот же результат.

[Andy_Mozzhevilov 0]

А что, писание на асме это "западло"?

в общем да

<{POST_SNAPBACK}>

И это есть самый главный ответ.

Да.

 

Как я замечал в частных беседах об достоинствах и недостатках "С".

Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.

Перед вами человек, умеющий писать на асм.

 

 

Как я понимаю этим они просто оправдывают свою не компитентность.

Не считаю не умение именно писать на асм в масштабе проекта - некомпетентностью. Большей некомпетентностью, я, например, считаю не умение писать под ОС. Особенно в контексте обсуждения 32битных платформ.

 

Ибо любому, кто писал на ASM просмотр ASM лиснинга С компилятора приводит в ужас.

Чем именно ужаснули вас те примеры, пусть мелких функций, которые я привел? Думаю, я добью со временем и fft на Ц и сравню по производительности на реальном железе, тут уже просто профессиональный интерес.

 

Единственное оправдание написания программ на С - доступность для понимания программистами заказчика.

Это как? Причем тут заказчик. Его как правило интересует устройство, обладающее определенными функциями и по определенной цене. О таких деталях, как компилятор, ассемблер или прочие мелочи он может даже не знать.

 

Потому, если планируется сопровождение передаваемой программы другими программистами, особенно если они не понимают ASM, то писать надо на С.

<{POST_SNAPBACK}>

На С удобнее писать, даже если планируется лишь самоличное сопровождение.

 

Далее следует мое имхо:

Как я сделал вывод после продолжительного общения в конференциях есть 2 категории людей, пишуших на асм:

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

 

2 категория, люди, считающие программирование искусством сродни живописи и сочинению музыки. Для них эффективность - это самоцель, она их волнует даже тогда, когда необходимости в ней нет. Им не важно, что программа для проекта, написанная на асме занимает 1К, а на Ц - 2K при доступной памяти 4К. Им не важно, что на асме производительность процессора используется на 50%, а на Ц- на 80%. Главное, что на асме - короче, главное, что на асме - быстрее. Как только пытаешься выянисть, в чем же причина и необходимость в этом самолюбовании, то сразу же находится куча частных случаев, в которых Ц действительно дает большой проигрыш. Цифры быстродействия и объема кода сразу становятся такими, что на асм используется 90% ПЗУ, а на Ц нужно 140%, на асм используется 80% производительности, а на Ц нужно 160%. Любимый пример - алгоритмны, использующие сдиг через перенос. Еще можно откомпилировать "hello, world!" на Ц и получить по сравнению с асм разницу в эффективности на 2 порядка. Полученные результаты начинают экстраполироваться на все, что движется. Это грустно, потому как такие люди, являясь в большинстве своем действительно профессионалами, воздействуют на неокрепшие умы категории 1, тем самым отдаляя для них перспективы перехода на ЯВУ, либо вообще переводя со временем их в свою категорию.

[Andy_Mozzhevilov 0]

То же от IAR. Оценивать хорошо это или плохо не бурусь.

 

<{POST_SNAPBACK}>

Это какой версией компилятора компилировалось? Какие опции оптимизации были установлены?

<{POST_SNAPBACK}>

 

Последней вестимо - 4.30a. Из опций - оптимизация по скорости или по размеру дает один и тот же результат.

<{POST_SNAPBACK}>

киньте проект, плз, у меня что-то несколько другой код получается.

или лист программы, которую компилируете.

[Andy_Mozzhevilov 0]

Например, x51 мы не закладываем в новые разработки уже лет 5, а проекты сопровождать нужно. Каждый раз вспоминать асм и копаться в неструктурированном коде? Ради чего, мифического увеличения производительности и  уменьшения объема кода на 30%-50%?

<{POST_SNAPBACK}>

 

А что такие проекты уже не структуируются средствами АСМ и не документируются по процедурно?

Это можно сделать, но фактически нужно будет работать компилятором с ЯВУ в уме. Это не интересно.

При большом проекте все равно придется выработать определенные правила, как то - способы передачи аргументов функциям и способы возврата результатов, соглашения по использованию регистров в вызывающей и вызываемой функциях. Для мелких архитектур, типа х51 размещение локальных переменных функций в памяти - вообще задача не тривиальная, если ее делать руками. Ну и т.п. А потом ради чего? Ради мифических 30% размера кода/производительности? Так оно и на Ц с некоторым запасом.

 

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

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

 

  А ради чего, вопрос риторический.

  Следую вашей логике можно как и в мире CPU платить огромные деньги за 30% прибавку производительности, что бы писать на ЯВУ всем и как угодно, затем еще на 10% что бы писать было быстро и каждый год по 5% что бы еще быстрее.

Вопрос очень даже практический. Если программа занимает 1К на асме, и 1.5К на Ц при доступной памяти 2К, то 0.5К оверхеда Ц бесплатно.

Только не надо мне петь про тот граничный случай, когда на асме влазит в 1 кристалл, а на Ц нужно брать более старший и платить на с50 больше. Если это даже так, то в наших, российских условиях, где преобладает мелкотиражное производтство, это мало кого волнует. Гораздо больше волнует выскочить на рынок быстрее, а там других расходов немерянно. Те же испытания на ЭМС сделать, метрологию, в коммандировки слетать по 3000р за номер/сутки - и c50 за контроллер покажутся вам каплей в морe, если до этого действительно дойдет.

 

 

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

  Что говорить что подобный путь развития ЭКСТЕНСИВЕН. ;(

<{POST_SNAPBACK}>

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

[VladislavS 37]

киньте проект, плз, у меня что-то несколько другой код получается.

или лист программы, которую компилируете.

 

Вот проект.

TEST_ARM.RAR

[dxp 53]

Как я замечал в частных беседах об достоинствах и недостатках "С".

Больше всего отстаивают С перед ASM люди не умеющие писать на ASM.

Как я понимаю этим они просто оправдывают свою не компитентность.

Ой, не смешите! Что там уметь? Взять документацию на проц и сразу начать писать инструкции. Тут вообще никаких знаний обширных не требуется. Именно поэтому асм так популярен среди начинающих. Все электронщинки, имеющие дело с процессорами, прошли этот путь.

 

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

 

Т.ч. перефразируя Вашу мысль - на асме голимом пишут те, кто не знает С, и заявляя, что "только асм, С - для некомпетентных", они прикрывают собственную некомпетентность.

 

Ибо любому, кто писал на ASM просмотр ASM лиснинга С компилятора приводит в ужас.

Это, извините, совершенно не соответствует действительности! Даже комментировать не буду такое нелепое замечание.

 

 

Единственное оправдание написания программ на С - доступность для понимания программистами заказчика.

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

 

Потому, если планируется сопровождение передаваемой программы другими программистами, особенно если они не понимают ASM, то писать надо на С.

<{POST_SNAPBACK}>

Опять мимо. Писать надо на том, что более подходит. Для проектов на МК в целом С более подходит, нежели асм. Есть отдельные случаи, если оправдано, то эти фрагменты следует выполнить на ассемблере. Но не более. Именно об этом Вам и толкуют.

 

Напоследок, дабы у Вас не возникало предположений о компетенции оппонентов, сообщу о своем опыте. Я, как и большинство, железячников, начинал с асма. Были времена, когда писал программы чисто на ассеблере объемом по 3 и более тысячи строк чистого кода (а для сопровождаемости там приходилось комментарии втыкать в изрядном объеме, что увеличивало и объем исходников чуть-ли не в два раза, и работы добавляло - как известно, написание качественного комментария по сложности и трудоемкости соизмеримо с объемом работы по написанию собственно кода). Было это на легендарном MCS-51. Потом появился AVR, и я пересел на него, продолжая работать в том же духе - асм, асм, для облечения жизни - макросы, бо асм у оного МК для ручного писания заметно менее приятный, чем у 51-го.

 

И так бы и продолжал, наверное, еще долгое время асмить, свято веря, что иного пути просто нет. Но тут увидел, как один из корешей (из другой организации) сидит и колупает IAR C (версии 1.30 еще). Я, было, поднял его на смех, типа, грю, чего ты, Мишка, дурака валяешь, кто ж для таких мелких МК на С пишет? А он отвечает, что, типа, вот заодно и узнаем, что там получается. Стали мы вместе смотреть. И вижу я, имеющий уже изрядный опыт асмования, что код (в листинге), сгенеренный компилятором, почти такой же, как я бы и сам написал. И что компилятор просто делает огромное количество тупой работы, которую без него мне приходилось делать самому. Стал тогда уже самостоятельно ковыряться, а заодно и язык учить. Мне здорово повезло - рядом оказались люди, знающие язык и наставившие сразу на пусть истинный, благодаря чему сложилось сразу правильное понимание ключевых моментов языка и правильное отношение к нему как средству для решения задач.

 

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

 

Я и сегодня не брезгую ассемблером, где он действительно нужен и оправдан. Но таких случаев можно по пальцам пересчитать. Это либо ситуация, где надо задействовать конкретный аппаратные узлы процессора (относится по большей части к DSP), либо какие-то уж сильно платформеннозависимые вещи вроде переключателя контекста в RTOS. Обычный управляющий код, львиная доля которого и составляет программы для МК, прекрасно ложится на С/С++ и оверхед составляет, как уже говорили, 10-30 % (в худших случаях процентов 50). И проистекает не столько из-за плохой якобы кодогенерации, сколько из-за вещей вроде соглашений о вызове и прочих условностях, без которых никакой проект приличных размеров жить не может, безотносительно на каком языке он написан.

 

Что касается оппонента, которого Вы обвинили в некомпетентности, то от себя замечу, что и тут Вы оказались очень мимо кассы: этого человека я знаю давно заочно и не очень давно лично (живем в разных городах), у него очень приличный опыт работы с МК вообще и на ассемблере для них в частности. И прошел он примерно тот же типовой путь, который был описан выше. Можете не сомневаться, с квалификацией в том числе программиста на ассемблере у него все в порядке, и где надо, там пользуется. Но писать сегодня для МК - особенно такого как ARM, - ВСЕ на асме - это или мазохизм, или искусство ради искусства вроде того, как китайцы пишут на раскаленном солнцем бетоне иероглифы кисточкой, смоченной водой. Иероглифы быстро высыхают. Но там цель не написать, а писать чисто из любви к этому процессу.

[IgorKossak 0]

Возвращаясь к теме, вот на мой взгляд неплохой сайт для начинающих.

New Micros

Всё как по нотам расписано, но надо знать английский.

Кроме того, закачивать придётся немало.

Есть также кое-что от Macraigor Systems, тоже всё очень подробно.