- Vote on answer
- posted
20 years ago
AVR GCC&IAR
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
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 может быть использован как под переменную А одной функции, так и под переменную Б другой. В случае асм-а приходится выделять память под каждую переменную, даже если они не мешают друг другу.
В общем, ты не смотрел, под что и как компилятор распределяет ОЗУ. Объяснить, зачем компилятору Си нужно дополнительное ОЗУ и что он с ним делает, тоже не можешь. Можешь задавать только встречные вопросы, оставляя без ответа заданные тебе.
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago
- Vote on answer
- posted
20 years ago