AVR GCC&IAR

Hi Dima.

DO> ëÓÔÁÔÉ ×ÏÔ ËÌÀÞÉË, ×pÏÄÅ pÁÂÏÔÁÅÔ.

Dimmy.

Hello Dimmy.

DT> ðÏÈÏÖÁÑ ÏÐÅpÁÃÉÑ ÅÓÔØ × BP7, "Object browser", ÔÏÌØËÏ ÏÎÁ Åݣ ÐÏËÁÚÙ×ÁÅÔ DT> ÓÐÉÓÏË ×ÓÅÈ ×ÈÏÖÄÅÎÉÊ ÐpÏÇpÁÍÍÎÏÇÏ ÏÂßÅËÔÁ; ÐÅpÅÍÅÝÁÑÓØ ÐÏ ÓÐÉÓËÕ, DT> ÐÏÐÁÄÁÅÛØ ÎÁ ÏÐÅpÁÔÏpÙ, × ËÏÔÏpÙÈ ÉÓÐÏÌØÚÕÅÔÓÑ ÜÔÏÔ ÏÂßÅËÔ. ëÏÇÄÁ DT> ÐpÏÇpÁÍÍÕ ÐÉÛÅÛØ × spaghetti style, ÂÅÓÃÅÎÎÙÊ ÉÎÓÔpÕÍÅÎÔ. ;)

HÅ ÔÏÌØËÏ, ËÏÇÄÁ ÍÎÏÇÏ ÉÓÈÏÄÎÉËÏ×, ÔÏ ÏÞÅÎØ ×ÙpyÞÁÅÔ. õ ÍÅÎÑ "Find in files" ÎÁ ÈÏÔËÅÅ Ctrl-Q (ÍÏÖÅÔ ÏÎ É ÄÅÆÏÌÔÏ×ÙÊ), É ÐÏÌØÚyÀÓØ ÅÀ ÄÏ×ÏÌØÎÏ ÞÁÓÔÏ.

OR>> åÓÔØ ÐÏÎÑÔÉÅ "ÓÅËÃÉÑ", ËÏÔÏpÏÅ ÏÐÉÓÙ×ÁÅÔÓÑ pÅÇÅËÓÐÁÍÉ, DT> ëÓÔÁÔÉ, ÐÏÄÓËÁÖÉ, ÞÔÏ ÐÏ ÜÔÉÍ pÅÇÅËÓÐÁÍ ÐÏÞÉÔÁÔØ ÍÏÖÎÏ. ïÓÏÂÅÎÎÏ DT> ÉÎÔÅpÅÓÕÅÔ, ËÁË Ó ÉÈ ÐÏÍÏÝØÀ ÏÐÉÓÙ×ÁÔØ pÁÚÂÏp ×Ù×ÏÄÁ ËÏÍÐÉÌÑÔÏpÁ.

OR>> á×ÔÏÄÏÐÏÌÎÅÎÉÑ ÎÅÔ.

DT> íÏÖÅÔ, Ó ÐÏÍÏÝØÀ ÍÁËpÏÓÏ× ÍÏÖÎÏ?

DT> :) äÁ, ×ÅÓØÍÁ É ×ÅÓØÍÁ ×ËÕÓÎÁÑ ÓÏÆÔÉÎÁ! ïÞÅÎØ ÁËËÕpÁÔÎÏ É ÉÚÑÝÎÏ DT> ÓÄÅÌÁÎÁ, ×ÓÅÍ ÂÙ ÔÁË. :) HÁÐpÉÍÅp, ÓÐÏÓÏ ÐÅpÅÎÁÚÎÁÞÅÎÉÑ ËÌÁ×ÉÛ.

Alexey

AM>> Hе встречал разных компиляторов для одной платформы, чтобы у них AM>> были разные размеры одних и тех же типов,

GS>> Это не значит, что таких компиляторов не было. AM> Приведи примеры конкретных компиляторов.

GS> Сам поищи, точно были.

"Пойди туда - не знаю куда, принеси то - не знаю что". Впрочем, другого ответа от тебя и не следовало ожидать.

AM> Сишные программы пишутся сами по себе? А я думал стиль определяется AM> программистом.

GS> Программисты пишут сами по себе? А я думал, берут пример GS> с других программистов ;)

А я думал, придерживаются выбранного стиля, благо их и хороших много.

GS>> А человек, пытающийся понять сишную программу, не должен GS>> как минимум знать си? ;) M> Да, но один Си, а не 10 ассемблеров.

GS> Hет "одного Си", есть куча разных реализаций. И это не противоречит GS> стандарту этого языка. Классический "ярко выраженный" пример gnu-тый GS> компилятор Си, который существенно отличается от классического, но GS> несмотря на это, им активно пользуются, так что необходимость программы GS> читать и модифицировать вполне может возникнуть...

Почти у всех компиляторов, которые я встречал есть опция компиляции в режиме ANSI C. Для желающих.

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

AM> Мне как-то больше приходится писать свои.

GS> Понимаю. Hо не поверю, что ты _сразу_ начал писать свои программы GS> в грамотном стиле. Hаверняка, как и любой из нас, поначалу "прошёлся GS> по граблям" ;)

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

GS>> Hаиболее типичное GS>> занятие такого рода - ковыряние в исходниках Linux. AM> Я не ковыряюсь.

GS> Достаточно распространено мнение, что при серьёзной работе под Linux GS> без такого ковыряния обойтись почти невозможно...

Я не работаю под Linux. Он не ставится по 8 и 16 битные контроллеры. Работал бы на 32-битных, возможно и смотрел бы туда.

GS>> Ты считаешь, что все они выдержаны в "правильном" стиле? AM> Я их вообще в глаза не видел.

GS> Посмотри. Может поймёшь, о чём шла речь.

Зачем? Я не собираюсь рассуждать о том, что можно написать плохо. Я в этом и не сомневаюсь, применитьно к любому языку можно написать плохо.

AM> Зачем они мне в embedded?

GS> Если мне придётся делать достаточно сложную систему на базе встраиваемого GS> процессора, скорее всего я пойду по пути адаптации одного из "крошечных" GS> линуковских ядер к одному из "встраиваемых" процессоров семейства x86. GS> Это, IMHO, существенно ускорит работу. GS> Какие предложишь альтернативы?

Если бы да кабы. Должны быть поставлены исходные условия задачи. Я, возможно, для достаточно сложной системы (впрочем я считаю, что текущие мои разработки относятся к доcтаточно сложным системам по функциональности и объему кода) возьму uCOS-II

AM> Впрочем, я приведу контр пример, uCOS-II. Посмотри на сайте uCOS,

GS> Увы, у меня по-прежнему очень ограничен доступ к инету.

Могу лишь посочувствовать.

AM> под сколько процессоров портирована ОС, исходники ОС при этом не AM> меняются, то есть машинонезависимость соблюдается в полной мере.

GS> Исходники открыты?

Открыты, для образовательных целей. Официально приобретаются вместе с книгой по uCOS-II (стоимость где-то около $50). Неофициально можно найти во многих местах по и-нету.

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

GS> Да. Hо программисты существуют не на необитаемом острове и вырабатывают GS> свой стиль с учётом работы других программистов. По жизни.

Это отностися к любому языку.

AM> и может быть плох как на асм, так и на Си.

GS> Да, бесспорно.

Тогда и не надо приводить эти аргументы против Си. Не о том речь.

AM> Я реализую свои задачи, пользуясь определенным стилем, AM> какое мне дело до того, что кто-то делает по другому?

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

Я отношу себя к нормальным водителям. Это ты любишь цирковые "трюки".

AM> Это определяется опять же стилем,

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

Не философствуй, приведи примеры.

AM> Си не обязывает использовать какие-то трюки.

GS> Он их _поощряет_.

Чушь. Приведи пример трюков. Только не надо опять сдвигать флоат.

AM> Для переменной цикла действительно часто i и j.

GS> Это уже уменьшение "самодокументированности" программы. Поскольку GS> переменная цикла тоже несёт вполне определённый _смысл_.

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

AM> Для других переменных - свои ясно читаемые имена. Hо это опять не AM> имеет отношения к языку Си, а зависит от программиста.

GS> Hет. Конструкции этого языка читабельны при компактной GS> записи, попытка "развернуть", к примеру, конструкцию GS> for (инициализация; проверка_завершения; изменения) тело_цикла, GS> используя "самодокументирующие" имена, приведёт к тому, GS> что отдельная команда "раздуется" и потеряет наглядность.

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

GS>> Весьма существенная часть программистов так любит экономить на GS>> нажатии кнопок ;) AM> Давно пора приучиться говорить только за себя.

GS> А по существу что скажешь? ;-)

По существу я собираюсь отвечать только за себя, а не за среднестатического программиста. Разговариваешь со мной? Вот и говори со мной, а не с "существенной частью программистов". По существу твоего утверждения об огромном овержеде Си что можешь сказать?

GS>> Ибо строгое следование хорошему стилю программирования GS>> требует дополнительных усилий от программиста (как правило GS>> ленивого).

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

GS> Hе идиализируй "среднестатистического программиста". Он обычный человек, GS> такой-же ленивый, склонный к ошибкам и "зевкам", как любой другой человек.

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

AM> Я могу также сказать, что среднестатистический программист AM> на асм делает куда более нечитаемый код, по сравнению с AM> аналогичным программистом на Си

GS> Да. Hо при программировании на ассемблере действует очень жёсткий GS> "естественный отбор",

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

GS> "ламерские" программы не создают видимость GS> нормальной работы. Программист, который создаёт чётко работающие GS> ассемблерные программы, как правило, научился на собственном опыте GS> придерживаться хорошего стиля. Это даёт ему возможность отлаживать GS> и сопровождать программу. Что касается "хакеров", которые из принципа GS> лепят невразумительный код - они способны проделывать это на _любом_ GS> языке программирования.

Ну что тебе сказать. Ты ловко умеешь менять тему разговора в сторону, где можно налить много "воды" и поразводить руками.

AM>> памяти, но и килобайт, и мегабайт. А в эхотажных будет то, что я AM>> привел. GS>> В эхотажных я наблюдал разницу в разы на процах i51 и PIC...

AM> Каким компиялтором для х51 при этом пользовался?

GS> Понятия не имею, я не пишу на C для 51-го семейства и не интересовался GS> такими подробностями у создателей софта, который удавалось "ужать" GS> на порядок. И не думаю, что выбор более подходящего компилятора привёл GS> бы к чуду. Верю в улучшение на 10%, на 30%, но никак не на 90%...

Так может нужно не полагаться на веру, а убедиться самому. Хотя бы в своей правоте. Чтобы потом хотя бы приводить в доказательства конкретный код, созданный компилятором 1000% оверхед. А то руками водить в воздухе у всех получается хорошо.

GS>> Для человека, который знает C заметно лучше, чем ассемблер - да. GS>> Hо если привлечь специалиста по ассемблеру и грамотно GS>> сформулировать задачу - будет гораздо эффективнее... AM> Hа 15%

GS> Или в 15 раз! ;)

Только хи-хи да ха-ха. Пример приведи. Код на Си, листинг после компилятора, альтернативную реализацию на ассмеблере, в 15 раз меньшую.

AM>>> на асме возможно чуть более оптимально, но и то не везде. GS>>> Иногда можно написать эффективнее на порядок. Hа ассемблере. AM>> Эти иногда - не более 1% кода. GS>> А иногда - 99% ;) AM> Такого не бывает.

GS> В эхотажных приложениях - очень и очень часто.

Приведи пример конкретного кода. Здесь и сейчас.

GS>>> И то, постоянно выдумываются хитрые трюки... AM>> Что такое трюки? GS>> Побочные и нетривиальные действия.

AM> Hапример?

GS> k[j++] = x = (++i Кратко, но абсолютно невразумительно.

Hello George,

GS>> исполнением команд программы (в процессорных тактах). Удобно такая GS>> задачка подходит для сишного программиста?

AM> Hе удобно, и что из этого вытекает? Что, что для PICов с 512 слов AM> памяти вполне можно писать на асме.

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

Ну и что. Если у тебя таких задач большинство, то ассемблер тебе в руки и вперед.

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

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

И на "о" - бывает, и на "ё" тоже бывает, и что с того?

AM> это кстати сколько, по твоему?

GS> Это больше 4 месяцев работы классного программиста. GS> Плюс-минус пол-лаптя ;)

Ты в объеме кода скажи.

AM> У меня последние проекты на MB90F543 где-то под 100кбайт BIN AM> кода. Таблиц практически нет.

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

в общем GS - самый умный, знает больше и лучше всех, ему бы еще интернет...

AM>> Реальные задачи состоят из набора контрукций языка. GS>> Угу. Что-то вроде "Hастоящие программисты пишут только на GS>> Фортране. Даже если они пользуются Паскалем или Си" ;-) AM> Я что-то не так сказал?

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

Задачи управления решаются конструкциями Си весьма эффективно. Для uC наиболее присущи задачи именно этого класса. Задачи ЦОС более эффективно будут решаться на DSP с использование ассемблера, и то управляющая надстройка может быть написана на Си. Классов задач не так много, как ты хочешь думать.

AM> Тогда как решаются задачи по твоему?

GS> Ты знаешь, по разному! Иногда грамотно, иногда не очень. Иногда вообще GS> не решаются. Это от множества факторов зависит, "единственно правильного" GS> пути не существует. Hо есть много полезных "дорожных указателей" ;)

Налево пойдешь...Направо пойдешь....Прямо пойдешь.... В общем опять в итоге никакого ответа, умеем лишь руками водить.

GS>> "высокоуровневые" языки, позволяющие создавать "подходящие" GS>> конструкции, но это выливается в громоздкость реализации... AM> Все это треп,

GS> Hет.

GS> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ... GS> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

Не путай алгоритм для решения задачи и способ его реализации. Ты описываешь уменьшение ресурсов, достигнутое за счет применения другого подхода, другого алгоритма. Я же пытаюсь обсуждать один и тот же алгоритм, реализованный на асм vs Си, утвеждая что оверхед последнего не более 15-30%

AM> Оптимален ли это код?

GS> Оптимально ли наклонить чайник, чтобы вылить из него воду? Видимо да. GS> Hо если это делается только для того, чтобы привести задачу к уже решённой, GS> когда в чайнике нет воды, значит эти действия избыточны, а то и вредны!

Все философствуем...

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

GS> Именно.

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

AM> который мы не знаем. Философствование вместо реальных дел.

GS> Ты в институте учился? И преподавателям на вопросы по предмету тоже пытался GS> "впаривать", что нечего философствовать, а надо делом заниматься? ;-)

Правильно, предоставь доказательства. Реальные листинги компиляторов и свой вариант на ассемблере.

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

AM> Как всегда, как пришло время реально подтвердить свои высказывания - AM> прыг-скок в кусты.

GS> Гут, ты допрыгался! ;) Hапиши на сях ядро стандартной (16-ти битной) GS> форт-системы. Дополнительные условия - все пользовательские данные GS> (словарь, стеки) должны быть машинонезависимы. Для простоты и GS> универсальности ввод-вывод сделать через COM-порт. Hачальную инициализацию GS> "железа" можно не делать, чтобы не загромождать программу не имеющим GS> отношения к делу алгоритмом.

Знаешь, у меня нет времени для реализации форт машины, тем более я не очень хорошо предствалсяю как она работает.

GS> А у меня есть похожий вариантик для процессоров семейства x86 (чтобы GS> работало на встраиваемых 80186/188 и выше). Адаптировать под эти условия GS> можно за день. GS> Поглядим, какой размер кода у тебя получится...

Но если ты найдешь в и-нете исходник на Си и дашь ссылку, я ее откомпилирую. Но только не под PC, а под любой uC из x51, AVR, MB90.

AM>> которые тебе надо, чтобы это продемонстрировать. GS>> Я беру просто _реальные_ условия, в которых хорошо видны GS>> отличия в использовании разных инструментов программирования. AM> Да, PIC с 512 слов и без таймеров.

GS> 80186/188, 128 килобайт "навесной" памяти, таймеры, UART...

GS>> в общем случае далеко не так... AM> Я выберу наиболее подходящий, впрочем они все более или менее похожи.

GS> Я _максимально_ облегчил тебе задачу, для x86 выбор довольно широк ;)

Я не собираюсь тратить время на изучение форта, написания и отладки его ядра на Си. Просто потому, что я не в эхе работаю, а на работе.

GS> Hу как, сделаешь? "Алгоритм" можно взять в книге "Язык Форт и его GS> реализации" Баранова и Hоздрунова.

GS> Задача заведомо имеет смысл, в отличие от абстрактных примеров.

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

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

GS> "Зуб даёшь", что это справедливо для _любого_ сишного компилятора?

Во-первых для любого не надо, потому что многие uC имеют нормальные инструкции работы по указателю со смещением и компилированный стек теряет смысл. Но для тех, с которыми я работал - Keil 51, PL/M 51, IAR Z80 - с этим проблем не возникало. Для Z80, впрочем я не помню, создавался ли именно компилированный стек, или переменные просто раскладывались в ОЗУ.

GS>> Да ещё и при GS>> любимом сишниками использовании "побочных эффектов" GS>> от выполнения операций?..

AM> Сто раз проверено, ничего не глючит. Алгоритмы распределения вполне AM> прозрачны.

GS> Допустим. Hо аналог на ассемблере в ряде случаев всё-равно можно GS> сделать эффективнее, так как часть переменных будут передаваться GS> не в "компилированном стеке", а в регистрах.

Не вижу смысл обсуждать этот вопрос безотностильно конкртеного компилятора и ядра. Тем не менее, вКейл 51 передается параметры функции в регистрах и раскладывает локальные переменные по регистрам, если это возможно.

GS> А если помнить об этом и делать функции с учётом таких особенностей GS> работы - опять появляется резерв оптимизации...

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

AM> Принципиальная возможность всегда есть, только голова начинает

AM> работать в том числе и линкером, проверяя области возможных AM> перекрытий.

GS> Да. И иногда в голову при этом приходят очень интересные идеи GS> по оптимизации кода ;-)

Что-то ты никак свои идеи здесь описать не можешь. Идей по оптимизации на самом деле не так и много.

Георгий - человеку так не любящему что его "оскорбляют" (действительно гадким местечковым имечком - но авторы этого "обращения" тоже не в Швеции живут), не пристало так выражаться. Да, мне уже сообщили что я был не прав, но только частично (серия V здесь может рассматриваться как один процессор, а ты говорил о многих).

Си ты таки не знаешь, паскаль говорят тоже не фонтан. Про ДЕК ты гонишь полную туфту, слышав только звон. Профессионалы работали только в ДЕКовской системе команд, только под специально адаптированными к ним дековскими системами. Ни CP/M ни MS-DOS на них никогда не работали. Про Рэйнобоу ты похоже даже и не слышал (а в отличии от практически чисто японских компов на V* они имели довольно широкое хождение). И она действительно была двухсистемной.

Аркадий

Hello Maxim.

GS>>>> ÚÁÍÅÞÁÔÅÌØÎÙÊ, ËÁË ÔÙ ÒÁÓÓËÁÚÙ×ÁÅÛØ?

AM>>> ÷ÉÄÉÍÏ Õ ÎÉÈ ÂÙÌÁ ÔÏÞËÁ ÚÒÅÎÉÑ ÔÁËÁÑ ÖÅ ËÁË Õ ÔÅÂÑ,

MP> ðÅÒÅÈÏÄ ÏÓÕÝÅÓÔ×ÌÑÌÓÑ × 1994-1995. ðÅÒ×ÕÀ ÐÒÏÇÒÁÍÍÕ ÎÁÐÉÓÁÌ ÎÅËÔÏ ïÌÅÇ MP> ôÏÇÉÄÎÙÊ. HÅ ÚÎÁÀ ÂÙÌÁ ÌÉ Õ ÎÅÇÏ ÔÁËÁÑ ÔÏÞËÁ ÚÒÅÎÉÑ ÉÌÉ ÎÅ ÔÁËÁÑ - ÎÏ ÏÎ MP> ÎÁÐÉÓÁÌ ÅÅ ÉÍÅÎÎÏ ÎÁ ÁÓÍÅ. ðÒÉ ÐÅÒÅËÌÁÄÙ×ÁÎÉÉ ÐÒÏÇÒÁÍÍÙ òÕÓØ ÎÁ x51 ÄÁÖÅ MP> ÍÙÓÌÅÊ Ï ÞÅÍ-ÔÏ ËÒÏÍÅ áóíá ÎÅÂÙÌÏ!

MP> é ÅÝÅ áÎÄÉ. áÏÎ - ËÌÁÓÓÉÞÅÓËÁÑ ÐÒÏÇÒÁÍÍÁ ËÏÔÏÒÁÑ ÎÅ ÍÏÖÅÔ ÂÙÔØ ÎÁÐÉÓÁÎÁ ÎÁ MP> Ñ×Õ.

MP> ðÒÏÃÅÓÓÏÒ Ó ÐÒÏÉÚ×ÏÄÉÔÌØÎÏÓÔØÀ ÍÅÎÅÅ 1mips, ÖÅÓÔËÉÅ ÏÇÒÁÎÉÞÅÎÉÑ ÐÏ MP> ÐÁÍÑÔÉ É ÏÂÅÍÕ ÏÚÕ, 10-ËÉ ÒÅÁÌÔÁÊÍÏ×ÙÈ ÐÒÏÃÅÄÕÒ × ÕÐÏÒÅ MP> ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ. é ÞÔÏ ÓÁÍÏÅ ÕÄÉ×ÉÔÅÌØÎÏÅ - ÔÁÍ ÍÅÎÅÅ 10-ÔÉ ÌÏËÁÌØÎÙÈ MP> ÐÅÒÅÍÅÎÎÙÈ × ÏÚÕ (Ô.Å. ÐÅÒÅÍÅÎÎÙÈ ÒÁÚÎÙÍÉ ÐÒÏÃÅÄÕÒÁÍÉ ÉÓÐÏÌØÚÕÅÍÙÈ ÄÌÑ MP> ÒÁÚÎÙÈ ÃÅÌÅÊ), ×ÓÅ ÏÓÔÁÌØÎÙÅ ÐÅÒÅÍÅÎÎÙÅ ÇÌÏÂÁÌØÎÙ.

Sat, 24 Jan 2004 12:55:42 +0300 Alexey Boyko wrote to Dima Orlov:

DO>> ÷ ÓÔÁÎÄÁÒÔÅ ó ÉÈ ÎÅÔ.

AB> ñ × ËÕÒÓÅ. åÝÅ × gcc ÍÏÖÎÏ ÐÉÓÁÔØ ÔÁË:

AB> void foo(int x) AB> { AB> int y[x]; // <--- AB> ... AB> }

AB> á ÅÝÅ ÔÁË:

AB> x = ({ int y; for(y=0; y<10; y++); y} );

Hello Dimmy.

AB>> x = ({ int y; for(y=0; y<10; y++); y} );

DT> éÚ ÍÁÔÌÁÂÏ×ÓËÏÇÏ í-ÑÚÙËÁ ÍÏÖÎÏ ÂÙÌÏ ÂÙ ÉÄÅÉ ×ÚÑÔØ. HÁÐpÉÍÅp, ÁÇpÅÇÁÔ DT> × ÌÅ×ÏÊ ÞÁÓÔÉ ÏÐÅpÁÔÏpÁ ÐpÉÓ×ÁÉ×ÁÎÉÑ:

DT> [y1,y2,y3] = func (x1, x2, x3)

Alexey

Hello Harry.

AB>> x = ({ int y; for(y=0; y<10; y++); y} ); HZ> á ÜÔÏ ÞÔÏ ÔÁËÏÅ?

Statements and Declarations in Expressions ==========================================

A compound statement enclosed in parentheses may appear as an expression in GNU C. This allows you to use loops, switches, and local variables within an expression.

Recall that a compound statement is a sequence of statements surrounded by braces; in this construct, parentheses go around the braces. For example:

({ int y = foo (); int z; if (y > 0) z = y; else z = - y; z; })

is a valid (though slightly more complex than necessary) expression for the absolute value of `foo ()'.

The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. (If you use some other kind of statement last within the braces, the construct has type `void', and thus effectively no value.)

This feature is especially useful in making macro definitions "safe" (so that they evaluate each operand exactly once). For example, the "maximum" function is commonly defined as a macro in standard C as follows:

#define max(a,b) ((a) > (b) ? (a) : (b))

But this definition computes either A or B twice, with bad results if the operand has side effects. In GNU C, if you know the type of the operands (here let's assume `int'), you can define the macro safely as follows:

#define maxint(a,b) \ ({int _a = (a), _b = (b); _a > _b ? _a : _b; })

Embedded statements are not allowed in constant expressions, such as the value of an enumeration constant, the width of a bit-field, or the initial value of a static variable.

If you don't know the type of the operand, you can still do this, but you must use `typeof' (*note Typeof::).

Statement expressions are not supported fully in G++, and their fate there is unclear. (It is possible that they will become fully supported at some point, or that they will be deprecated, or that the bugs that are present will continue to exist indefinitely.) Presently, statement expressions do not work well as default arguments.

In addition, there are semantic issues with statement-expressions in C++. If you try to use statement-expressions instead of inline functions in C++, you may be surprised at the way object destruction is handled. For example:

#define foo(a) ({int b = (a); b + 3; })

does not work the same way as:

inline int foo(int a) { int b = a; return b + 3; }

In particular, if the expression passed into `foo' involves the creation of temporaries, the destructors for those temporaries will be run earlier in the case of the macro than in the case of the function.

These considerations mean that it is probably a bad idea to use statement-expressions of this form in header files that are designed to work with C++. (Note that some versions of the GNU C Library contained header files using statement-expression that lead to precisely this bug.)

Alexey

Hi Maxim !

MP> é Õ ÍÅÎÑ ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÎÅÔ ×ÒÅÍÅÎÉ ÚÎÁÔØ É ÕÞÉÔØ ÓÉ - ÏÎ ÐÒÏÓÔÏ ÎÅ MP> ÐÏÍÏÖÅÔ ÍÎÅ ÎÉ × ÞÅÍ, ÔÏÌØËÏ ÚÁÓÒÅÔ ÍÏÚÇ ÌÉÛÎÅÊ ÉÎÆÏÒÍÁÃÉÅÊ. íÁËÓÉÍ, ÍÎÅ ÔÅÂÑ ÖÁÌØ. ëÁË ×ÐÒÏÞÅÍ É ÓÅÂÑ, ÔÁË ËÁË Ñ ÎÁÞÁÌ ÐÒÉÍÅÎÑÔØ C ÌÅÔ ÎÅ ÛÅÓÔØ ÐÏÚÖÅ, ÞÅÍ ÍÏÇ ÜÔÏ ÓÄÅÌÁÔØ. ÷ ÔÏÍ ÞÉÓÌÅ É ÉÚ-ÚÁ ÐÏÄÏÂÎÙÈ ÔÅÂÅ. ïÞÅÎØ ÂÏÌØÎÏ ÓÍÏÔÒÅÔØ ÎÁ Ó×ÏÉ ÓÔÁÒÙÅ ×ÙÌÉÚÁÎÎÙÅ ÁÓÍÏ×ÓËÉÅ ÐÒÏÇÒÁÍÍÙ É ×ÓÐÏÍÉÎÁÔØ, ÓËÏÌØËÏ ×ÒÅÍÅÎÉ ÔÁÍ ÂÙÌÏ ÚÁÒÙÔÏ. ôÏ, ÞÔÏ ÔÙ ÐÉÛÅÛØ- ÐÒÏÓÔÏ ×ÒÅÄÎÏ ÞÉÔÁÔØ. åÓÌÉ ÈÏÔØ ÏÄÉÎ ÉÚ ÞÉÔÁÔÅÌÅÊ ÂÌÁÇÏÄÁÒÑ Ô×ÏÉÍ ÐÉÓØÍÁÍ ÏÔÓÒÏÞÉÔ Ó×ÏÊ ÐÅÒÅÈÏÄ Ó ÁÓÍÁ ÎÁ ÓÉ- ÚÎÁÞÉÔ, Õ ÔÅÂÑ ÓÅÇÏÄÎÑ ÒÁÄÏÓÔØ.

MP> ñ ÎÅ ÍÏÇÕ ÕÓËÏÒÉÔØ ÎÁÐÉÓÁÎÉÅ ÜÔÏÇÏ ËÏÄÁ ÉÓÐÏÌØÚÕÑ ÓÉ, ÐÏÓËÏÌØËÕ ÅÓÌÉ MP> ÐÒÏà ×ÙÂÒÁÌ ÎÅ Ñ, ÜÔÏ Á×ÔÏÍÁÔÉÞÅÓËÉ ÐÏÄÒÁÚÕÍÅ×ÁÅÔ, ÞÔÏ 90% ÐÒÏÜËÔÁ - MP> ÒÅ×ÅÒÓÉÎÇ. üÔÏ ËÏÒÒÅËÃÉÑ ÞÕÖÉÈ ÄÉÚÁÓÓÅÍÂÌÉÒÏ×ÁÎÎÙÈ ÐÒÏÇÒÁÍÍ? ðÒÉ ÞÅÍ ÚÄÅÓØ ÎÁÐÉÓÁÎÉÅ Ó×ÏÉÈ? MP> á ÔÁÍ ÕÖÅ ÎÁÄÏ ÚÎÁÔØ ÎÅ ÑÚÙË, Á ËÏÎÓÔÒÕËÃÉÉ ÐÏÒÏÖÄÁÅÍÙÅ MP> ËÏÍÐÉÌÑÔÏÒÁÍÉ, ÔÁË ÞÔÏ ÂÕÄØ ÓÐÏË - ×ÁÛÁ ÓÉÛÎÁÑ ËÕÈÎÑ ÍÎÅ ÐÒÅËÒÁÓÎÏ MP> ×ÉÄÎÁ ÔÁË ÓËÁÚÁÔØ ÉÚÎÕÔÒÉ. ðÏÜÔÏÍÕ É ÓÍÅÛÎÏ ÞÉÔÁÔØ ÐÒÏ Ï×ÅÒÈÅÄ=15% × MP> MCS51, ×ÐÒÏÞÅÍ "ÓÞÁÓÔØÅ × ÎÅ×ÅÄÅÎØÉ" É ÐÏÔÏÍÕ ×Ù ÉÍÅÅÔÅ ÐÏÌÎÏÅ ÐÒÁ×Ï MP> ÄÕÍÁÔØ, ÞÔÏ ÜÔÏ ÐÒÁ×ÄÁ. ;) åÓÌÉ ÖÅ ÐÒÏà ×ÙÂÒÁÌ Ñ - Ñ Á×ÔÏÍÁÔÉÞÅÓËÉ MP> ÌÕÞÛÅ É ÂÙÓÔÒÅÅ ÎÁÐÉÛÕ ÎÁ ÁÓÍÅ! þÅÍ Ñ ÎÁ ÓÉ? äÁ×ÁÊ ÞÔÏ-ÌÉÂÏ ÉÎÔÅÒÁËÔÉ×ÎÏÅ ÓËÁÖÅÍ ÄÌÑ ÐÕÌØÔÁ Ó ÍÎÏÇÏÓÔÒÏÞÎÙÍ ÄÉÓÐÌÅÅÍ É ÐÁÒÏÊ ÄÅÓÑÔËÏ× ÍÎÏÇÏÆÕÎËÃÉÏÎÁÌØÎÙÈ ËÎÏÐÏË? á ÐÏÔÏÍ Ñ ÐÒÅÄÌÏÖÕ ÐÏÍÅÎÑÔØ ÆÏÒÍÁÔ ×Ù×ÏÄÁ ÉÌÉ ÌÏÇÉËÕ ÒÅÁËÃÉÉ ÎÁ ËÎÏÐËÉ?

WBRgrds Ruslan

Hi Maxim !

LB>> á ËÁË ÔÙ × ÜÔÉÈ ÍÁËÒÏÓÁÈ ÐÒÏ×ÅÒÑÛØ/ÕÓÔÁÎÁ×ÌÉ×ÁÅÛØ ÔÅËÕÝÉÊ ÂÁÎË LB>> ÐÁÍÑÔÉ? MP> á ×ÏÔ ÜÔÏ ÕÖÅ ÓÔÉÌØ. HÉËÁË - ÉÂÏ ×ÓÅ ÏÄÉÎÏÞÎÙÅ ÐÅÒÅÍÅÎÎÙÅ ÎÁÈÏÄÑÔÓÑ × MP> 0 ÂÁÎËÅ Á ×ÓÅ ÍÁÓÓÉ×Ù ÎÁÈÏÄÑÔÓÑ × ÏÓÔÁÌØÎÙÈ É ÁÄÒÅÓÕÀÔÓÑ ÞÅÔËÏ MP> ÓÔÒÕËÔÕÒÉÒÏ×ÁÎÎÙÍÉ ËÕÓËÁÍÉ ÞÅÒÅÚ FSR. åÓÌÉ ÔÁË ÎÅ ÐÏÌÕÞÁÅÔÓÑ - MP> ËÏÎÔÒÏÌÌÅÒ ÎÅ ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ ÚÁÄÁÞÅ!

WBRgrds Ruslan

Hi Alexey.

AB> ðÏÔÏÍ ÓÔÁÌ ÐÉÓÁÔØ ÎÁ óÉ É pÁÂÏÔÁÔØ ÐÏÄ ìÉÎÕËÓ - ÎÉÞÅÇÏ ÐÏÄÏÂÎÏÇÏ, AB> ÎÉËÁËÉÈ ÏÛÉÂÏË pÁÚÌÉÞÅÎÉÅ pÅÇÉÓÔpÁ ÎÅ ÐpÏ×ÏÃÉpÕÅÔ.

Dimmy.

Hi Andy !

AM> óÌÅÄÕÀÝÉÊ ÛÁÇ - ÏÓ×ÏÅÎÉÅ RTOS :) ôÏÖÅ ÍÎÏÇÏ ÞÅÇÏ ÏÂÌÅÇÞÁÅÔ. á Ó ËÁËÏÇÏ ÕÒÏ×ÎÑ ÕÖÅ ÉÍÅÅÔ ÓÍÙÓÌ ÓÍÏÔÒÅÔØ ÎÁ RTOS? ëÁËÏ×Ù ËÒÉÔÅÒÉÉ ÐÏÌÅÚÎÏÓÔÉ? óËÁÖÅÍ, ËÏÌÉÞÅÓÔ×Ï ÐÒÏÃÅÓÓÏ× ÂÏÌÅÅ Ä×ÕÈ, ÒÁÚÍÅÒ ËÁÖÄÏÊ ÉÚ ÚÁÄÁÞ ÂÏÌÅÅ Ä×ÕÈ ÜËÒÁÎÏ×, ÚÁÎÑÔÏÓÔØ ÐÒÏÃÅÓÓÏÒÁ ÎÅ ÂÏÌÅÅ 50%....

WBRgrds Ruslan

Hi George !

LB>> ðÒÉ×ÅÄÉ ÄÌÑ ÐÒÉÍÅÒÁ ÎÅÓËÏÌØËÏ Ó×ÏÉÈ ÍÁËÒÏÓÏ× ÄÌÑ PIC, ËÏÔÏÒÙÅ LB>> ÕÍÅÀÔ ÜÔÏ ÄÅÌÁÔØ.

GS> ÷ PIC ×ӣ 8-ÍÉ ÂÉÔÎÏÅ, ÐÒÏ×ÅÒÑÔØ ÎÅÞÅÇÏ ;) GS> ÷ÙÌÅÚ ÚÁ 8-ÍÉ ÂÉÔÎÕÀ ×ÅÌÉÞÉÎÕ - ÐÏÌÕÞÉÌ ÓÏÏÂÝÅÎÉÅ Ï ÏÛÉÂËÅ GS> ÏÔ ËÏÍÐÉÌÑÔÏÒÁ... äÁ, ÓÞÁÚ. á ÍÎÏÇÏÂÁÊÔÎÙÅ ËÏÎÓÔÁÎÔÙ ÔÙ ÎÅ ÐÒÉÍÅÎÑÌ? ñ ÍÎÏÇÏ ËÏÇÄÁ ÔÁËÉÅ 4-ÂÁÊÔÎÙÅ ËÏÎÓÔÁÎÔÙ × ×ÙÞÉÓÌÅÎÉÑÈ Ó ÐÌÁ×ÁÀÝÅÊ ÔÏÞËÏÊ ÉÓÐÏÌØÚÏ×ÁÌ. ñÓÎÏ, ÐÏ ÂÁÊÔÉËÁÍ ÒÁÓÓÏ×Ù×ÁÔØ ÒÕËÁÍÉ ÌÅÎÉ×Ï, ÍÁËÒÏÓ ÂÙÌ. É ÎÁ ÐÅÒÅÓÙÌËÉ ÍÎÏÇÏÂÁÊÔÏ×ÙÈ ÐÅÒÅÍÅÎÎÙÈ ÍÁËÒÏÓÙ ×ÏÄÉÌÉÓØ. ÷ÏÔ ÔÏÌØËÏ ÎÅ ÓÍÏÇ Ñ ÚÁÓÔÁ×ÉÔØ mpasm ÐÅÒÅ×ÏÄÉÔØ ÞÉÓÌÁ ÔÉÐÁ "1.32" × 4-ÂÁÊÔÏ×ÙÊ hex. ðÒÉÈÏÄÉÌÏÓØ ÒÕÞËÁÍÉ ÔÁËÏÊ hex ×ÐÉÓÙ×ÁÔØ × define. á ×ÏÔ × ÓÑÈ ÔÁÂÌÉÞËÉ ÔÉÐÁ double ÏÞÅÎØ ÚÄÏÒÏ×Ï ÓÍÏÔÒÑÔØÓÑ :)

WBRgrds Ruslan

Hi George.

IT> HÏ ÓÔÏÉÔ ÌÉ ÐpÉÂÅÇÁÔØ Ë ÐÏÌÕÍÅpÁÍ? éÌÉ ÕÖ ÐÏÌÎÁÑ ÎÅ×ÏÚÍÏÖÎÏÓÔØ IT> ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÈÁËÅpÓËÉÈ ÐpÉÅÍÏ×,

GS> Pascal.

HÅ ðÁÓËÁÌØ, Á áÄÁ. ÷ ÐpÉÎÃÉÐÅ ÍÏÖÎÏ ×ӣ, ÎÏ ÜÔÏ ×ӣ ÂÕÄÅÔ ÐÏÎÑÔÎÏ É ÏÄÎÏÚÎÁÞÎÏ.

IT> ÉÌÉ ÐÏÌÎÁÑ Ó×ÏÂÏÄÁ + ÓpÅÄÓÔ×Á ÏÔÌÁÄËÉ, ÐÏÚ×ÏÌÑÀÝÉÅ ÜÆÆÅËÔÉ×ÎÏ IT> ÏÔÌÁ×ÌÉ×ÁÔØ ÎÅËÏppÅËÔÎÏÓÔÉ × ÁÌÇÏpÉÔÍÁÈ.

Dimmy.

Hello George.

GS> ðÁÓËÁÌÅ×ÓËÉÊ integer ÜÔÏ ÎÅ ÓÉÛÎÙÊ int, ÏÎ Ä×ÕÈÂÁÊÔÏ×ÙÊ.

Alexey

Hello Oleksandr.

OR> ëÓÔÁÔÉ × ÔÏÍ ÖÅ ÕÖÅ 4-ÌÅÔÎÅÍ ÓÔÁÎÄÁÒÔÅ ó (ÎÅ C++) ÅÓÔØ É OR> inline-ÆÕÎËÃÉÉ, ÞÔÏ ÂÏÌÅÅ ÐÏÌÅÚÎÏ ÄÌÑ ÍÅÌËÉÈ ÐÒÉÍÅÎÅÎÉÊ.

OR> ôÁË ÞÔÏ ÜÔÉ ×ÅÝÉ ÕÖÅ _ÄÏÌÖÎÙ_ÂÙ_ ÐÏÄÄÅÒÖÉ×ÁÔØ É ÄÒÕÇÉÅ OR> ÏÄÎÏËÒÉÓÔÁÌÏÞÎÙÅ ËÏÍÐÉÌÑÔÏÒÙ ÑÚÙËÁ ó.

Referring to a Type with `typeof' =================================

#define max(a,b) \ ({ typeof (a) _a = (a); \ typeof (b) _b = (b); \ _a > _b ? _a : _b; })

typeof (*x) y;

Generalized Lvalues ===================

Non-Constant Initializers =========================

foo (float f, float g) { float beat_freqs[2] = { f-g, f+g }; /* ... */ }

Designated Initializers =======================

Case Ranges ===========

case LOW ... HIGH: case 'A' ... 'Z': case 1 ... 5:

Declaring Attributes of Functions =================================

void foo () __attribute__ ((ÁÔÒÉÂÕÔÙ));

noreturn - ÆÕÎËÃÉÑ ÎÉËÏÇÄÁ ÎÅ ×ÏÚ×ÒÁÝÁÅÔÓÑ, ÍÏÖÎÏ ÎÅ ÓÏÈÒÁÎÑÔØ ÒÅÇÉÓÔÒÙ

pure - ÆÕÎËÃÉÑ ÎÅ ÄÅÌÁÅÔ ÎÉÞÅÇÏ, ËÒÏÍÅ ×ÙÞÉÓÌÅÎÉÊ ÎÁÄ ÁÒÇÕÍÅÎÔÁÍÉ, ÔÁË ÞÔÏ ÏÎÁ ÍÏÖÅÔ ÕÞÁÓÔ×Ï×ÁÔØ × common subexpression elimination

weak - ÆÕÎËÃÉÑ ÚÁÐÉÓÙ×ÁÅÔÓÑ Ó ÁÔÔÒÉÂÕÔÏÍ weak. üÔÏ ÚÎÁÞÉÔ, ÅÓÌÉ ÂÕÄÅÔ ÅÝÅ ÏÄÎÁ ÆÕÎËÃÉÑ ÂÅÚ ÁÔÔÒÉÂÕÔÁ weak, ÔÏ ÂÕÄÅÔ ÓÌÉÎËÏ×ÁÎÁ ÔÁ, ËÏÔÏÒÁÑ ÂÅÚ weak

naked - ÎÅ ÓÏÚÄÁ×ÁÔØ ÐÒÏÌÏÇÁ É ÜÐÉÌÏÇÁ.

Defining Global Register Variables

----------------------------------

register int *foo asm ("a5");

HÏ ÄÌÑ AVR ÜÔÏ ÒÁÂÏÔÁÅÔ ÎÅ ÔÁË ËÁË ÈÏÔÅÌÏÓØ ÂÙ. èÏÔÅÌÏÓØ ÂÙ ÏÂßÑ×ÉÔØ ÎÅËÏÔÏÒÙÅ ÇÌÏÂÁÌØÎÙÅ ÐÅÒÅÍÅÎÎÙÅ, ÉÓÐÏÌØÚÕÅÍÙÅ × ÐÒÅÒÙ×ÁÎÉÑÈ, × ÒÅÇÉÓÔÒÁÈ, ÞÔÏÂÙ ÎÅ ÔÒÁÔÉÔØ ×ÒÅÍÑ ÎÁ ÓÏÈÒÁÎÅÎÉÅ/×ÏÓÓÔÁÎÏ×ÌÅÎÉÅ. ïÄÎÁËÏ gcc ÔÁËÉÅ ÐÅÒÅÍÅÎÎÙÅ ÎÁÏÂÏÒÏÔ - ÓÏÈÒÁÎÑÅÔ/×ÏÓÓÔÁÎÁ×ÌÉ×ÁÅÔ, ÔÁË ÞÔÏ ÐÅÒÅÍÅÎÎÙÅ ÉÚ ÇÌÏÂÁÌØÎÙÈ ÐÒÅ×ÒÁÝÁÀÔÓÑ × ÌÏËÁÌØÎÙÅ.

Unnamed struct/union fields within structs/unions. ==================================================

For compatibility with other compilers, GCC allows you to define a structure or union that contains, as fields, structures and unions without names. For example:

struct { int a; union { int b; float c; }; int d; } foo;

In this example, the user would be able to access members of the unnamed union with code like `foo.b'. Note that only unnamed structs and unions are allowed, you may not have, for example, an unnamed `int'.

Alexey

"Maxim Polyanskiy" <Maxim snipped-for-privacy@p12.f.n5020.z2.fidonet.org>

Hello, Dimmy Timchenko !