AM>>> Приведи примеры конкретных компиляторов. GS>>> Сам поищи, точно были. AM>> "Пойди туда - не знаю куда, принеси то - не знаю что". AM>> Впрочем, другого ответа от тебя и не следовало ожидать.
GS> Тебе надо - ты и ищи. Я не обязан терять своё время на постоянные GS> доказательства очевидных вещей. _Своих дел хватает_.
Ты обязан, утверждая что-либо, подкреплять это доказательствами. А не отсылать за поиском оных своего же оппонента. Во всяком случае, я считаю это хорошим стилем обсуждения.
AM>> благо их и хороших много.
GS> Хороших-то стилей может и много, но пользующихся ими явно GS> недостаточно...
Я здесь не это обсуждаю
AM>> Почти у всех компиляторов, которые я встречал есть опция компиляции в AM>> режиме ANSI C. Для желающих.
GS> Hу а теперь посмотри на начало обсуждения и подумай, кто даёт тебе GS> гарантии, что чужая программа, которую нужно будет понять, написана GS> именно в такм режиме? Правильный ответ - никто.
А и не надо, базовые контрукции не меняются. Производятся лишь дополнения, связанные с аппаратными особенностями процессора. А не зная аппаратных особенностей железа нефиг соваться в сопровождение устройства вообще, если сопровождаешь именно HAL или нечто подобное. В APP у меня вполне себе ANSI C.
AM>> Hикогда ничего не получается сразу, вот так "по щучьему велению".
GS> Вопрос не в том, что ничего не получается сразу, а сколько надо GS> затратить времени и усилий, чтобы получалось (причём грамотно).
Независимо от C / Asm
GS> Я понимаю, задачи, которыми занимаются другие люди, тебе GS> не интересны, но постарайся про их существование не забывать...
Зачем мне о них знать? Я их буду сопровождать?
GS> Исходный вопрос был о "сишном стиле". Я привёл пример общедоступного GS> источника "сишного стиля". Который существует объективно, независимо GS> от моего мнения о качестве этого стиля и этих текстов...
Исходный вопрос был не о стиле, а о оверхеде на порядок и больше. Стиль в рамках данного обсуждения мне вообще неинтересен, это ты гнешь сюда, где можно побольше воды налить и пофилософствовать.
AM>> Я отношу себя к нормальным водителям. Это ты любишь цирковые "трюки".
GS> Ещё раз. Сишный стиль _объективно_ провоцирует трюки. Сам язык возник GS> как инструмент компактной записи таких трюков. Hе на всякий процессор GS> это хорошо "ложится", к примеру для PIC12/16 изобилие указателей GS> с пре/пост инкрементом/декрементом на бумаге выглюдит эффектно, а GS> в коде - кошмарно.
У тебя есть листинг после компилятора? Приведи здесь.
GS>>> преимущества (уменьшение исходника, повышенная эффективность и GS>>> т.п.) AM>> Hе философствуй, приведи примеры.
GS> Их множество в любой книжке по C.
Опять отсылаешь оппонента за поискоми доказательств для тебя же?
AM>> Чушь. Приведи пример трюков.
GS> Использование внутри выражения пре/пост инкремента/декремента, GS> простейший пример трюка. Который достаточно понятен в простеньком GS> "учебном" примере и может быть весьма неочевиден в программе GS> реальной сложности.
например: buffer[i++] = char; Это трюк?
AM>> И не о том речь. Речь о твоем утверждении об оверхеде кода после AM>> компилятора Си, на порядок по сравнению с асм.
GS> Это просто факт из личной практики (не только моей).
У тебя в личной практике нет опыта работы с Си. Как ты можешь это утверждать?
AM>> Hе приведя никаких конкретных доказательств ты уiел от темы разговора AM>> в обсужение самодокументирования.
GS> Я привёл конкретный, общеизвестный пример. Программы для АОH'ов GS> пишутся на ассемблере. Хотя коллективов программистов, которые GS> этим занимались, было много, софт переносился с одного процессора GS> на другой и компилятор C был доступен этим программистам. Основная GS> причина такой ситуации - заметно большие ресурсы, которые требует GS> АОH'овский софт, написанный сишниками. GS> Вот с этим _фактом_ попробуй поспорить, а не со мной ;)
Я уже высказывал свое мнение насчет АОНов с соседних письмах. Кроме того Аон - одна из миллионов существующих задач и свет на ней клином не сошелся.
AM>> Я не идеализирую, я отвечаю от своего имени, а не от имени армии AM>> программиистов на Си. Hо по существу вопроса я пока ничего не услышал, AM>> кроме утверждений о том, что ты сам не пробовал и не знаешь.
GS> По существу вопроса - я убедился, что C крайне плохо ловит GS> "зевки" программиста,
Ассемблер их ловит ну просто хорошо. Чего уж стоит зевок в х51 типа MOV A,3 вместо MOV a,#3 Сделанный в паре сотен строк кода. Причем иногда может не то, что совсем не работать, но работать как-то странно, в зависимости от того, что нам по адресу 3 лежит. А по существу, нужно знать язык, чтобы на нем писать. Ну, и хотелось бы иметь пример зевка, который плохо ловит Си.
GS> чужие программы как правило плохо GS> документированы и написаны в "странном" стиле, посему по GS> возможности отказался от его использования. За себя я сказал ;)
Что-то наконец более или менее конкретное. Но что-то в аргументах я не вижу 10 кратного оверхеда Си по ROM и RAM.
AM>> Hу что тебе сказать. Ты ловко умеешь менять тему разговора в сторону, AM>> где можно налить много "воды" и поразводить руками.
GS> Ля-ля не надо. Ты меняешь тему разговора точно так-же, только GS> фактов у тебя нету, а есть только фразы о твоём мнении и твоём GS> стиле, которые не обязаны совпадать с остальными...
Я не стиль здесь обсуждаю, а утревждение об оверхеде.
GS>>> удавалось "ужать" на порядок. И не думаю, что выбор более GS>>> подходящего компилятора привёл бы к чуду. Верю в улучшение на 10%, GS>>> на 30%, но никак не на 90%... AM>> Так может нужно не полагаться на веру, а убедиться самому.
GS> Я не обязан быть "святее Папы римского". Если куда лучшие специалисты GS> по сям не смогли получить пристойный результат - я не буду пытаться GS> с ними соперничать "на их территории". У меня есть свой инструмент GS> (ассемблер), который я знаю лучше и который обеспечивает на конкретных GS> задачах _существенно_ лучшие результаты. Хочешь доказать, что я неправ, GS> попытайся сделать на сях программку с той же эффективностью, как это GS> делаю я на ассемблере (до сих пор это ещё никому не удавалось)...
С той же - не удастся - 100%. С оверхедом 15-30%, вполне, ну 40% с попровкой на твою гениальность. При одинаковых алгоритмах работы.
AM>>> Hа 15% GS>>> Или в 15 раз! ;) AM>> Только хи-хи да ха-ха. AM>> Пример приведи.
GS> Современный АОH'овский софт. Хочешь для Z80, хочешь для i51.
На Z80 - это современный? Я думал уже раритет.
GS> Сишных вариантов нет,
Все исходники free? Ты их видел? Аоны обычно продаются с зашитым кодом, а не с исходниками/компилятором и программатором в комплекте.
GS> поскольку в доступныю память "железяки" они "не лезут".
И это единственный возможный аргумент. "Осталось 2 байта свободной памяти после годовой оптимизации в уме на ассемблере".
GS> Это при том, что больше половины объёма ПЗУ GS> занимает пакованный звук, так что избытка места для кода никак GS> не наблюдается...
Не аонами едиными жив эмбеддер. У меня вот в MB90F543 памяти 128К, в общем хоть ж... ешь.
AM>> Ты же мне приводишь какой-то код Си.
GS> Да. Что касается ассемблера, то возможность "трюкачить" GS> на нём относится к принципиальным особенностям этого языка. GS> И к этому приходится прибегать, если нужно обеспечить GS> предельную эффективность программы (весьма актуально для GS> эхотага).
Вот и приведи пример, одного трюка, не всех. От одной засветки у тебя конкуретнов не прибавится, имхо.
GS>>> "Вменяемые" действия алгоритма желательно иметь возможность GS>>> достаточно просто описать на естественном языке. AM>> Приведи пример своих трюков на ассемблере, которые магическим образом AM>> позволяют ужfть программу в разы. Hадеюсь, это не ноу-хау.
GS> Кстати, зря надеешься. Я деньги получаю за программы, написанные GS> с использованием этих ноу-хау. И к чему мне самому-себе растить GS> конкурентов? ,)
То есть либо таких трюков (позволяющих ужать код в разы) у тебя просто нет (что очевидно), либо это обычные тривиальные действия, которые ты не хочешь показать, потому что "ну все так умеют".