AVR GCC&IAR

Hello, Vadik!

VA> ëÁËÁÑ ÒÁÚÎÉÃÁ? ðÅÒÅÓÙÌËÉ? á ÞÔÏ ÖÅ ÎÅ ÏÄÎÁ É ÔÁ ÖÅ ÍÎÅÍÏÎÉËÁ mov? á ÎÉËÔÏ ÎÅ ÍÅÛÁÅÔ ÔÅÂÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÏÄÎÕ ÔÏÌØËÏ ÍÎÅÍÏÎÉËÕ MOV! MP>> ôÅÐÅÒØ ÓÍÏÔÒÉÍ ×Ï ÞÔÏ ÜÔÏ ÐÒÅ×ÒÁÔÉÌÏÓØ × 68Ë: VA> HÅÔ, ÓÍÏÔÒÉÍ, ÞÔÏ ÏÚÎÁÞÁÅÔ ËÁÖÄÁÑ ËÏÍÁÎÄÁ É ÄÕÍÁÅÍ. MP>> movea.l VA> HÉËÔÏ ÎÅ ÚÁÐÒÅÔÉÔ ÎÁÐÉÓÁÔØ move.l ×ÍÅÓÔÏ movea.l, É ËÏÍÐÉÌÑÔÏÒ ÔÅÂÑ VA> ×ÓÅÇÄÁ ÐÏÊͣÔ. åÓÌÉ ËÏÎÅÞÎÏ ÔÙ ÐÏÎÉÍÁÅÛØ ÏÔÌÉÞÉÅ movea ÏÔ move... HÅ-Á. Warning ×ÙÄÁÓÔ. ðÏÔÏÍ ÄÕÍÁÊ ÏÔËÕÄÁ ÔÁËÉÈ ×ÁÒÎÉÎÇÏ× ×ÁÇÏÎ ÒÁÓÔÅÔ. MP>> movem.l VA> þÔÏ ÏÎÁ ÄÅÌÁÅÔ-ÔÏ, ÚÎÁÅÛØ? ìÁÄÎÏ ÐÏÊÍÁÌ, ÐÅÒÅÓÙÌËÉ ÍÅÖÄÕ ÐÁÍÑÔØÀ ÉÌÉ ÓÏÈÒÁÎÅÎÉÅ É ×ÏÓÔÁÎÏ×ÌÅÎÉÅ ÒÅÇÉÓÔÒÏ× ÐÏ ÓÐÉÓËÕ... ÷ ÐÓ ÐÏÄÏÂÎÏÇÏ ÉÚ×ÒÁÔÁ ÎÅÔ. HÕÖÅÎ ÏÎ ÉÓËÌÀÞÉÔÅÌØÎÏ ÄÌÑ ñ÷õ. MP>> move.l MP>> move.w MP>> move.b

VA> HÕ É? ÐÉÓÁÔØ word ptr/byte ptr/ÈÒÅÎ ptr ÌÕÞÛÅ? ëÓÔÁ, moveq ÎÅ × ÔÅÍÕ É VA> ÐÏÔÏÍÕ ÓËÉÐÎÕÔÁ. ìÕÞÛÅ, ÉÂÏ ÓÈÏÄÕ ÐÏÎÑÔÎÅÅ. é ÏÂßÑÓÎÀ ÐÏÞÅÍÕ. ðÏÔÏÍÕ, ÞÔÏ ÍÏÔÏÒÏÌÁ ÂÁÎÁÌØÎÏ ÎÅ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÁ, É × ÔÏÍ-ÖÅ mcore ÐÏÔÁÝÉÌÁÓØ ËÏÎËÕÒÉÒÏ×ÁÔØ Ó ÁÒÍÏÍ. × ÒÅÚÕÌØÔÁÔÅ ÉÍÅÅÍ LDW LDH LDB. íÎÅ ËÏÎÅÞÎÏ ÐÏÆÉÇÕ, ÎÏ ÄÌÑ ÍÅÎÑ DWORD/WORD/BYTE - ÜÔÏ 20 ÌÅÔ ËÁË ÏÄÎÏÚÎÁÞÎÏ 32/16/8 ÂÉÔÎÙÅ ×ÅÌÉÞÉÎÙ. ñ ËÏÎÅÞÎÏ ÎÕÔÒÏÍ ÐÏÎÉÍÁÀ, ÞÔÏ WORD/HALFWORD/BYTE × ÄÉÂÉÌØÎÙÈ ÁÒÈÉÔÅËÔÕÒÁÈ 32/16/8, ÎÏ ×ÏÔ ÕÍÏÍ ÐÏÎÑÔØ ÎÅ ÍÏÇÕ, ÎÁÆÉÇ ÔÁËÏÊ ÚÏÏÐÁÒË ÎÕÖÅÎ. äÁ ×ÏÏÂÝÅ × ÁÎÇÌÉÊÓËÏÍ ÑÚÙËÅ ÔÉÐÁ 29 ÉÌÉ ÓËÏËÁ ÔÁÍ-ÂÕË×. ìÀÂÏÊ ÎÁÂÏÒ ÍÎÅÍÏÎÉË ÍÏÖÎÏ 2-ÍÑ ÂÕË×ÁÍÉ ÚÁÐÉÓÁÔØ, ÏÄÎÁËÏ ÉÄÉÏÔÉÚÍ ÜÔÏ. MP>> åÓÌÉ ÐÒÏÁÎÁÌÉÚÉÒÏ×ÁÔØ ÓÉÔÕÁÃÉÀ ÔÏ ×ÉÄÎÏ, ÞÔÏ ËÏÍÁÎÄÙ ÄÕÂÌÉÒÕÀÔ MP>> ÄÒÕÇ ÄÒÕÇÁ, ÔÁ-ÖÅ moveq ÜÔÏ move.l - ×ÉÄ ÓÂÏËÕ. VA> âÒÅÄ. moveq - ÚÁÇÒÕÚËÁ ÚÎÁËÏ×ÏÊ ÂÁÊÔÏ×ÏÊ ËÏÎÓÔÁÎÔÙ Ó ÒÁÓÛÉÒÅÎÉÅÍ ÄÏ VA> ÌÏÎÇÁ × ÒÅÇÉÓÔÒ ÄÁÎÎÙÈ (ËÏÎÓÔÁÎÔÁ ÉģÔ × ÏÐËÏÄÅ), move.l - ÐÅÒÅÓÙÌËÁ VA> ÌÏÎÇÁ ÏÔËÕÄÁ ÕÇÏÄÎÏ ËÕÄÁ ÕÇÏÄÎÏ. HÁÐÒÉÍÅÒ: VA> move.l -(a0),5(a1,d0.w*8) HÉÖÅ ÔÙ ÓÁÍ ÎÁÐÉÓÁÌ ÞÔÏ MOVEQ ÅÓÔØ ÏÐÔÉÍÉÚÉÒÏ×ÁÎÎÙÊ ×ÁÒÉÁÎÔ MOVE.L! HÅ ÐÏÎÑÌ Ó ÞÅÍ ÔÙ ÔÏÇÄÁ ÎÅ ÓÏÇÌÁÓÅÎ? MP>> óÏÚÄÁÎÉÅ ÏÐÔÉÍÉÚÉÒÕÀÝÅÇÏ ÁÓÍ ËÏÍÐÉÌÑÔÏÒÁ (ÔÉÐÁ ÔÏÇÏ ÞÔÏ ÎÁ x51 MP>> Á×ÔÏÍÁÔÏÍ ×ÙÂÉÒÁÅÔ acall scall ÉÌÉ lcall ÓÔÁ×ÉÔØ ×ÍÅÓÔÏ call) × MP>> ÐÒÉÎÃÉÐÅ ÐÏÚ×ÏÌÉÌÏ ÂÙ ×ÙËÉÎÕÔØ ÎÁÆÉÇ moveq ÎÅ ÎÁÇÒÕÖÁÑ ËÏÄ MP>> ÌÉÛÎÉÍÉ ÎÕÌÑÍÉ, ÐÏÞÅÍÕ ÍÏÔÏÒÏÌÁ ÐÏÛÌÁ ÐÏ ÔÁËÏÍÕ ÄÕÒÁÃËÏÍÕ ÐÕÔÉ - MP>> ÎÅ ÚÎÁÀ. VA> ëÏÍÐÉÌÑÔÏÒÙ ÕÍÅÀÔ ÐÅÒÅÄÅÌÙ×ÁÔØ ÐÏÄÈÏÄÑÝÉÊ move.l #const,dn × moveq VA> (ÅÓÌÉ ÐÏÐÒÏÓÉÛØ), ÄÁÌØÛÅ ÞÔÏ? äÁÌØÛÅ Ë ÞÅÒÔÕ MOVEQ! (ëÓÔÁÔÉ ÍÏÊ ÎÅ ÕÍÅÅÔ) MP>> HÏ ÔÏ, ÞÔÏ ÍÎÅÍÏÎÉËÉ 68k - ÜÔÏ ÂÒÅÄ ÓÕÍÁÛÅÄÛÅÇÏ, Õ ÍÅÎÑ ÎÉËÁËÉÈ MP>> ÓÏÍÎÅÎÉÊ ÎÅ ×ÙÚÙ×ÁÅÔ! VA> õÇÕ, Õ ÎÁÓ ÔÁËÁÑ ÒÅÌÉÇÉÑ É Ó×ÏÊ ÂÏÇ (x86), ×ӣ ÏÓÔÁÌØÎÏÅ - ÂÒÅÄ VA> ÓÕÍÁÓÛÅÄÛÅÇÏ... HÅ ×ÓÅ Á ËÏÎËÒÅÔÎÏ 68k - ÂÒÅÄÑÔÉÎÁ. MP>> üÆÅËÔÉ×ÎÁÑ ÓÉÓÔÅÍÁ Õ×Ù ÚÁÐÁÔÅÎÔÏ×ÁÎÁ... ×ÓÅ ÏÓÔÁÌØÎÙÅ ÉÚ×ÒÁÝÁÀÔÓÑ MP>> ËÁË ÍÏÇÕÔ. VA> óËÏÌØËÏ ËÉÌÏÂÁÊÔ ËÏÄÁ ÔÙ ÎÁÐÉÓÁÌ ÎÁ 68k? HÅ ÂÏÌÅÅ 3-È. ôÏÌØËÏ ×ÏÔ, ÞÔÏ ÉÈ ÎÁÐÉÓÁÔØ ÍÎÅ ÐÒÉÛÌÏÓØ ÉÓÓÌÅÄÏ×ÁÔØ ÏËÏÌÏ 10Í ÞÕÖÏÇÏ ËÏÄÁ, É ÐÅÒÅÌÏÖÉÔØ ÎÁ pc ÐÏÒÑÄËÁ 70Ë ÏÎÏÇÏ, É Ñ ÍÏÇÕ ÓËÁÚÁÔØ ÞÔÏ × ÇÒÏÂÕ Ñ ×ÉÄÅÌ ÜÔÏÔ 68Ë ÐÏÓÌÅ ÜÔÏÇÏ!

Hello, Dima!

Hello, Dima!

Dimmy, ÔÙ Åݣ ÚÄÅÓØ ÓÉÄÉÛØ?

GS>> i51 z80 x86 PIC

GS>> þÔÅÎÉÅ ÑÞÅÊËÉ ÐÁÍÑÔÉ GS>> -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- GS>> -- ÍÎÅÍÏÎÉËÁ MOV A,n ÆÌÁÇ Z + ÆÌÁÇ C -

DT> HÅÔ × 51-Í "ÆÌÁÇÁ Z". :)

HÏ ÅÓÔØ ËÏÍÁÎÄÙ, ËÏÔÏÒÙÅ ÒÁÂÏÔÁÀÔ, ËÁË ÂÕÄÔÏ ÜÔÏÔ ÆÌÁÇ ÅÓÔØ. üÄÁËÉÊ ×ÉÒÔÕÁÌØÎÙÊ ÆÌÁÇ ;) õÄÏÂÎÏ ÄÌÑ ÏÂÝÎÏÓÔÉ ÒÁÂÏÔÙ Ó ÒÁÚÎÙÍÉ ÐÒÏÃÅÓÓÏÒÁÍÉ.

HÏ Ñ ÇÏÔÏ× Ó ÉÎÔÅÒÅÓÏÍ ×ÙÓÌÕÛÁÔØ ÏÂÏÓÎÏ×ÁÎÉÅ, ÐÏÞÅÍÕ ÔÁËÁÑ ËÏÎÃÅÐÃÉÑ _ÐÒÉÎÃÉÐÉÁÌØÎÏ_ ÎÅ×ÅÒÎÁ.

Dimmy, ÔÙ Åݣ ÚÄÅÓØ ÓÉÄÉÛØ?

HZ>> HÁÌÉÞÉÅ ËÁËÉÈ-ÌÉÂÏ ÐpÁ×ÉÌ ×ÓÅÇÄÁ ÌÕÞÛÅ ÐÏÌÎÏÇÏ ÉÈ ÏÔÓÕÔÓÔ×ÉÑ.

DT> HÏ ÎÁÌÉÞÉÅ ÓÔpÏÇÉÈ ÐpÁ×ÉÌ Õ×ÅÌÉÞÉ×ÁÅÔ ÎÁģÖÎÏÓÔØ É ÂÅÚÏÐÁÓÎÏÓÔØ, ÞÔÏ DT> ×Ï ×ÓÔpÏÅÎÎÙÈ ÓÉÓÔÅÍÁÈ ËÕÄÁ ×ÁÖÎÅÅ, ÞÅÍ × ÏÆÉÓÅ É ÜËÓÅÌÅ...

çÅÏÒÇÉÊ

Maxim, ÔÙ Åݣ ÚÄÅÓØ ÓÉÄÉÛØ?

MP> íÎÅ ËÏÎÅÞÎÏ ÐÏÆÉÇÕ, ÎÏ ÄÌÑ ÍÅÎÑ DWORD/WORD/BYTE - ÜÔÏ 20 ÌÅÔ ËÁË MP> ÏÄÎÏÚÎÁÞÎÏ 32/16/8 ÂÉÔÎÙÅ ×ÅÌÉÞÉÎÙ. ñ ËÏÎÅÞÎÏ ÎÕÔÒÏÍ ÐÏÎÉÍÁÀ, ÞÔÏ MP> WORD/HALFWORD/BYTE × ÄÉÂÉÌØÎÙÈ ÁÒÈÉÔÅËÔÕÒÁÈ 32/16/8, ÎÏ ×ÏÔ ÕÍÏÍ MP> ÐÏÎÑÔØ ÎÅ ÍÏÇÕ, ÎÁÆÉÇ ÔÁËÏÊ ÚÏÏÐÁÒË ÎÕÖÅÎ.

int4 int8 int12 int16 int24 int32 ... uint4 uint8 uint12 uint16 uint24 uint32 ...

çÅÏÒÇÉÊ

Maxim, ÔÙ Åݣ ÚÄÅÓØ ÓÉÄÉÛØ?

MP> èÏÔÑ ×ÏÔ ×ÒÕ - × ÏÄÎÏÍ ÕÓÔÒÏÊÓÔ×Å 1 ÒÁÚ ÚÁ 5 ÌÅÔ ÞÅÒÔ ÅÇÏ ÚÎÁÅÔ ÉÚ ÚÁ MP> ÞÅÇÏ ÐÉË 870-Ê ÓÔÅÒÓÑ. òÁÚ×ÅÌ ÒÕËÁÍÉ - ÐÏÓÏ×ÅÔÏ×ÁÌ ÐÉËÉ ×ÚÑÔØ

çÅÏÒÇÉÊ

AM>> Определяется, но оно известо для данной коткретной платформы. GS>> Hе только платформы, но ещё и от конкретного _компилятора_. AM> Hе встречал разных компиляторов для одной платформы, чтобы у них были AM> разные размеры одних и тех же типов,

GS> Это не значит, что таких компиляторов не было.

Приведи примеры конкретных компиляторов.

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

GS> Весьма нетипичного для сишных программ, и всё равно не дающего GS> полных гарантий.

Сишные программы пишутся сами по себе? А я думал стиль определяется программистом.

AM> Hо в embedded - машинонезависимость не сама цель.

GS> К счастью, да.

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

GS> А человек, пытающийся понять сишную программу, не должен GS> как минимум знать си? ;)

Да, но один Си, а не 10 ассемблеров.

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

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

Мне как-то больше приходится писать свои.

GS> Hаиболее типичное GS> занятие такого рода - ковыряние в исходниках Linux.

Я не ковыряюсь.

GS> Ты считаешь, что все они выдержаны в "правильном" стиле?

Я их вообще в глаза не видел. Зачем они мне в embedded? Впрочем, я приведу контр пример, uCOS-II. Посмотри на сайте uCOS, под сколько процессоров портирована ОС, исходники ОС при этом не меняются, то есть машинонезависимость соблюдается в полной мере.

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

GS> С типичным. Который этот язык, к сожалению, провоцирует.

Чушь, подход определяется программистом, и может быть плох как на асм, так и на Си. Я реализую свои задачи, пользуясь определенным стилем, какое мне дело до того, что кто-то делает по другому?

AM> а к описанию алгоритма для достижения определенной цели.

GS> Алгоритма мало, поскольку при программировании на C весьма GS> часто используются "трюки".

Это определяется опять же стилем, Си не обязывает использовать какие-то трюки.

GS> AM> с _понятными_ именами переменных.

GS> Вида b, i и j ?

Для переменной цикла действительно часто i и j. Для других переменных

- свои ясно читаемые имена. Но это опять не имеет отношения к языку Си, а зависит от программиста.

GS> Весьма существенная часть программистов так любит экономить на GS> нажатии кнопок ;)

Давно пора приучиться говорить только за себя.

AM> Искодник будет в купе с тектовым описанием алгоритма AM> самодокументированным.

GS> Как правило - будет _недостаточно_ документированным. GS> Ибо строгое следование хорошему стилю программирования GS> требует дополнительных усилий от программиста (как правило GS> ленивого).

Говори только за себя, а не оценивай среднестатистического программиста. Я могу также сказать, что среднестатистический программист на асм делает куда более нечитаемый код, по сравнению с аналогичным программистом на Си

AM> памяти, но и килобайт, и мегабайт. А в эхотажных будет то, что я AM> привел.

GS> В эхотажных я наблюдал разницу в разы на процах i51 и PIC...

Каким компиялтором для х51 при этом пользовался?

AM>> Тем, что разглядывая код после Си я видел примерно то-же, что я бы AM>> написал на асме, GS>> Hу и что? AM> То, что в разы эффективенее написать невозможно.

GS> Для человека, который знает C заметно лучше, чем ассемблер - да. GS> Hо если привлечь специалиста по ассемблеру и грамотно сформулировать GS> задачу - будет гораздо эффективнее...

На 15%

AM>> на асме возможно чуть более оптимально, но и то не везде. GS>> Иногда можно написать эффективнее на порядок. Hа ассемблере. AM> Эти иногда - не более 1% кода.

GS> А иногда - 99% ;)

Такого не бывает.

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

GS> Побочные и нетривиальные действия.

Например?

Hi George.

DT> HÏ ÎÁÌÉÞÉÅ ÓÔpÏÇÉÈ ÐpÁ×ÉÌ Õ×ÅÌÉÞÉ×ÁÅÔ ÎÁģÖÎÏÓÔØ É ÂÅÚÏÐÁÓÎÏÓÔØ, ÞÔÏ DT> ×Ï ×ÓÔpÏÅÎÎÙÈ ÓÉÓÔÅÍÁÈ ËÕÄÁ ×ÁÖÎÅÅ, ÞÅÍ × ÏÆÉÓÅ É ÜËÓÅÌÅ...

GS> åÓÌÉ × "ÏÆÉÓÅ É ÜËÓÅÌÅ" ×ÅÄÕÔ ÄÅÌÏ×ÕÀ ÐÅpÅÐÉÓËÕ É ÆÉÎÁÎÓÏ×ÙÅ GS> ÏÔޣÔÙ - ÎÁģÖÎÏÓÔØ É ÂÅÚÏÐÁÓÎÏÓÔØ ÎÕÖÎÙ ÎÉÞÕÔØ ÎÅ ÍÅÎØÛÅ.

HÕ ÅÓÔÅÓÔ×ÅÎÎÏ, ×ÅÄØ ÔÕÔ ÐÏÄ ×ÏÐpÏÓÏÍ äåHøçé. é ×ӣ ÖÅ Ï ÉÓËÁÈ Ë ÍÉËpÏÓÏÆÔÕ Ñ ÞÔÏ-ÔÏ ÎÅ ÓÌÙÛÁÌ, Á ÇÌÀËÏ× × ÅÇÏ ÐpÏÄÕËÔÁÈ ÐÏÌÎÏ. åÓÌÉ ÔÁËÏÅ ÂÕÄÅÔ × embedded... :(

Dimmy.

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

AM> Определенные конструкции языка компилируются в определенный код.

GS> Да. Hо это вовсе не значит, что конкретная задача "хорошо ложится" GS> на "определённые конструкции языка". К примеру, у меня была задачка, GS> когда нужно было простеньким процем декодировать коды с внешнего GS> АЦП, выдавать их "наружу" по интерфейсу RS-232 и при этом непрерывно GS> генерировать на одном из выводов частоту тактирования АЦП. При GS> этом в процессоре не было ни аппаратного UART, ни чего-нибудь GS> наподобие ШИМ-генератора. Всё операции ввода-вывода приходилось GS> делать, подбирая задержки между исполнением команд программы GS> (в процессорных тактах). Удобно такая задачка подходит для GS> сишного программиста?

Не удобно, и что из этого вытекает? Что, что для PICов с 512 слов памяти вполне можно писать на асме. Изначально возможность применения асма при необходимости мной никогда и не отрицалась. Ты же вроде говорил про большие проекты, это кстати сколько, по твоему? У меня последние проекты на MB90F543 где-то под 100кбайт BIN кода. Таблиц практически нет.

AM> Реальные задачи состоят из набора контрукций языка.

GS> Угу. Что-то вроде "Hастоящие программисты пишут только на Фортране. GS> Даже если они пользуются Паскалем или Си" ;-)

Я что-то не так сказал? Тогда как решаются задачи по твоему?

AM> Поясни, почему с увеличением количества этих конструкций в проекте AM> код становится неоптимальным?

GS> Потому что ассемблер позволяет _создавать_ _подходящие_ для данной GS> задачи конструкции, а не приспосабливать к задаче фиксированный набор GS> конструкций данного языка. Конечно, существуют "высокоуровневые" GS> языки, позволяющие создавать "подходящие" конструкции, но это GS> выливается в громоздкость реализации...

Все это треп, типа "потому что потому, что кончается на У"

AM> Сделай сравнение двух переменных из RAM х51 оптимальнее, чем AM> MOV A,tx_idx AM> XRL A,save_idx AM> JZ ?C0003 AM> Именно в этот код компилируется оператор AM> if (tx_idx != save_idx) {...}

GS> А кто тебе сказал, что для решения конкретной задачи будет GS> оптимален именно этот оператор? ;)

Оптимален ли это код? На этот вопрос нельзя ответить, потому что этот код является частью другого кода, более сложного, который мы не знаем. Философствование вместо реальных дел.

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

AM> И не в пользу асма. AM> Разница какая?

GS> Hа маленьких примерах разницы может вообще не быть. Высокоуровневый GS> компилятор, который не в состоянии эффективно сгенерить десяток GS> машинных команд - мало кому нужен.

Как всегда, как пришло время реально подтвердить свои высказывания - прыг-скок в кусты.

AM> В общем, ты, как всегда остаешься бездоказательным.

GS> Hет, ты просто стараешься не замечать доказательств. Это, GS> как говорят в Одессе, две большие разницы ;)

Доказательства я получу, когда ты все продемонстрируешь на деле.

AM> Hа словах ты, как факир, ужимаешь код в 10 раз,

GS> Как профессионал. Hа практике. И не один раз.

Только не понятно, по сравнению с чем, ты ведь на Си не пишешь аналогичный код.

AM> которые тебе надо, чтобы это продемонстрировать.

GS> Я беру просто _реальные_ условия, в которых хорошо видны GS> отличия в использовании разных инструментов программирования.

Да, PIC с 512 слов и без таймеров.

AM> и компилятор дерьмовый,

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

Я выберу наиболее подходящий, впрочем они все более или менее похожи.

AM> и программиста на Си пахорукого.

GS> Передёргивать не надо. Когда о "неэффективности" ассемблера GS> пытаются судить люди, толком его не знающие - это ты GS> считаешь нормальным?

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

GS> Давай сравнивать работу в _равных_ условиях. Один программист GS> очень хорошо знает C, другой - не менее хорошо знает ассемблер GS> того процессора, на котором решается задача. Другие подходы GS> являются подтасовкой и ничего не доказывают.

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

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

GS> Ты снова зациклился на готовых алгоритмах, на которых, вполне GS> возможно, "вылизывались" оптимизации конкретных компиляторов.

Ты хотя бы просмотри, что в "Numerical Recipes in C" за алгоритмы. Может и выберешь какой.

GS> А ими отнюдь не исчерпывается набор реальных задач, _особенно_ GS> в эхотажном применении.

Да, в эхотажных еще по результатам выполнения алгорима нужно ножкой дернуть на порту или в UART результат передать (утрированно)

AM> Посчитаем оверхед по скорости и объему.

GS> Ты ещё помнишь АОH'ы? Сначала их делали на Z80, потом GS> перешли на i51. При этом код писали именно на ассемблере. GS> Как думаешь, почему не перешли на C, если он такой GS> замечательный, как ты рассказываешь?

Видимо у них была точка зрения такая же как у тебя, или попросу в то время (а где-то 90-92 год) возможно не было доступа к кросс-компиляторам Си или даже персоналкам, для разработки. Не удивлюсь, если АОН для Z80 писали и отлаживали на ZX.

AM> Если он будет 5 кратным - я съем свою шляпу и перейду на AM> ассемблер.

GS> Оставь свою шляпу в покое ;) Я вовсе не призываю всех GS> подряд бросать C и переходить на ассемблер. Это разные GS> языки, у которых разные области применения. И тот, и другой GS> ещё _очень_ долго будут использоваться, каждый в своей GS> "нише". Если у тебя хорошо получается писать программы GS> на C, обычно нет никакого смысла делать посредственные GS> программы на ассемблере. И наоборот.

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

GS> AM> К увеличению времени не приводит, потому что все это делается не в GS> AM> ран-тайме, а на этапе компиляции.

GS> Может приводить, причём к очень большому, если компилятор GS> будет эмулировать стек в ОЗУ, с помощью регистра-указателя GS> и косвенной адресации.

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

AM> К издержкам RAM не приводит, потому что память распределяется ровно AM> под то число переменных, которое было объявлено.

GS> Стек позволяет "убирать" неиспользуемые переменные. Создавая GS> для них место только тогда, когда они нужны.

Я говорю про компилированный стек, впрочем ты похоже не понимаешь о чем речь. В компилированном стеке нет стека в классическом его понимании, как LIFO.

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

GS> И ты гарантируешь, что компилятор не будет глючить при GS> "вложении" таких функций? Даже когда они будут выполняться GS> по нескольку штук в разных комбинациях? GS> Да ещё и при GS> любимом сишниками использовании "побочных эффектов" GS> от выполнения операций?..

Сто раз проверено, ничего не глючит. Алгоритмы распределения вполне прозрачны.

AM> В случае асм-а приходится выделять память под каждую переменную, даже AM> если они не мешают друг другу.

GS> Абсолютно не обязательно. Довольно типична операция, при которой GS> резервируется область "временных переменных", которые используются GS> для разных целей разными модулями программы. Это требует повышенного GS> внимания программиста или введения "хитрых приёмов", обеспечивающих GS> проверку, но принципиальной невозможности нет.

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

GS> При желании на ассемблере можно написать _абсолютно всё_, что GS> можно сделать на "высокоуровневом" языке.

Кто бы спорил, только затраты несопоставимы.

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

GS> Hа некорректные вопросы я не отвечаю. Попробуй сам на них ответить, GS> только не забывай, что список существующих процессоров не исчерпывается GS> той парочкой, о которых ты слышал, причём все они РАЗHЫЕ.

Слышал, к слову сказать я о гораздо большем числе процессоров, чем парочка. Реально работал на 7 типах, если точно помню. Активно - на 4-х.

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

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

Thursday January 22 2004 14:00, George Shepelev wrote to Andy Mozzhevilov:

AM>> ÐÏÔÏÍÕ ËÁË ÒÁÚÍÅÒÎÏÓÔØ ÔÉÐÏ× ÏÐÒÅÄÅÌÑÅÔÓÑ ÇÌÁ×ÎÙÍ ÏÂÒÁÚÏÍ ÓÁÍÉÍ AM>> ÑÄÒÏÍ, ÅÇÏ ÒÁÚÒÑÄÎÏÓÔØÀ. GS>

GS> ëÁËÁÑ ÒÁÚÒÑÄÎÏÓÔØ Õ ÑÄÒÁ x86? HÁÐÏÍÉÎÁÀ, × ÜÔÏÍ ÓÅÍÅÊÓÔ×Å ÓÕÝÅÓÔ×Ï×ÁÌÉ GS> embedded'ÎÙÅ ËÒÉÓÔÁÌÌÙ 80186/188, 80386, 80486...

AM>> üÔÏÔ ÞÅÌÏ×ÅË, ËÁË ÍÉÎÉÍÕÍ ÄÏÌÖÅÎ ÚÎÁÔØ ÁÓÓÅÍÂÌÅÒ, ÄÌÑ ÎÁÞÁÌÁ. GS>

GS> á ÞÅÌÏ×ÅË, ÐÙÔÁÀÝÉÊÓÑ ÐÏÎÑÔØ ÓÉÛÎÕÀ ÐÒÏÇÒÁÍÍÕ, ÎÅ ÄÏÌÖÅÎ GS> ËÁË ÍÉÎÉÍÕÍ ÚÎÁÔØ ÓÉ? ;)

AM>>> ôÅÍ, ÞÔÏ ÒÁÚÇÌÑÄÙ×ÁÑ ËÏÄ ÐÏÓÌÅ óÉ Ñ ×ÉÄÅÌ ÐÒÉÍÅÒÎÏ ÔÏ-ÖÅ, ÞÔÏ Ñ ÂÙ AM>>> ÎÁÐÉÓÁÌ ÎÁ ÁÓÍÅ, GS>>> HÕ É ÞÔÏ? AM>> ôÏ, ÞÔÏ × ÒÁÚÙ ÜÆÆÅËÔÉ×ÅÎÅÅ ÎÁÐÉÓÁÔØ ÎÅ×ÏÚÍÏÖÎÏ. GS>

GS> äÌÑ ÞÅÌÏ×ÅËÁ, ËÏÔÏÒÙÊ ÚÎÁÅÔ C ÚÁÍÅÔÎÏ ÌÕÞÛÅ, ÞÅÍ ÁÓÓÅÍÂÌÅÒ - ÄÁ. GS> HÏ ÅÓÌÉ ÐÒÉ×ÌÅÞØ ÓÐÅÃÉÁÌÉÓÔÁ ÐÏ ÁÓÓÅÍÂÌÅÒÕ É ÇÒÁÍÏÔÎÏ ÓÆÏÒÍÕÌÉÒÏ×ÁÔØ GS> ÚÁÄÁÞÕ - ÂÕÄÅÔ ÇÏÒÁÚÄÏ ÜÆÆÅËÔÉ×ÎÅÅ...

HÅ ÂÕÄÅÔ.

AM>>> ÎÁ ÁÓÍÅ ×ÏÚÍÏÖÎÏ ÞÕÔØ ÂÏÌÅÅ ÏÐÔÉÍÁÌØÎÏ, ÎÏ É ÔÏ ÎÅ ×ÅÚÄÅ. GS>>> éÎÏÇÄÁ ÍÏÖÎÏ ÎÁÐÉÓÁÔØ ÜÆÆÅËÔÉ×ÎÅÅ ÎÁ ÐÏÒÑÄÏË. HÁ ÁÓÓÅÍÂÌÅÒÅ. AM>> üÔÉ ÉÎÏÇÄÁ - ÎÅ ÂÏÌÅÅ 1% ËÏÄÁ. GS>

GS> á ÉÎÏÇÄÁ - 99% ;) GS>

AM>> é ÔÏ, ÅÄÉÎÏÖÎÙ ÐÏÓÍÏÔÒÅ×, ËÁËÁÑ ËÏÎÓÒÕËÉÃÑ óÉ ÌÏÖÉÔÓÑ ÏÞÅÎØ ÎÅ AM>> ÏÐÔÉÍÁÌØÎÏ ÎÁ ÜÔÏÔ ÐÒÏÃÅÓÓÏÒ, ÍÏÖÎÏ ×ÙÂÒÁÔØ ÄÒÕÇÕÀ É ÓÏËÒÁÔÉÔØ ËÏÄ, AM>> ÅÓÌÉ ÜÔÏ ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÎÕÖÎÏ. GS>

GS> ôÅÒÑÅÔÓÑ ÓËÏÒÏÓÔØ ÒÁÚÒÁÂÏÔËÉ, ÐÒÏÝÅ ÂÕÄÅÔ ÐÉÓÁÔØ ÎÁ ÁÓÍÅ, GS> ÉÎÏÇÄÁ ÄÅÌÁÑ ÔÅÓÔÏ×ÕÀ ËÏÍÐÉÌÑÃÉÀ ÓÐÏÒÎÙÈ ÍÅÓÔ ÎÁ C, ËÁË GS> Ñ ÕÖÅ ÏÐÉÓÙ×ÁÌ.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

Hello Dima.

HÁ×ÅpÎÏ ÓÐpÏÓ ÐÏpÏÖÄÁÅÔ ÐpÅÄÌÏÖÅÎÉÅ. äÉËÁpØ ÂÏÌØÛÅ ÏÃÅÎÉÔ ÓÔÅËÌÑÎÎÙÅ ÂÕÓÙ, ÞÅÍ ÔÏËÁpÎÙÊ ÓÔÁÎÏË, Á ÞÅÌÏ×ÅÞÅÓÔ×Ï ÚÁ ÔÙÓÑÞÉ ÌÅÔ ÎÅ ÉÚÍÅÎÉÌÏÓØ.

Sergey

Hello, George Shepelev !

HÒÁ×ÉÔÓÑ. öÏÒÁ × Ó×ÏÅÍ ÒÅÐÅÒÔÕÁÒÅ. åÓÌÉ ÂÙ ÔÙ ÐÏÐÒÏÂÏ×ÁÌ ÓËÏÍÐÉÌÉÒÏ×ÁÔØ ÔÏÔ ÂÒÅÄ, ÞÔÏ ÎÁÐÉÓÁÌ, ÔÏ ÐÏÌÕÞÉÌ ÂÙ

Error ..\EXAMPLES\1.C 10: Illegal use of floating point

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, George Shepelev !

Hello, Maxim Polyanskiy !

HÅ ÚÁÇÏÒÁÅÔÓÑ. åÓÌÉ ÁËËÁÍÕÌÑÔÏÒ ÕÂÉÔÙÊ, ÏÎ ÍÏÖÅÔ ÕÍÅÒÅÔØ ×ÏÔ ÔÁË ×ÏÔ ÓÒÁÚÕ. ðÏÛÅÌ ÞÅÌÏ×ÅË × ÓÕÐÅÒ, ÚÁÂÙÌ ÆÁÒÙ, ×ÅÒÎÕÌÓÑ - É ÏÐÁÎØËÉ.

HÁ ÒÕÌÅ ÏÂÙÞÎÏ ÚÁÍÏË ÍÅÈÁÎÉÞÅÓËÉÊ, Á ÉÍÍÏÂÉÌÁÊÚÅÒ ÎÅ ÄÁÅÔ ÒÁÂÏÔÁÔØ Ä×ÉÇÁÔÅÌÀ.

Hello, Maxim Polyanskiy !

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, Ilia Tarasov !

Hello, Ilia Tarasov !