AVR GCC&IAR

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

GS>> При чём тут стиль? Hачиная с размера "байта" и "инта" - сплошные GS>> "определяется реализацией". Какой при этом может быть стиль? :-/ AM> Определяется, но оно известо для данной коткретной платформы.

GS> Hе только платформы, но ещё и от конкретного _компилятора_.

Не встречал разных компиляторов для одной платформы, чтобы у них были разные размеры одних и тех же типов, потому как размерность типов определяется главным образом самим ядром, его разрядностью. Нет смыскла делать int на х51 32 разрядным, к примеру. Но тем не менее, хорошим стилем считается переопределить стандартные типы на свои: typedef unsigned char BOOLEAN; typedef unsigned char INT8U; /* Unsigned 8 bit quantity */ typedef signed char INT8S; /* Signed 8 bit quantity */ typedef unsigned int INT16U; /* Unsigned 16 bit quantity */ typedef signed int INT16S; /* Signed 16 bit quantity */ typedef unsigned long INT32U; /* Unsigned 32 bit quantity */ typedef signed long INT32S; /* Signed 32 bit quantity */ typedef float FP32; /* Single precision floating point */ typedef double FP64; /* Double precision floating point */

GS> Это автоматически определяет машинозависимость получившейся GS> программы. Хотя многие сторонники C любят напирать на его GS> "машинонезависимость"...

Чтобы обеспечить машинонезависимость, нужно придерживаться определенного стиля. Но в embedded - машинонезависимость не сама цель. В ряде случаев она вообще не имеет смысла, например при написании HAL. Но в App я уровнях стараюсь придерживаться стиля, получая возможность повторного использования кода на других платформах. В любом случае ассемблер вообще не обладает какой-либо независимостью, у асм даже служебные слова не стандартизованы.

AM> Hе уверен

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

Этот человек, как минимум должен знать ассемблер, для начала.

GS>> чем в аналогичной по сложности сишной программе в GS>> типичном для сишников "минималистском" духе ;)

AM> Что значит типичный для сишников? Почему все, кто не пишет на Си, AM> считает, что программа на си это нечно в виде: AM> #include <stdio.h>

AM> #include <stdlib.h>

AM> #define P printf AM> #define I atoi AM> int main(int a,char*v AM> []){int r=7, i;if(a>1 AM> ) r=I(v[1]); if(r<=0) AM> r=5;if(r%2==0)++r;for

GS> Потому что при попытках ознакомиться с языком на примерах GS> чаще всего они видят нечто подобное ;)

Скажи, в каких учебниках по языку ты видел подобные примеры?

GS>> У меня комментария в несколько раз больше, чем кода... AM> Hа Си запрещены комментарии?

GS> Hет. Hо против них выступаю многие сишники, считая, что GS> "и так всё понятно".

Ты споришь не с подходом, а с неким стилем программирования на Си, причем явно не лучшим. Комментарии на Си в большинстве случаев сводятся не к построчным: /* Вот здесь к А прибавили Б */ /* А вот здесь сравнили А с 10 */ а к описанию алгоритма для достижения определенной цели. В заголовке к функции может быть описано, что вообще здесь делается, потом могут следовать 10-20-100 строк на Си без комментариев (или с минимумом их), с _понятными_ именами переменных. Искодник будет в купе с тектовым описанием алгоритма самодокументированным.

AM> Почему ты считаешь, что , к примеру у меня на Си нет комментариев.

GS> Я этого не говорил. "Исключения лишь подтверждают правило" ;)

Я не думаю, что я исключение, скорее правило.

GS>> Можно, конечно программировать сразу на "высокоуровневом" языке. GS>> И учат сейчас преимущественно на Паскеле. Hо знание "нижнего GS>> уровня" всё-таки даёт очень много преимуществ. Особенно в GS>> эхотаге...

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

GS> Эхотажных?

Да, я вообще привык говорить в эхе про эхотаг, а не про PC под Win, как это делает иногда MP

AM> решаются либо вообще без асма, либо со вставками в критических по AM> скорости или объему кода местах. Общее количество асма обычно не AM> превышает 3-5% объема кода.

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

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

GS>> А с чего ты взял, что ты имеешь равную квалификацию на сях и GS>> асме?

AM> Тем, что разглядывая код после Си я видел примерно то-же, что я бы AM> написал на асме,

GS> Hу и что?

То, что в разы эффективенее написать невозможно.

AM> на асме возможно чуть более оптимально, но и то не везде.

GS> Иногда можно написать эффективнее на порядок. Hа ассемблере.

Эти иногда - не более 1% кода. И то, единожны посмотрев, какая консрукиця Си ложится очень не оптимально на этот процессор, можно выбрать другую и сократить код, если это действительно нужно.

GS>> У меня поначалу тоже кошмарные программы получались. Hо через GS>> несколько лет пришло понимание, как на уровне "низкоуровневых GS>> трюков", так и на "высоком" уровне - организации структур и GS>> процессов в системе. И теперь мои программы имеют размер в разы GS>> меньше, чем аналоги на сях от опытных программистов.

AM> Для определенных действий всегда существует минимально-возможный AM> объем операций (команд процессора).

GS> Это для самых простейших действий.

Вся программа в конечном итоге состоит из набора простейших действий

GS> И то, постоянно выдумываются хитрые трюки...

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

AM> Большинство компиляторов на Си приближаются к нему достаточно сильно, AM> допуская небольшой оверхед.

GS> Hа примитивных тестовых примерах - да. Потому что при создании GS> этих компиляторов они на подобных примерах тестируются. Hа реальных GS> сложных задачах возможны варианты...

Определенные конструкции языка компилируются в определенный код. Реальные задачи состоят из набора контрукций языка. Поясни, почему с увеличением количества этих конструкций в проекте код становится неоптимальным?

AM> Уменьшить его в несколько раз физически не возможно.

GS> Hеверие в свои силы - одна из причин невозможности что-либо GS> сделать.

Сделай сравнение двух переменных из RAM х51 оптимальнее, чем

MOV A,tx_idx XRL A,save_idx JZ ?C0003

Именно в этот код компилируется оператор if (tx_idx != save_idx) {...}

AM> Впрочем, для Фомы неверующего предлагаю дать сюда простой алгоритм AM> чего либо.

GS> Простой алгоритм не о чём не говорит. Это уже показано многократными GS> обсуждениями в эхах.

И не в пользу асма. Разница какая? Программа в конечном итоге набор простых алгоритмов. В общем, ты, как всегда остаешься бездоказательным. На словах ты, как факир, ужимаешь код в 10 раз, на деле же сразу появляется 100 допущений, которые тебе надо, чтобы это продемонстрировать. И алгоритм тебе надо сложный, и компилятор дерьмовый, и программиста на Си пахорукого.

Мое предложение, выбери алгоритм из "Numerical Recipes in C", я его откомпилирую на х51, а ты попробуешь оптимизирвоать полученный код или предствавить полностью свой. Посчитаем оверхед по скорости и объему. Если он будет 5 кратным - я съем свою шляпу и перейду на ассемблер.

AM>> По RAM на Си иногда можно получить выигрыш на "не стековх AM>> архитектурах", из-за трудности вручную на ассемблере сделать AM>> компилированный стек.

GS>> Hа PIC стека, считай, вообще нету.

AM> Куда же локальные переменные кладутся? Правильно - распределяются по AM> RAM, то есть получается не в чистом виде стек, а компилированный стек.

GS> Теперь попробуй доказать, что это не приводит к издержкам на GS> время выполнения, "раздуванию" кода и уменьшению и так крошечного GS> объёма доступной оперативной памяти PIC'ов...

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

В общем, ты не смотрел, под что и как компилятор распределяет ОЗУ. Объяснить, зачем компилятору Си нужно дополнительное ОЗУ и что он с ним делает, тоже не можешь. Можешь задавать только встречные вопросы, оставляя без ответа заданные тебе.

Reply to
Andy Mozzhevilov
Reply to
Dimmy Timchenko
Reply to
Maxim Polyanskiy
Reply to
Dimmy Timchenko

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.