Мэт Годбольт (Matt Godbolt) представил (http://xania.org/201205/gcc-explorer) первую версию инструмента GCC Exlorer, предназначенного для наглядного просмотра результата компиляции участков исходного кода на языках C/C++ в инструкции на языке ассемблера. GCC Explorer выполнен в виде веб-приложения, позволяющего быстро просмотреть результат компиляции произвольного участка кода, оценить качество его оптимизации, а также наглядно изучить техники оптимизации, применяемые GCC.
<center><img src="https://www.opennet.ru/opennews/pics_base/0_1337878005.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
В частности, используя GCC Exlorer разработчики могут более детально познакомиться с особенностями генерации машинного кода для различных новых возможностей стандарта C++11 и понять насколько оптимальны применяемые в проекте конструкции. Приложение полностью основано на технологиях AJAX, поэтому любое изменение исходного кода, версии компилятора, передаваемых ему флагов приводит к немедленному обновления окна с результатом компиляции. Благодаря этому инструмент удобно использовать не только для изучения, но и для оптимизации и устранения узких мест алгоритмов в реальном времени.Оценить работу инструмента можно на странице gcc.godbolt.org (http://gcc.godbolt.org), поддерживается генерация кода с использованием g++ 4.4, 4.5 и 4.6
Исходные тексты опубликованы на хостинге GitHub (https://github.com/mattgodbolt/gcc-explorer). Для работы требуется фреймворк node.js.
URL: http://xania.org/201205/gcc-explorer
Новость: https://www.opennet.ru/opennews/art.shtml?num=33931
Да ну... Я думал, он что-нибудь анализирует, или там хотя бы дерево разбора показывает, а он мне просто вывод от gcc -S вываливает :( Детская игрушка.
Пардон, а нафига мне, допустим, как конечному пользователю gcc, промежуточное дерево разбора? Что оно мне даст с практической точки зрения компиляции в конечный ассемблерный код моего родимого C кода? Да пусть он представляет промежуточные данные внутри себя любым пусть самым невообразимым [красивым|ужасным] способом - меня то, как конечного пользователя, интересует лишь конечный результат.
Чёй-то у меня даже слов нету... :DПример
Дано:
if ( a < b )
x++;/* либо */
if ( b > a )
x++;Найти: Оптимальный вариант!
Он может сильно отличаться в зависимости от платформы, версии gcc, и кода, который стоит до и после (например, какого типа у нас a и b, перегружен ли < и/или >) - что все варианты перепробовать? По-моему, цели могут быть только образовательные или ради любопытства. Для серьезных оптимизаций обычно используют другие средства (профайлер, статические анализаторы и пр).
Есть очень глубокий цикл, в нем пара десятков коротких операций, влияющих на контекст. Как вы их оптимизируете профайлером без просмотра кода? Выдергивать из цикла не получится - изменится контекст, замерить одну итерацию тоже не получится.
> Он может сильно отличаться в зависимости от платформы, версии gcc, и кода,
> который стоит до и после (например, какого типа у нас a
> и b, перегружен ли < и/или >) - что все варианты
> перепробовать? По-моему, цели могут быть только образовательные или ради любопытства.
> Для серьезных оптимизаций обычно используют другие средства (профайлер, статические анализаторы
> и пр).if ( a > b )
cmovge %edx,%eax
if ( b < a )
cmovl %edx,%eax
---
Условия переходаCMOVGE: ˜(SF ˆ OF) & ˜ZF == NOT ( SF XOR OF ) AND ( NOT ZF)
CMOVL: SF ˆ OF == SF XOR OF
gcc такое не оптимизирует?! o_O
Старый боян https://www.midnight-commander.org/ticket/1948
:)
Я даже пошел по ссылке и глянул. Предположение, что дело в количестве операций над флагами мне видится странным (вряд ли на серьезном процессоре от Intel или AMD cmov* будет реализован на микрокоде или транслироваться в большое количество uop'ов - по идее, любой из cmov* должен на этих процессорах быть в железе и выполняться не более чем за один такт по throughput при отсутствии stall'ов). Более вероятным мне представляется, что один из вариантов условия более соответствовал конкретным входным данным, что, возможно, позволяло избежать data или output dependency stall (недавно измененный операнд оказывался невостребованным или же результат оставался неизменным) в большей части случаев. Если так, то это не то, что компилятор должен угадывать сам, без хотя бы profiler feedback'а. Если такая особенность данных закономерна (статистически таких наборов данных больше, чем "противоположных"), то вместо игр с a < b vs. b > a, которые не обязаны транслироваться именно в эти инструкции, может быть лучше использовать __builtin_expect() (сначала проверив на __GNUC__), чтобы передать совет компилятору явно. Ссылку на руководство от AMD тоже глянул - она почти не в тему - там только о том как cmov* лучше branch'ей....Проверил на Xeon E5420 (что было под рукой) - как и ожидал, cmovl и cmovge выполняются одинаково за один такт, независимо от выполнения условия. Повлиять на stall'ы в этой или соседних инструкциях меняя cmovl/cmovge или (не)выполнение условия мне не удалось. Возможно, на другом процессоре удалось бы.
> как и ожидал, cmovl и cmovge выполняются одинаково за один такт,
> независимо от выполнения условия.Скажи, что за чудная программа для определения тактов команд?
> Скажи, что за чудная программа для определения тактов команд?Одна из самоделок. Проверяемая инструкция или короткая последовательность инструкций повторяется много раз (например, от 100 до 1000), чтобы убавить эффект от out-of-order выполнения в начале и конце, и измеряется время выполнения либо одного такого куска кода в тактах (по rdtsc), либо цикла, повторяющего такой набор (в этом случае можно измерять количество итераций цикла за секунду процессорного времени). Потом результат пересчитывается. Для использования требуется понимание того, что делаешь, в том числе надо учитывать зависимости между инструкциями или их отсутствие - поэтому я не вижу особого смысла выпускать такой готовый инструмент.
По исходной теме, мне представляется наиболее вероятным, что ты где-то ошибся - например, смотрел не на точно тот же код, для которого проверял время выполнения.
> повторяется много раз (например, от 100 до 1000), чтобы убавить эффект
> от out-of-order выполнения в начале и конце, и измеряется время выполненияДык это... в реальной программе не будет непрерывного потока из 1 этой команды. А вот как соседние инструкции цикла нагрузят проц совместно с этой командой - кула более интересный вопрос, ведь это и влияет на скорость цикла.
>> повторяется много раз (например, от 100 до 1000), чтобы убавить эффект
>> от out-of-order выполнения в начале и конце, и измеряется время выполнения
> Дык это... в реальной программе не будет непрерывного потока из 1 этой
> команды. А вот как соседние инструкции цикла нагрузят проц совместно с
> этой командой - кула более интересный вопрос, ведь это и влияет
> на скорость цикла.Раньше Intel печатала таблицы расстактовок, сейчас видимо забили.
> Раньше Intel печатала таблицы расстактовок, сейчас видимо забили.Потому что стало довольно бессмысленно: растактовка варьируется в зависимости от того какие команды были рядом. Как ты понимаешь, возможность впихать раздробленные на микрокоманды инструкции в блоки выполнения зависит от того какие и чем заняты. То-есть разные инструкции вокруг "исследуемой" очень даже могут поменять наблюдаемую картину. По идее растактовка получается плавающей и зависимой от "предыстории".
> Дык это... в реальной программе не будет непрерывного потока из 1 этой
> команды. А вот как соседние инструкции цикла нагрузят проц совместно с
> этой командой - кула более интересный вопрос, ведь это и влияет
> на скорость цикла.Конечно.
> По исходной теме, мне представляется наиболее вероятным, что ты где-то ошибсяСугубо гипотетические расчёты, CMOVGE - проверяет значения трёх флагов: ZF, OF, SF;
CMOVL - двух: OF и ZF. При самых оптимистичных расчетах выигрыш не менее 3 тактов. :)
> CMOVGE - проверяет значения трёх флагов: ZF, OF, SF;
> CMOVL - двух: OF и ZF. При самых оптимистичных расчетах выигрыш не менее 3 тактов. :)Я старался быть вежливым и надеялся, что за твоими словами есть хоть что-то, но всё же употреблю это слово: абсурд. Вот некоторые причины почему такие рассуждения абсурдны:
Реальные процессоры (не эмуляторы) обрабатывают всё это параллельно, в пределах одного такта (теоретически можно было бы говорить лишь о задержке прохождения сигнала, что теоретически могло бы ограничивать максимальную тактовую частоту - но в данном контексте это тоже на уровне абсурда). Реальные logic gates не соответствуют привычному и потому используемому в документации на ISA набору AND/OR/NOT, так что их количество будет другим (возможно, даже не целым), да и смешно их считать для этой разовой вещи вот так поштучно (к тому же, разработчика скорее будет интересовать задержка, чем количество транзисторов). Флаги могут храниться не именно в том виде, как они представлены на уровне ISA. Проверка флагов - лишь небольшая часть реализации даже только CMOV*, и она, вероятно, существует не сама по себе, а является частью реализации в целом, т.е., вероятно, нет отдельно блока, проверяющего три флага и отдельно другого блока, проверяющего два.
> CMOVL - двух: OF и ZF. При самых оптимистичных расчетах выигрыш не
> менее 3 тактов. :)А с чего вдруг манипуляции с флагами должны иметь разную растактовку? Любой мало-мальски вменяемый проц выставляет все флаги как надо за 1 такт.
> А с чего вдруг манипуляции с флагами должны иметь разную растактовку? Любой
> мало-мальски вменяемый проц выставляет все флаги как надо за 1 такт.Докажешь, что за один такт можно сделать ˜(SF ˆ OF) & ˜ZF
Ну, представь, он тебе вываливает какое-нибудь промежуточное дерево, а ты интерактивно выбираешь, где какие оптимизации применить, и сразу видишь результат.
> Пардон, а нафига мне, допустим, как конечному пользователю gcc, промежуточное дерево разбора? Что оно мне даст с практической точки зрения компиляции в конечный ассемблерный код моего родимого C кода? Да пусть он представляет промежуточные данные внутри себя любым пусть самым невообразимым [красивым|ужасным] способом - меня то, как конечного пользователя, интересует лишь конечный результат.Примерно так же рассуждают пользователи Виндов, допустим, об опенсурсе.
"Пардон, а нафига мне, допустим, как конечному пользователю ОС, открытый код? Что оно мне даст с точки зрения с точки зрения возникновения на экране моих родимых окошек? Да пусть оно написано хоть на каком языке внутри себя, пусть самым невообразимым [красивым|ужасным] способом - меня то, как конечного пользователя, интересует лишь конечный результат."Ваши рассуждения ошибочны уже по логической форме даже не вдаваясь в содержание.
Поскольку если вы не знаете, зачем нужно промежуточное дерево разбора, это еще не значит, что оно не нужно. И если вы не знаете, что с ним делать, это еще не значит, что никто не знает, как это можно применять, и извлекать очень большую пользу для себя.А если вы этого ничего не знаете, тогда зачем вам даже такой инструмент нужен, как "конечному пользователю". Видимо просто только чтобы попонтоваться перед другими мельтешней кода на экране.
А без интроспекции это действительно просто красивая игрушка для любителей окошек, для тех, кто так и не осилил командную строку.
Все-таки вопрос был "зачем оно надо", на который ваша стена текста никак не отвечает, в ней только распальцовка. Я не говорю что оно не нужно, просто приведите конкретные примеры, чтобы не выглядеть болтологом
> Все-таки вопрос был "зачем оно надо", на который ваша стена текста никак не отвечает, в ней только распальцовка. Я не говорю что оно не нужно, просто приведите конкретные примеры, чтобы не выглядеть болтологомВсе уже прекрасно поняли, что вы считаете "болтологами" тех, кто знает, зачем нужно видеть дерево разбора транслятора.
Хотя при этом так и остается непонятным, зачем вам нужен этот "explorer", если вам не нужна интроспекция. И кто после этого "болтолог".
> Пустопорожняя болтовняСлив засчитан
> Слив засчитанВсе так говорят, когда нечем крыть.
Как много букв, как мало смысла.
> Как много букв, как мало смысла.Если для вас это количество букв показалось запредельным, а смысл от вас ускользнул, неудивительно, что вы раньше ничего не знали про опцию -S. Ведь в руководствах букв еще больше.
эти болтологи думаете прочли хоть один ваш комент ?думаю не стоит их кормить
> эти болтологи думаете прочли хоть один ваш комент ?
> думаю не стоит их кормитьПусть кушают, не жалко.
А прочитают другие и сделают выводы.
>Примерно так же рассуждают пользователи Виндов, допустим, об опенсурсе.11 лет назад ушел с виндов потому что они не справлялись с кодированием мпег4 в реалтайме. С тех пор ни разу не пожалел. Так что не обобщайте.
>>Примерно так же рассуждают пользователи Виндов, допустим, об опенсурсе.
>
> 11 лет назад ушел с виндов потому что они не справлялись с кодированием мпег4 в реалтайме. С тех пор ни разу не пожалел. Так что не обобщайте.Если вы не рассуждаете так же, как было написано выше, тогда причем здесь вы.
Дерево разбора может понадобиться, например, студентам или разработчикам компиляторов или кому угодно, кто интересуется. Не столь важно. Важно то, что нарисовать дерево разбора - достаточно нетривиальная задача, а сделать gcc -S сможет любой дурак. Причём он сможет сделать это на реальном, большом проекте, и посмотреть какой код генерится, например, во всех узких местах. А в это окошечко он что сможет запостить? Две функции без зависимостей?Ну, ладно, ещё можно сказать, что там сразу несколько версий компиляторов. Но ведь для АРМа не работает! Опции поменять - тоже у меня не получилось. Компилятор запускается, похоже, при изменении текста в поле ввода! Что это ещё за "ынтырпрайз" подход, когда компилятор знает лучше разработчика, когда ему запускаться! Сделал бы кнопочку "Скомпилировать", не так криво, может быть, работало бы, да и нагрузка на сервер уменьшилась бы, который сейчас дёргает компилятор на каждый чих в поле ввода!
Студенческое поделие, короче, причём студента второкурсника. Я помню, мы на старших курсах сами компиляторы писали, причём с генерацией кода...
> Да ну... Я думал, он что-нибудь анализирует, или там хотя бы дерево разбора показывает, а он мне просто вывод от gcc -S вываливает :( Детская игрушка.А все дело в том, что в самом по себе gcc большие проблемы с интроспекцией. Всему виной его хаотично разраставшаяся архитектура и долгое отсутствие альтернатив.
И какую оконную морду ему ни прикрути, его внутренняя суть от этого не изменится.
А кто командной строкой пользоваться так и не научился, ему окошки недостаток способностей не восполнят, а лишь сделают вид.
Глядя на то какой код генерят всякие шланги, кейлы, иары и прочие - понимаешь что gcc генерит далеко не самый плохой код на свете. А пиндящие насчет архитектуры забыли одну маленькую деталь: выкатить свой кодогенератор который всех сделает. В частности gcc. На всех поддерживаемых архитектурах, разумеется. Посмотрев на то что шланг генерит для ARM например можно вообще офигеть.
> Глядя на то какой код генерят всякие шланги, кейлы, иары и прочие
> - понимаешь что gcc генерит далеко не самый плохой код на
> свете. А пиндящие насчет архитектуры забыли одну маленькую деталь: выкатить свой
> кодогенератор который всех сделает. В частности gcc. На всех поддерживаемых архитектурах,
> разумеется. Посмотрев на то что шланг генерит для ARM например можно
> вообще офигеть.294-ый, ты 3.1 уже прогнал на арм-ах?
> 294-ый, ты 3.1 уже прогнал на арм-ах?Я на данный момент больше гоняю на cortex M3 и немного на AVR. А LLVM уже это умеет?
> Глядя на то какой код генерят всякие шланги, кейлы, иары и прочие - понимаешь что gcc генерит далеко не самый плохой код на свете.Вот насчёт Кейла не надо. Кейл генерит более качественный код для ARM, чем gcc. Знаю как разработчик. Не говоря уже о кейловской среде разработки. Ещё Кейл поддерживает, например, 8051, а gcc нет.
ты что - великий User294 все знает :) И вообще gcc все поддерживает что надо - а что не поддерживает - никому не надо.
> поддерживает что надо - а что не поддерживает - никому не надо.Не хочу ничего сказать но лично мне актуальнее и интереснее компильнуть пингвин под ARM чем с окаменелым х51 возиться. Впрочем я и против cortex M3 ничего не имею, у STM например весьма годные чипы по весьма годным ценам, навороченные и умеющие дофига всего, при цене и параметрах делающих 8-битники просто морально устаревшими ископаемыми.
> Вот насчёт Кейла не надо. Кейл генерит более качественный код для ARM, чем gcc.Вау, сразу видно проприераса: у него кайло бьет гцц на всех видах ядер сразу, во всех ситуациях :)
> Знаю как разработчик.
Слишком хорошо звучит чтобы быть правдой, вам не кажется? Мне ведь достаточно найти всего 1 пример где это будет не так и вы в 2 счета окажетесь лжецом. А вы так специально подставляетесь или это просто в силу природной толстокожести характерной для убежденных проприетарщиков?
> Не говоря уже о кейловской среде разработки.
Да, монолитная кривоватая хрень, где все через то еще место. Я ей даже когда-то пользовался слегка. Довольно гадостная штука IMO. Лично мне юзать отдельный эдитор и пулять из него make'ом билдовку и зашивку больше нравится чем юзать это кривоватое и глючноватое угробище. Которое еще и стоит конских денег или имеет лимит на размер кода - на выбор. Все-таки модульность и независимость разных частей друг от друга - это хорошо и гибко. Да еще и нахаляву. Честно говоря я вообще не понял кем надо быть чтобы такие поделия покупать за такие бабки.
> Ещё Кейл поддерживает, например, 8051, а gcc нет.
Спасибо, конечно, но вот ты и колупайся с этой интелской окаменелостью в эпоху когда 32-битный cortex M3 со всеми наворотами и с кучей вкусной периферии за доллар продается. Под x51 есть в принципе sdcc но мне до балды, потому что я не некроман и просто не имею с ним дело ни в какой ипостаси.
А ты если такой умный лучше расскажи мне как твоей кайлой вообще пингвин собрать под ARM? Ну допустим ARM9 или Cortex A8? А то не получается EPIC WIN'а над гццом без настолько вкусной плюшки то. Все-таки ARM это не только мелкие контроллеры но и довольно большие процессоры приложений еще.
> IMOIMHO, правильно писать IMHO
Млин, луркояз хотя бы учите, если "русский языка" для вас "такая сложная"
>> IMO
> IMHO, правильно писать IMHOну, вот у тебя humble, а у кого-то просто обычное. я, например, показной скромностью не страдаю. и не только я.
> IMHO, правильно писать IMHOНу я не считал что в данном случае мнение излишне скромное, поэтому "humble" убрал ;). Да, я в отличие от вас еще и знаю что "IMHO" означает, а не просто повторяю заученное слово.
> Млин, луркояз хотя бы учите, если "русский языка" для вас "такая сложная"
Удачи в обучении меня сетевым акронимам. Только я в сетях побольше вашего и данными акронимами пользуюсь поболее вашего. Указанный варант сокращения имеет хождение, просто менее популярен, т.к. не у всех хватает духа намекать на свою нескромность :)
> Вау, сразу видно проприераса: у него кайло бьет гцц на всех видах ядер сразу, во всех ситуациях :)Не надо придумывать глупостей и приписывать их оппоненту.
> Слишком хорошо звучит чтобы быть правдой, вам не кажется? Мне ведь достаточно найти всего 1 пример где это будет не так и вы в 2 счета окажетесь лжецом. А вы так специально подставляетесь или это просто в силу природной толстокожести характерной для убежденных проприетарщиков?
Мне не интересно, что вам кажется. Мне также не интересны ваши убеждения по поводу "проприетарщины" и СПО. Я подозреваю, что ваши религиозные взгляды были оскорблены тем фактом, что кто-то высказался в пользу проприетарного ПО, а не СПО, но с этим я тоже ничего поделать не могу.
> Мне ведь достаточно найти всего 1 пример где это будет не так и вы в 2 счета окажетесь лжецом.
Чушь. Один пример всего лишь покажет, что в одном случае gcc лучше. Покажите, что gcc лучше в БОЛЬШИНСТВЕ случаев, тогда я вас послушаю.
> Да, монолитная кривоватая хрень, где все через то еще место. Я ей даже когда-то пользовался слегка. Довольно гадостная штука IMO. Лично мне юзать отдельный эдитор и пулять из него make'ом билдовку и зашивку больше нравится чем юзать это кривоватое и глючноватое угробище. Которое еще и стоит конских денег или имеет лимит на размер кода - на выбор. Все-таки модульность и независимость разных частей друг от друга - это хорошо и гибко. Да еще и нахаляву. Честно говоря я вообще не понял кем надо быть чтобы такие поделия покупать за такие бабки.
А отлаживать свой замечательный проект ты будешь чем? gdb для ARM? Тогда ты точно не некроман. Ты мазохист. А написать прогу для, допустим, LPC2129, не имея этого самого LPC2129 на руках, слабо? Кейловская среда не без проблем, но она обеспечивает визуальную отладку не только на устройстве, но и совсем без устройства, эмулируя ОГРОМНОЕ количество микроконтроллеров вместе с периферией ИЗ КОРОБКИ. Свободные аналоги такого уровня ОТСУТСТВУЮТ КАК КЛАСС.
> Спасибо, конечно, но вот ты и колупайся с этой интелской окаменелостью в эпоху когда 32-битный cortex M3 со всеми наворотами и с кучей вкусной периферии за доллар продается. Под x51 есть в принципе sdcc но мне до балды, потому что я не некроман и просто не имею с ним дело ни в какой ипостаси.
Ты смешной. Если что-то не вписывается в твой инвентарный список, это не значит, что оно не нужно :) У меня девайс габаритами 3 х 5 см с 1К ОЗУ (своего рода флэшка, если хочешь знать, только специализированная). Какой там "32-битный cortex M3"! Там 8051 хватает за глаза, только нужен нормальный компилятор, генерящий оптимальный код, и отладчик с эмулятором, потому что отлаживать всё это на реальном устройстве с 1К ОЗУ - удовольствие ниже среднего.
> А ты если такой умный лучше расскажи мне как твоей кайлой вообще пингвин собрать под ARM? Ну допустим ARM9 или Cortex A8? А то не получается EPIC WIN'а над гццом без настолько вкусной плюшки то. Все-таки ARM это не только мелкие контроллеры но и довольно большие процессоры приложений еще.
Я тебя умоляю! Я не собираю кейлом пингвин под АРМ и не забиваю гвозди микроскопом. Пусть этим занимаются красноглазые пионеры-экспериментаторы. Мне достаточно РЕАЛЬНЫХ задач, где Кейлу пока что найти замену трудно.
> Не надо придумывать глупостей и приписывать их оппоненту.Ну так вы безаппеляционно завяили не меньшую глупость. Почему бы и не отыграться за это? Вы сами такой шанс дали :)
> Мне не интересно, что вам кажется. Мне также не интересны ваши убеждения
> по поводу "проприетарщины" и СПО. Я подозреваю, что ваши религиозные взгляды
> были оскорблены тем фактом, что кто-то высказался в пользу проприетарного ПО,Мои религиозные взгляды были оскорблены тем фактом что кто-то имеет наглость сватать кривой проприетарный булшит стоящих конских бабок, при этом выдавая на гора не совсем объективные сведения. Ну и да, отсутствие этой хрени под удобную мне систему вызывает у меня некие антипатии к вендору, который хочет кучу бабла, но совершенно не хочет париться о моем удобстве. Как ни странно я при таком раскладе питаю антипатию далеко не только к кейлу но и к любому иному продавцу/производителю поступающему так же.
> а не СПО, но с этим я тоже ничего поделать не могу.Скорее, имеет место ситуация "я тут освоил кайлу, а свое г... не пахнет". Юзал кайло в свое время. Ничего особо позитивного о нем сказать не могу - весьма кривая хрень. С довольно самопальным пониманием и самого си, и форматов файлов, и что там еще. Так что если этот бобик сдохнет - применить знания потом вообще нигде особо не получится. А како он будет дохнуть или развиваться зависити от небольшой горстки людей. Ну решат они его придушить например - фиг оспоришь.
>> Мне ведь достаточно найти всего 1 пример где это будет не так и вы в 2 счета окажетесь лжецом.
> Чушь. Один пример всего лишь покажет, что в одном случае gcc лучше.Ну так тотального превосходства кайлы уже не получается. А если рубаться по всем мыслимым критериям - так там наверняка в каких-то случаях один выиграет, в каких-то другой.
> Покажите, что gcc лучше в БОЛЬШИНСТВЕ случаев, тогда я вас послушаю.
Во первых, это весьма масштабная задача, которая наврядли реализуема за разумный срок.
Во вторых, а почему меня должно интересовать какое-то там абстрактное большинство случаев?
В третьих, по результатам забегов опубликованных ALL на тематических форумах GCC выглядит вполне приличным компилером.> А отлаживать свой замечательный проект ты будешь чем? gdb для ARM? Тогда
> ты точно не некроман. Ты мазохист.Не вижу ничего такого мазохистичного. GDB - он не "для ARM". Он - дебагер. А к нему есть например OpenOCD мостик. Впрочем, я обычно обхожусь вообще отладочным выводом в UART, мне вполне хватает. Так, на подумать: народ много лет писал весьма навороченный софт и без всех этих примочек для гламурных-кис-wannabe-embedded-типа-developer. И работало. Получше чем у таких как вы.
> А написать прогу для, допустим, LPC2129, не имея этого самого LPC2129 на руках, слабо?
Не "прогу" а жалкое подобие, которое на реальном железе скорее всего или не будет работать вообще, или будет обладать зиллионами глюков. Кстати сами LPC лично мне вообще не понравились. Кривые какие-то, как большинство поделий NXP. Пинауты удивительно дебильные (почему-то все время обе нужные функции на одних и тех же пинах) и сама периферия странная. Запись в флеш - вообще жесткач какой-то. Мало того что надо дергать какое-то левое ROM апи, так оно еще кривое и бажное и с кучей требований к софту к тому же. А вот у STM периферия радает крутостью и продуманностью, пинауты обычно куда более вменяемы, линейки и ценообразование тоже радуют.
> Кейловская среда не без проблем, но она обеспечивает визуальную отладку
(нужную только гламурным кисам, которые сперва напишут булшит, который сами уже не понимают, а потом пытаются из д@рьма конфетку сделать в дебагере, знаем-знаем).
> не только на устройстве, но и совсем без устройства, эмулируя ОГРОМНОЕ
> количество микроконтроллеров вместе с периферией ИЗ КОРОБКИ.Увы, я не фанат "резиновых зин" и считаю что лучший отладочный тулзень - это реальная плата с реальным камнем в реальных условиях. На кой черт мне сферические кони в вакууме? Тем паче что у них своих глюков есть а у камней - своих (errata же).
> Свободные аналоги такого уровня ОТСУТСТВУЮТ КАК КЛАСС.
Да, у меня не будет "резиновой зины" забесплатно. Такое несчастье, конечно. Правда я в свое время налетев на отличие в поведении реального железа и эмуля зарекся с эмулями связываться. Круто когда в эмуле работает а в реальной железке - болт, правда? Если отлаживаться на реальной железке, гоняя там постепенно дописываемый код - момент когда оно начало работать не так как ожидалось на основании логики кода и даташитов - поймать довольно просто (так даже можно поймать то что попадает в секцию errata даташита потом). А вот если все написать под эмуль а потом пытаться разгрести на реальной железке почему все работает не так как задумано - хорошая заявка на геморрой. Вот тут реально придется корпеть в дебагере дохрена (хотя имхо проще сразу застрелиться).
> Ты смешной. Если что-то не вписывается в твой инвентарный список, это не
> значит, что оно не нужно :)А ты смотри внимательно и наблюдай как ща половина 8-битников радостно помрет. ARM довольно грамотно им обгадил малину своими M3 и M0. Почти все более-менее активные вендоры 8-биток резко отрастили маложрущие 32-битные линейки. И чего это они? Учитывая их параметры и уровни цен - ареал обитания 8-биток сильно сократися.
> У меня девайс габаритами 3 х 5 см с 1К ОЗУ (своего рода флэшка, если хочешь
> знать, только специализированная). Какой там "32-битный cortex M3"!В девайс 3х5 см с современной комплектухой можно впихать дофига всего, уже полновесные штуки с линем и кучей памяти приближаются к этому размеру вплотную. А у упомянутых кортексов есть корпуса типа 6х6 мм (QFN 36, например). Это как тетрадная клеточка примерно. На плате 3х5 сантиметров он как кактус в пустыне будет выглядеть :P.
> Там 8051 хватает за глаза,
Так это... при цене армового камня менее бакса, с кучей мощной и приятно сделанной периферии, нормальным набором команд, внятным набором регистров и режимов, etc - этот твой х51 с кучей дебилизмов, убогим ядром, паскудной периферией, кривым I/O и прочая сдался только махровым некроманам. Ну еще есть всякие китайцы, гоняющие партии в миллионы, там за 10 центов удавятся. Ну вот там х51 может еще не помрет. Но это не про exUSSR. Тут такие тиражи как-то не характерны.
> только нужен нормальный компилятор, генерящий оптимальный код, и отладчик
> с эмулятором, потому что отлаживать всё это на реальном устройстве с
> 1К ОЗУ - удовольствие ниже среднего.Да я не спорю что сначала можно создать себе вагон проблем а потом героически их решать. Но мне этот вариант не нравится, извините.
> Я тебя умоляю! Я не собираю кейлом пингвин под АРМ и не забиваю гвозди микроскопом.
Не вижу в каком месте это забивание гвоздей микроскопом. Пингвин отлично подходит для массы различных задач. Уж в сетевых вопросах он вообще всех рвет с отрывом. А ты попробуй на чем-нибудь еще например сделать железку показывающую статус или рулящую чем-то через интернет? А чтоб это еще и с провом у которого PPTP работало? А по вайфаю? Ах, задачи разные бывают? Ну надо же :)
> Пусть этим занимаются красноглазые пионеры-экспериментаторы.
> Мне достаточно РЕАЛЬНЫХ задач, где Кейлу пока что найти замену трудно.Трудно оно только тем кто зачем-то создает себе проблемы на ровном месте.
> Во вторых, а почему меня должно интересовать какое-то там абстрактное большинство случаев?Ха-ха. Вот в этом вы все. Будете отрицать даже очевидные факты, если они противоречат вашей религии :)
> Впрочем, я обычно обхожусь вообще отладочным выводом в UART, мне вполне хватает.
Это потому, что ты ничего сложнее "Hello world" никогда не писал. Попробуй написать устройство которое одновременно делает измерения, обрабатывает результаты, записывает их в определённом формате (в ту самую "флэшку"), управляется пользователем посредством клавиатуры и индикаторов, а также взаимодействует с другими устройствами по CAN. И всё это на "голом железе" с 16К (ШЕСТНАДЦАТЬЮ КИЛОБАЙТАМИ) ОЗУ. Вот тогда я посмотрю, как тебе будет "достаточно" отладочного вывода по УАРТ. Бгг.
Кстати, что ты делаешь, если УАРТа на твоём устройстве физически нет?
> Получше чем у таких как вы.
У меня одна и та же прога работает на ARM, на 8051, на ПК, и в эмуляторе Кейла. И работает везде одинаково хорошо. А что можешь сделать ты?
> Да я не спорю что сначала можно создать себе вагон проблем а потом героически их решать. Но мне этот вариант не нравится, извините.
Это потому, что ты живёшь в параллельной вселенной. А в нашем мире нужно сделать малогабаритное энергосберегающее устройство, в которое ARM ну никак не влезет, и по УАРТ его отлаживать невозможно ввиду отсутствия этого самого УАРТА. И результате мы принимаем рациональное решение, а не религиозно верное.
> написать устройство которое одновременно делает измерения, обрабатывает результаты,
> записывает их в определённом формате (в ту самую "флэшку"), управляется пользователем
> посредством клавиатуры и индикаторов, а также взаимодействует с другими устройствами по
> CAN. И всё это на "голом железе" с 16К (ШЕСТНАДЦАТЬЮ КИЛОБАЙТАМИ)
> ОЗУ.самое то для форта.
> Ха-ха. Вот в этом вы все. Будете отрицать даже очевидные факты, если
> они противоречат вашей религии :)Вот в этом вы все - будете впаривать кривой булшит под 1 систему стоящий конских бабок, хотя есть еще 100500 валидных методов решения исходной задачи ("нужен девайс, делающий X с параметрами Y по цене Z"). Настаивая что ваш метод самый лучший. Без уточнения чем именно это принципиально лучше.
>> Впрочем, я обычно обхожусь вообще отладочным выводом в UART, мне вполне хватает.
> Это потому, что ты ничего сложнее "Hello world" никогда не писал.Смотря что за хелловорлд считать. У меня один знакомый в качестве хелловорлда на ардуине соорудил девайс похожий на то что вы описываете. Нормально? :)
> Попробуй написать устройство которое одновременно делает измерения,
> обрабатывает результаты, записывает их в определённом формате (в ту самую "флэшку"),
> управляется пользователем посредством клавиатуры и индикаторов,Во первых, я не вижу в каком месте тут ракетная наука. Каждый второй эмбеданутый девайс как-то так и выглядит. Даже совсем наколенные ардуинщики такое и то делают, хоть и со скрипом отличают диоды от транзюков :)
Во вторых, истинной одновременности на 1-ядерной системе все-таки не получится поскольку поток команд в каждый момент времени - один.
В третьих, у ARMов для оффлоада проца от половины подобных вещей есть DMA, что позволяет ему переживать куда более серьезные потоки данных, если уж на то пошло.
В четвертых, вот прям ща у меня валяется контроллер на Z80, которому более 20 лет. Тут вам и экран, и клава, и меню, и что там еще. Несложно догадаться что его фирмварину в 32К накорябали без всяких jtag'ов и супер-дебагеров.> а также взаимодействует с другими устройствами по CAN. И всё это на "голом железе"
> с 16К (ШЕСТНАДЦАТЬЮ КИЛОБАЙТАМИ) ОЗУ.16К ОЗУ вообще-то по меркам мелкой эмбедовки довольно дофига. Если хочется попонтоваться - это тинька какая-нибудь, где 8 лапок, 1-2 кило флеша и спасибо если полкило оперативы. Вот тут понт мизерным количеством ресурсов будет засчитан :P. А на что в той задаче 16К жрать?
> Вот тогда я посмотрю, как тебе будет "достаточно" отладочного вывода по УАРТ. Бгг.
И что будет? Ты поди как самый умный написал огромную простыню, да еще на симуляторе. "А потом со всей этой фигней мы попробуем взлететь". Ну и получил то что должен был. Так не все ж такие эпичные буратины.
> Кстати, что ты делаешь, если УАРТа на твоём устройстве физически нет?
Его обычно нет в совсем тривиальных камнях типа тинек, где вообще нифига нет и все лапы заняты, так что никакой крЮтой дебагер тоже не прицепишь. И да, полкило кода без багов я и без дебагового вывода напишу. А сильно больше в эту мелочь и не лезет.
>> Получше чем у таких как вы.
> У меня одна и та же прога работает на ARM, на 8051, на ПК, и в эмуляторе Кейла.Дык это чистая математика так отлаживается. С фига б ей не работать? А работа с периферией где?! Чистую математику можно отладить вообще билданув код под писюк. Правда вот от uC обычно почему-то нужна далеко не только (или даже не столько) математика. Скажи, чувак, как мне чтение ADC отлаживать на писюке? У него такого ADC нет! А то что там эмулятором наэмулируется может очень слабо коррелировать с свойствами реальной железяки в реальном применении. И чем мне поможет твой эмулятор при этом? Тем что "в теории вроде работает"? Так бл, мне на практике нужны отсчеты. При том желательно достоверные и с пониманием того насколько фуфельный результат по факту вышел.
> И работает везде одинаково хорошо. А что можешь сделать ты?
Ну по крайней мере у меня хватает ума не понтоваться тем что голая математика одинаково работает, т.к. я это воспринимаю как данность :). Она у всех у кого руки не из ж... одинаково работает. За что мы и любим си, собственно. Вот только на uC обычно нужна не только абстрактная математика но и работа с реальной периферией реального камня. А вот она обычно кульными эмуляторами эмулируется черти-как, с кучей глюков и особенностей. Так что надеятся на это вообще нельзя. А у камней бывают еще и ерраты и прочая. Была мне охота кроме глюков реального камня еще и глюки эмулятора изучать.
>> Но мне этот вариант не нравится, извините.
> Это потому, что ты живёшь в параллельной вселенной. А в нашем мире
> нужно сделать малогабаритное энергосберегающее устройство, в которое ARM ну никак не
> влезет,А что именно не влезет и по какому именно критерию? Я пока только самое общее блеяние видел, но ни единого конкретного параметра по которму не влезло. Огласите лимиты из задачи и то чего вы достигли, я с удовольствием сравню с параметрами симпатичных мне ARMов :). ARM нынче есть и дешевые, и мелкие, и маложрущие (а ты думаешь что я от них просто так прусь?). И еще не факт что ваш х51 сильно лучше будет. Вы хоть тип вашего камня скажите чтоли чтоб я датащит позырил? :)
> и по УАРТ его отлаживать невозможно ввиду отсутствия этого самого
> УАРТА. И результате мы принимаем рациональное решение, а не религиозно верное.Судя по отсутствию сколь-нибудь рационального обоснования выбора такой дребедени как x51 в 2012 году, тут что-то не то. В каком месте тут рациональность?
ЗЫ кстати случайно обнаружил что olimex (чьих плат у меня есть, по очевидным причинам) - затейники и в целом стали довольно дружественны к опенсорсу - как-то так: http://www.olimex.com/dev/
член секты "сидетели ллвм"?
> член секты "сидетели ллвм"?Если вам что-то не понравилось или вы что-то не осилили, это еще не значит, что там секта.
О таком я только мечтал)
Ну да - ничего сверхъестественного, мог бы профайлер запускать
> О таком я только мечтал)лучше бы ты документацию на компилятор читал вместо мечтаний. тогда давно слепил бы себе скрипт и пользовался.
Какой-то студент склпеал веб-оболочку для gcc -S и радуется как дитя. А то без веба и гитхаба как-то немодно.
> Какой-то студент склпеал веб-оболочку для gcc -S и радуется как дитя. А то без веба и гитхаба как-то немодно.Да ладно бы и не жалко, пусть упражняется.
Только слишком амбициозное название для такой лабораторной работы - целый Explorer.
Хотя на самом деле он ничего там не експлоурит, а всего лишь с потоками ввода-вывода играется.
> Только слишком амбициозное название для такой лабораторной работы — целый Explorer.красивое название — половина успеха!
это GCC для хомячков?
Отличное дополнение к internet explorer и explorer.exe
Хипстеры добрались до gcc ?!
кто такие хипстеры?
> кто такие хипстеры?Чуть заапгрейженые хомячки :)
Теперь бы тоже самое, но в виде нормального приложения, а не web-убожества.
Прочти комментарии выше твоего.
А смысл?
> А смысл?Втыкать ради 1 студенческой приблуды в систему node.js нужный мне как рыбке зонтик в водной среде - довольно странное и неудобное развлечение.
1) а ARM версия не работает =(2) было бы удобно если оно будет добавлять строки исходного кода внутрь кода как это делает objdump например
3) ну и если будет ARM было бы забавно видеть ARM NEON - вот где пригоидтся эта утилита чтобы сразу видеть результат
4) ну и вообще супер если оно еще запускаться будет, т.е. исполнять код и можно будет оценить скорость, но это наверное уже проще десктопный софт писануть :)
Опять этот убожеский AT&T синтакс! Когда же его забудут?
> Опять этот убожеский AT&T синтакс! Когда же его забудут?непривычный — не обязательно плохой.
> Опять этот убожеский AT&T синтакс! Когда же его забудут?Не понял, а чего такого плохого в синтаксисе?
Не понятен малость смысл. Ну выводит она мне gcc -S, и чё дальше....Встроили бы bruteforce по перебору флагов gcc:
- На минимальность размера кода;
- По сумме тактов команд;
- Прогнозирование переходов и объёмы циклов с заданными пределами;
- Сравнение 3-4 вариантов (настраиваемое);
Хочу GCC-Doom, где ошибки компиляции можно расстреливать из пулемёта, чтобы не мешали.
> Хочу GCC-Doom, где ошибки компиляции можно расстреливать из пулемёта, чтобы не мешали.Use comments, Luke! :). Хотя да, нормальное для питониста желание - там факап случается после того как оно отпашет 2 дня. Счастливой отладки!
отакжы полезно для анализа различных программ, для последующего взлома