AVR GCC&IAR

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

DO> Он вполне подходит и под понятие компилятора.

YK> Hикогда не слышал, чтобы говорили компилятор ассемблера. YK> Как-то не по-русски это звучит.

Словарь компьютерных терминов: Компиляция. Преобразование программы из описания на входном языке (языке программирования) в ее представление на выходном языке (в машинных командах).

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

Reply to
Andy Mozzhevilov
Reply to
George Shepelev
Reply to
George Shepelev
Reply to
George Shepelev
Reply to
George Shepelev
Reply to
George Shepelev

MP> IU> сложных алгоpитмах. Hо даже в данном пpимеpе легкость понимания MP> IU> алгоpитма значительно выше в Сях.

MP> Этот религиозный спор бессмысленен. Понимание автоматически лучше на том языке MP> который лучше знаешь, не может быть никакой легкости понимания си если лучше MP> знаешь асм. Это же банально.

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

MP>> Вообще-то именно для таких пpоэктов (нажали кнопкy - загоpелся MP>> светодиод) сyществyет банальная битовая логика, вот напpимеp MP>> MCS51:

IU> Компилиpованный модyль в Сях, также бyдет использовать битовyю IU> логикy.

MP> А вот это уже гон! Приведи пример компилятора которым ты можешь откомпилировать MP> тот кусок на си (изначально предложенный как пример), чтоб использовалась MP> битоваля логика?

В Си для х51 для использования битовых операций переменная объявляется типа bit - это расширение языка. После этого компилятор для нее применяет clrb, setb, movb, jb, jnb и jbc, если нужно. (возможно за давностью не все мнемоники написал верно)

IU> Еще pаз, pазговоp о пpостоте понимания алгоpитма. За более IU> легкое чтение пpиходится платить pазмеpом и скоpостью выполнения IU> кода, ты не готов не плати.

MP> Да нет никакой легкости понимания - это очевидно.

Очевидно, что для понимания Си нужно знать только Си, для понимания алгоритма на ассемблере знать N ассемблеров. Вообще никогда не видел, чтобы в книгах алгоритмы писали на каком-то ассемблере, поскольку якобы это проще для понимания :)

MP> Hесостоятельность оверхеда MP> 15% я уже многократно доказывал. Как на собственном примере так и на чужих.

Вообще - не помню, чтобы ты доказывал. Последнее доказательство ты приводил для PC - оно не катит. Кроме того бессмысленно доказывать большой оверхед одного маленького кусочка. Всегда можно найти пример, где Си проиграет ассемблеру и в 5 раз. Но в пределах проекта это нивелируется и оверхед составит 15-30%, не более.

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

Чушь, все компиляторы дают после компиляции в файле листинга объем сегментов code, const, data, stack и т.п. в зависимости от типа платформы. Для оценки временных ресурсов тоже есть свои способы - простейший, посчитать по листингу такты в критичных по времени кусках, как правило прерываниях.

MP> в результате где-то в середине вдруг приходит насущная необходимость поменять MP> контроллер, тут начинаются базары про то, как все шоколадно переписывается на MP> другой контроллер, которые ничего кроме здорового смеха у меня не вызывают!

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

Reply to
Andy Mozzhevilov
Reply to
George Shepelev
Reply to
George Shepelev

DO> Откуда 5-6 раз-то? И причем тут писишный софт под виндовс?

MP> ладно - пример неудачный. У меня на самом деле нет реальных примеров когда одно MP> и то-же писалось на 2-х языках для одного контроллера, но вот есть например x51 MP> прога на сях исходник 21421 длинна откомпилированного кода 3865 байт. Есть MP> БОЛЕЕ ФУHКЦИОHАЛЬHЫЙ аналог на picasm - исходник 27765 код 1252 слова. Таблицы MP> в обоих имеют одинаковую длинну. Оверхед по любому 50% есть.

Сравнил жопу с пальцем Может еще сравним ARM с MCS48?

MP> >> на сях, для связи с какой нибудь банальной 24с256. ;) DO> Пишется на С за 5 минут.

MP> Hу ладно - положим пишется за 5 минут, и отлаживается за часок ;)

Чем манипуляция битами порта на Си более сложна, чем таже манипуляция на ассемблере?

DO> А сколько ты свои ассемблерные наработки (и когда ты столько DO> накопил?)

MP> За 10 лет можно и не столько накопить...

DO> на другой процессор переносить будешь?

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

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

DO> Мы как-то программный UART с ST7 на PIC переносили перекомпиляцией.

MP> Да ничего сложного. Мне надо было в моторолу 11-ю вставить кусок кода MP> програмного уарта, - быстренько прикинул как там по тактам прога выполнется и MP> какие команды за сколько (кстати безценная инфа) и написал. Дальше зациклил ее MP> на выводе кода 55h ткнул частотомер - baudrate то, что надо, вот и все дела. MP> Сколько времени заняло не помню - но и чтоб проблемы какие-то при этом возникли MP> тоже не помню.

Ничего сложного, конечно нет, но время то где взять?

Reply to
Andy Mozzhevilov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.