AVR GCC&IAR

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

AG> äÒÕÇÏÇÏ ÍÅÔÏÄÁ ÐÒÏ×ÅÒËÉ, ËÒÏÍÅ ÔÅÓÔÉÒÏ×ÁÎÉÑ, ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÎÅ AG> ÐÒÏÇÌÑÄÙ×ÁÅÔÓÑ × ÏÂÏÚÒÉÍÏÍ ÂÕÄÕÝÅÍ.

HÅ ×ÉÄÉÍ ÏÞÅ×ÉÄÎÏÇÏ? åÓÔØ Åݣ ÔÝÁÔÅÌØÎÙÊ ÁÎÁÌÉÚ ÓÐÅÃÉÆÉËÁÃÉÊ É ÉÓÈÏÄÎÏÇÏ ËÏÄÁ, ÉÓÞÅÒÐÙ×ÁÀÝÁÑ ÐÏÍÏÄÕÌØÎÁÑ ÏÔÌÁÄËÁ ËÏÍÐÏÎÅÎÔ ÐÒÏÇÒÁÍÍÙ, ÓÉÓÔÅÍÎÁÑ ÏÔÌÁÄËÁ, ÁÎÁÌÉÚ ÒÁÂÏÔÙ × ÓÐÅÃÉÁÌØÎÏÍ ÓÉÍÕÌÑÔÏÒÅ.

AG> é ÔÅÓÔÙ (pardon ÚÁ ÂÁÎÁÌØÎÏÓÔØ) ÓÌÅÄÕÅÔ ÒÁÚÒÁÂÁÔÙ×ÁÔØ ÄÏÓÔÁÔÏÞÎÏ AG> ÔÝÁÔÅÌØÎÏ, ÏÄÎÏ×ÒÅÍÅÎÎÏ Ó ÒÁÚÒÁÂÏÔËÏÊ ÖÅÌÅÚÁ, ÆÉÒÍ×ÁÒÉ É (ÅÓÌÉ ÅÓÔØ) AG> ÓÏÆÔÁ.

AG> ïÄÎÁËÏ ÐÏ×ÔÏÒÀ ÅÝÅ ÒÁÚ - ÔÅÓÔÉÒÏ×ÁÎÉÅ ÎÅ ÍÏÖÅÔ ÄÏËÁÚÁÔØ AG> ÏÔÓÕÔÓÔ×ÉÑ ÏÛÉÂÏË × ÐÒÏÅËÔÅ.

AG> ô.Å. ÄÏËÁÚÁÔØ, ÞÔÏ × ÌÀÂÙÈ ÕÓÌÏ×ÉÑÈ, ÏÇÏ×ÏÒÅÎÎÙÈ × ôú, ÒÅÚÕÌØÔÁÔ AG> ÒÁÂÏÔÙ ÕÓÔÒÏÊÓÔ×Á ÂÕÄÅÔ ÐÒÁ×ÉÌØÎÙÍ.

çÅÏÒÇÉÊ

Hello, George Shepelev !

var a: integer; b: longint; begin b := a; end.

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

Hi Dima.

DO> óÉÛÎÙÊ enum - ÜÔÏ ÎÁÂÏp ÃÅÌÙÈ ÉÍÅÎÏ×ÁÎÎÙÈ ËÏÎÓÔÁÎÔ, Á ÎÅ DO> ÐÅpÅÞÉÓÌÉÍÙÊ ÔÉÐ ËÁË × ðÁÓËÁÌÅ É ÐÏÄÏÂÎÙÈ.

Dimmy.

Hi Dima.

DO> ðÏÍÎÉÔØ ËÁËÉÅ ËÏÍÁÎÄÙ ÎÁ ÎÉÈ ×ÌÉÑÀÔ Á ËÁËÉÅ ÎÅÔ.

Dimmy.

Hi Harry.

DT> ëÓÔÁÔÉ, pred, succ, high, low ÄÁÖÅ × C++ ÎÅ ÐÏÑ×ÉÌÏÓØ, Á ÄÌÑ enum DT> ÜÔÏ ÂÙÌÏ ÂÙ ÏÞÅÎØ ËÓÔÁÔÉ.

HZ> á ÜÔÏ ÞÔÏ?

- ÎÉÖÎÅÅ. é ÍÏÖÎÏ ÎÁÐÉÓÁÔØ, ÎÁÐpÉÍÅp:

for i := low(MyArray) to high(MyArray) do MyArray[i] := 0;

Dimmy.

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 может быть использован как под переменную А одной функции, так и под переменную Б другой. В случае асм-а приходится выделять память под каждую переменную, даже если они не мешают друг другу.

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

Wed, 21 Jan 2004 03:09:01 +0300 George Shepelev wrote to Harry Zhurov:

GS> ðÏÎÅÄÅÌØÎÉË ñÎ×ÁÒØ 19 2004 09:40, Harry Zhurov wrote to Yuriy K:

HZ>> HÕ, ÅÓÌÉ ÇÏÌÏ×Å ÂÏÌØÛÅ ÎÅÞÅÍ ÚÁÎÑÔØÓÑ, ËÒÏÍÅ ËÁË ÏÔÓÌÅÖÉ×ÁÔØ HZ>> ÇÒÁÂÌÉ ÏÔ ÍÁËÒÏÐÒÏÃÅÓÓÏÒÁ, ÔÁÍ, ÇÄÅ ÂÅÚ ÎÉÈ ÍÏÖÎÏ ÏÂÏÊÔÉÓØ, ÔÏ ÔÏÇÄÁ HZ>> ×ÏÚÒÁÖÅÎÉÊ ÎÅ ÉÍÅÀ.

GS> á ×ÏÔ ÏÔ ÇÒÁÂÌÅÊ ÏÔ ÉÄÉÏÔÓËÉÈ ËÏÎÃÅÐÃÉÊ Á×ÔÏÐÒÅÏÂÒÁÚÏ×ÁÎÉÑ GS> ÐÏ ÐÏ×ÏÄÕ É ÂÅÚ ÐÏ×ÏÄÁ - ÎÉËÁË ÎÅ ÏÂÏÊÔÉÓØ, ÉÓÐÏÌØÚÕÑ "ÌÕÞÛÉÊ GS> ÑÚÙË".

GS> þÔÏ-Ö, ÉÍÅÅÔÅ ÐÏÓÔÏÑÎÎÏÅ ÚÁÎÑÔÉÅ ÄÌÑ ÇÏÌÏ×Ù ;)

Hello, Dimmy Timchenko !

HÏ ÞÁÓÔÏ ÐÅÒÅÇÒÕÖÅÎÎÙÊ ÒÁÎÔÁÊÍÏ×ÙÍÉ ÐÒÏ×ÅÒËÁÍÉ É ÐÏ ÜÔÏÊ ÐÒÉÞÉÎÅ ÎÅÜÆÆÅËÔÉ×ÎÙÊ.

Hello, Dimmy Timchenko !

ðÒÏÂÌÅÍÁ × ÔÏÍ, ÞÔÏ ÄÌÑ ËÁÖÄÏÇÏ ËÏÎËÒÅÔÎÏÇÏ ÐÒÏÃÅÓÓÏÒÁ ÎÕÖÎÏ ÐÏÍÎÉÔØ ÎÁ ÞÔÏ ×ÌÉÑÀÔ ÔÅ ÉÌÉ ÉÎÙÅ ËÏÍÁÎÄÙ ËÏÎËÒÅÔÎÏ, Á ÎÅ ËÁË ÏÎÏ ÂÙ×ÁÅÔ ÏÂÙÞÎÏ.

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

Hello, Dimmy Timchenko !

ðÏÔÏÍÕ ÖÅ, ÐÏÞÅÍÕ ÎÅ ÒÅÁÌÉÚÕÀÔ áÄÕ ÎÁ ÍÉËÒÏËÏÎÔÒÏÌÌÅÒÁÈ. çÒÏÍÏÚÄËÏ ÓÌÉÛËÏÍ.

Hello, Vadik!

VA> é ÞÔÏ ÖÅ, ÐÏ-Ô×ÏÅÍÕ, ÍÏÔÏÒÏÌØÎÙÅ ÍÎÅÍÏÎÉËÉ (68k) ÚÁÓÉÒÁÀÔ ÍÏÚÇ É ÎÅ VA> Ñ×ÌÑÀÔÓÑ ÎÏÒÍÁÌØÎÙÍ ÒÅÛÅÎÉÅÍ? éÍÅÎÎÏ × ÍÏÔÏÒÏÌÁÈ ÜÔÏ ÏÞÅÎØ ÞÅÔËÏ ÐÏËÁÚÁÎÏ. ëÏÇÄÁ ÐÒÏÃÅÓÓÏÒÙ ÂÙÌÉ ÔÕÈÌÙÍÉ (6805) ÎÅ ÏÞÅÎØ ÔÏ ÓÌÏÖÎÏ ÂÙÌÏ ÎÅÓËÏÌØËÏ ÐÒÏÓÔÙÈ ×ÏÓØÍÉÂÉÔÎÙÈ ÏÐÅÒÁÃÉÊ ÚÁÐÉÓÁÔØ ÐÒÉÓ×ÏÉ× ËÁÖÄÏÊ Ó×ÏÀ ÍÎÅÍÏÎÉËÕ ËÏÔÏÒÁÑ ÓÏÄÅÒÖÉÔ ÚÁÞÁÓÔÕÀ ÅÝÅ ÁËËÕÍÕÌÑÔÏÒ. ðÏÔÏÍ ÞÉÓÌÏ ÒÅÇÉÓÔÒÏ× ÏÐÅÒÁÃÉÊ É ÍÎÅÍÏÎÉË Õ×ÅÌÉÞÉ×ÁÌÏÓØ ËÁË ÓÎÅÖÎÙÊ ËÏÍ. ÷ ÒÅÚÕÌØÔÁÔÅ × 68Ë ÍÙ ÉÍÅÅÍ ÒÅÁÌØÎÙÊ ÚÏÏÐÁÒË ÍÎÅÍÏÎÉË. HÁÐÒÉÍÅÒ ÔÅ-ÖÅ ÐÅÒÅÓÙÌËÉ ÐÁÍÑÔØ ÒÅÇÉÓÔÒ É ÒÁÇÒÕÚËÁ ÒÅÇÉÓÔÒÏ× ÓÔÁÔÉÞÅÓËÉÍÉ ÄÁÎÎÙÍÉ × 11-Í: LDAA,LDAB,LDAD,LDX,LDY,STAA STAB,STAD,STX,STY - 10 ÍÎÅÍÏÎÉË. ÷ ËÁÞÅÓÔ×Å ÁÒÇÕÍÅÎÔÁ ÁÄÒÅÓ ÉÌÉ ÉÎÄÅËÓ-ÒÅÇÉÓÔÒ, ÉÌÉ ÄÁÎÎÙÅ ËÏÔÏÒÙÅ × ÒÅÇÉÓÔÒ ÎÁÄÏ ÐÏÌÏÖÉÔØ... ÷ÒÏÄÅ ×ÓÅ ÎÏÒÍÁÌØÎÏ, ÎÅÔ ÎÉËÁËÉÈ ÐÒÏÂÌÅÍ, ËÏÍÐÁËÔÎÁÑ ÚÁÐÉÓØ, ÌÅÇËÏÅ ×ÏÓÐÒÏÉÚ×ÅÄÅÎÉÅ (ÅÓÌÉ ÎÉÞÅÇÏ ÄÒÕÇÏÇÏ ÎÅ ÚÎÁÅÛØ). ôÅÐÅÒØ ÐÒÅÄÐÏÌÏÖÉÍ ÞÔÏ Õ ÎÁÓ ÒÅÇÉÓÔÒÏ× ÓÔÁÌÏ ÒÅÚËÏ ÂÏÌØÛÅ É ÐÅÒÅÓÙÌËÉ ×ÏÚÍÏÖÎÙ ÍÅÖÄÕ ÎÉÍÉ, ÅÓÔÅÓÔ×ÅÎÎÏ ÎÁÍ ÎÁÄÏ ÕÄÁÌÉÔØ ÉÚ ÍÎÅÍÏÎÉËÉ ÎÁÚÁÎÉÅ ÒÅÇÉÓÔÒÁ. ïÓÔÁÎÅÔÓÑ ÏÓÎÏ×ÁÎÉÅ LD/ST. õÞÉÔÙ×ÁÑ, ÞÔÏ ÎÁÐÒÁ×ÌÅÎÉÅ ÐÒÉ 2-È ÁÒÇÕÍÅÎÔÁÈ ÚÁÄÁÎÏ ÞÅÔËÏ - ÏÓÔÁÅÔÓÑ ×ÏÏÂÝÅ ÅÄÉÎÓÔ×ÅÎÎÁÑ ËÏÍÁÎÄÁ LD! ïÄÎÁ ÅÄÉÎÓÔ×ÅÎÎÁÑ ÌÏÇÉÞÎÁÑ ËÏÍÁÎÄÁ ÐÅÒÅÓÙÌËÉ (Z80), ÎÕ ÎÁÐÒÉÍÅÒ × x86 ÜÔÏ ÂÕÄÅÔ MOV/LEA ÐÒÉÞÅÍ 2-Ñ ÉÎÓÔÒÕËÃÉÑ ÆÉÚÉÞÅÓËÉ ÎÅ ÎÕÖÎÁ É ÓÌÕÖÉÔ ÔÏÌØËÏ ÄÌÑ ËÏÍÐÁËÔÎÏÊ ÚÁÐÉÓÉ.. åÓÔØ ËÏÎÅÞÎÏ ÒÅÄËÏÉÓÐÏÌØÚÕÅÍÙÅ LES/LDS É ×ÓÑËÉÅ ÔÁÍ ÐÅÒÅÓÙÌËÉ Ó ÄÏÐÏÌÎÅÎÉÑÍÉ É ÏÂÒÅÚÁÎÉÑÍÉ MOVZX, ÎÏ ÐÏ ÓÕÔÉ ÏÎÉ ÐÒÏÓÔÏ ÅÓÔØ... ôÅÐÅÒØ ÓÍÏÔÒÉÍ ×Ï ÞÔÏ ÜÔÏ ÐÒÅ×ÒÁÔÉÌÏÓØ × 68Ë:

movea.l movem.l move.l moveq move.w move.b lea

VA> Bye... WBR! Maxim Polyanskiy.

Wed Jan 21 2004 03:04, George Shepelev wrote to Dimmy Timchenko:

DT>> ïÞÅÎØ ÎÅÕÄÏÂÎÏ, ËÏÇÄÁ ÎÅÔ ×ÏÚÍÏÖÎÏÓÔÉ ÚÁÄÁÔØ Ä×ÏÉÞÎÏÅ ÞÉÓÌÏ. ëÓÔÁÔÉ, DT>> × áÄÅ ÍÏÖÎÏ ÚÁÄÁ×ÁÔØ ËÏÎÓÔÁÎÔÙ ÐÏ ÌÀÂÏÍÕ ÐpÏÉÚ×ÏÌØÎÏÍÕ ÏÓÎÏ×ÁÎÉÀ. :)

GS> ëÓÔÁÔÉ, × æÏÒÔÅ - ÔÏÖÅ ÍÏÖÎÏ ÚÁÄÁ×ÁÔØ ÐÒÏÉÚ×ÏÌØÎÏÅ ÏÓÎÏ×ÁÎÉÅ ;) GS> é ÆÏÒÍÁÔ ×Ù×ÏÄÁ Á×ÔÏÍÁÔÉÞÅÓËÉ ÐÅÒÅËÌÀÞÁÅÔÓÑ ÎÁ ÜÔÏ ÏÓÎÏ×ÁÎÉÅ...

Wed Jan 21 2004 03:05, George Shepelev wrote to Ilia Tarasov:

IT>> á ÞÅÍ ðÁÓËÁÌØ ÔÁË ÕÖ ÏÔÌÉÞÁÅÔÓÑ ÏÔ óÉ?

GS> óÔÒÏÇÏÊ ÔÉÐÉÚÁÃÉÅÊ É ÏÔÓÕÔÓÔ×ÉÅÍ Á×ÔÏÐÒÅÏÂÒÁÚÏ×ÁÎÉÑ.

IT>> ÷ÓÅ ×ÙÛÌÉ ÉÚ áÌÇÏÌÁ... GS> HÅÚÁÍÅÔÎÏ ;) óÌÉÛËÏÍ ÓÉÌØÎÏ ÏÔÌÉÞÁÀÔÓÑ ÂÁÚÏ×ÙÅ ËÏÎÃÅÐÃÉÉ.

IT>> åÓÔØ ÒÁÚÎÙÅ ÚÁÄÁÞÉ É ÒÁÚÎÙÅ ËÒÉÔÅÒÉÉ. óÉ ÏÄÉÎ ÉÚ ÎÁÉÂÏÌÅÅ IT>> ÒÁÓÐÒÏÓÔÒÁÎÅÎÎÙÈ ÑÚÙËÏ×, ÜÔÏ ÄÁÎÎÏÓÔØ. GS> óÁÍÙÅ ÒÁÓÐÒÏÓÔÒÁΣÎÎÙÅ ÖÉ×ÙÅ ÓÕÝÅÓÔ×Á - ÐÒÏÓÔÅÊÛÉÅ. HÏ ÜÔÏ ÏÔÎÀÄØ GS> ÎÅ ÓÁÍÁÑ ÒÁÚÕÍÎÁÑ ÆÏÒÍÁ ÖÉÚÎÉ.

IT>> "÷ÓÅ ÄÅÊÓÔ×ÉÔÅÌØÎÏÅ ÒÁÚÕÍÎÏ..." GS> úÁËÌÉÎÁÎÉÑÍÉ ÄÅÌÕ ÎÅ ÐÏÍÏÖÅÛØ ;)

IT>> úÁÞÅÍ??? GS> þÔÏÂÙ ÐÏÌÕÞÉÔØ ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÍÁÛÉÎÏÎÅÚÁ×ÉÓÉÍÕÀ ÒÅÁÌÉÚÁÃÉÀ áÄÙ ;)

IT>> ðÉÓÁÔØ áÄÕ, ÞÔÏÂÙ ÐÏÔÏÍ ÄÅÌÁÔØ DSL _ÎÁ_ÎÅÊ_? GS> HÁ ÆÏÒÔÅ ÏÞÅÎØ ÞÁÓÔÏ ÐÉÛÕÔ "ÃÅÌÅ×ÙÅ ÑÚÙËÉ ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ". GS> éÈ ÓÌÏÖÎÏÓÔØ ÔÅÏÒÅÔÉÞÅÓËÉ ÎÅ ÏÇÒÁÎÉÞÅÎÁ.

HÏ ÒÅÁÌÉÚÁÃÉÑ áÄÙ ÎÁ æÏÒÔÅ × ÔÁËÏÍ ÓÌÕÞÁÅ ÂÕÄÅÔ ÐÏÈÏÖÁ ÎÁ "×ÙÌÉ×ÁÅÍ ×ÏÄÕ ÉÚ ÞÁÊÎÉËÁ, ×ÙËÌÀÞÁÅÍ ÇÏÒÅÌËÕ, Ó×ÏÄÑ ÔÅÍ ÓÁÍÙÍ ÚÁÄÁÞÕ Ë ÉÚ×ÅÓÔÎÙÍ ÎÁÞÁÌØÎÙÍ ÕÓÌÏ×ÉÑÍ". õÖÅ ÅÓÔØ ÍÅÈÁÎÉÚÍ ÒÁÚÂÏÒÁ ×ÈÏÄÎÏÇÏ ÔÅËÓÔÁ É ËÏÍÐÉÌÑÃÉÉ, ÚÁÞÅÍ ÇÏÒÏÄÉÔØ ÌÉÛÎÉÅ ÎÁ×ÅÓËÉ? áÄÁ - × ÏÓÎÏ×ÎÏÍ ÌÉÎÇ×ÉÓÔÉËÁ, Á ÎÅ ÖÅÌÅÚÏ, ÓÐÅÃÉÆÉËÁÃÉÑ ÐÉÓÁÌÁÓØ ÔÁË, ÞÔÏÂÙ ÎÁ ÜÔÏÍ ÑÚÙËÅ ÍÏÖÎÏ ÂÙÌÏ ×ÙÒÁÖÁÔØ ÎÅËÉÅ ÁÌÇÏÒÉÔÍÙ. ñÚÙË ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ ÍÏÖÅÔ É ÎÅ ÉÍÅÔØ ËÏÍÐÉÌÑÔÏÒÁ ÎÉ ÐÏÄ ÏÄÎÕ ÐÌÁÔÆÏÒÍÕ! á ÓÐÅÃÉÆÉËÁÃÉÑ ÁÓÓÅÍÂÌÅÒÏ× É ÉÍ ÐÏÄÏÂÎÙÈ ÑÚÙËÏ× ÏÓÎÏ×ÁÎÁ ÎÁ ÖÅÌÅÚÅ, ÄÌÑ ËÏÔÏÒÏÇÏ ÏÎÉ ÐÒÅÄÎÁÚÎÁÞÅÎÙ.

IT>> áÄÁ ×ÅÄØ ÔÏÖÅ ÎÅ ÉÚ ÎÉÞÅÇÏ ×ÚÑÌÁÓØ, ÔÒÁÎÓÌÑÔÏÒÙ ÓÅÊÞÁÓ ÐÉÛÕÔÓÑ × IT>> ÏÓÎÏ×ÎÏÍ ÌÉÂÏ ÎÁ ÁÓÍÅ, GS> õ×Ù, ÜÔÏ ÍÁÛÉÎÏÚÁ×ÉÓÉÍÁÑ ÒÅÁÌÉÚÁÃÉÑ.

HÕ ×ÏÎ ÅÓÔØ ÍÁÛÉÎÎÏÎÅÚÁ×ÉÓÉÍÁÑ Java. þÔÏ-ÔÏ ÌÅÇÞÅ ÎÅ ÓÔÁÌÏ...

IT>> HÁÐÉÓÁÔØ ÎÁ æÏÒÔÅ ÜË×É×ÁÌÅÎÔÎÙÅ ×ÅÝÉ × ÐÒÉÎÃÉÐÅ ×ÏÚÍÏÖÎÏ. IT>> ôÏÌØËÏ ÜÔÏ ÂÕÄÅÔ ÕÖÅ ÄÒÕÇÏÊ ÐÒÏÄÕËÔ. GS> åÓÌÉ ÔÏÞÎÏ ÓÏÂÌÀÓÔÉ ×ÓÅ ÓÐÅÃÉÆÉËÁÃÉÉ ÑÚÙËÁ - ÜÔÏ ÂÕÄÅÔ GS> ÎÕÖÎÙÊ ÐÒÏÄÕËÔ ;)

GS> òÅÞØ ÛÌÁ Ï ÔÏÍ, ÞÔÏÂÙ ÚÁÍÅÎÉÔØ "ÎÉÚËÏÕÒÏ×ÎÅ×ÙÊ" ÕÒÏ×ÅÎØ GS> Ó ÍÁÛÉÎÏÚÁ×ÉÓÉÍÙÈ ÁÓÓÅÍÂÌÅÒÎÙÈ ËÏÄÏ× ÎÁ ÓÔÒÏÇÏ ÚÁÄÁÎÎÕÀ GS> ×ÉÒÔÕÁÌØÎÕÀ ÍÁÛÉÎÕ, ÐÒÏÓÔÕÀ × ÒÅÁÌÉÚÁÃÉÉ.

IT>> ñ ÉÍÅÀ × ×ÉÄÕ ÕÓÒÅÄÎÅÎÎÙÊ ÌÉÓÔÉÎÇ, ÎÁÐÉÓÁÎÎÙÊ ÄÏÓÔÁÔÏÞÎÏ ÇÒÁÍÏÔÎÏ É Ó IT>> ÓÏÂÌÀÄÅÎÉÅÍ ÓÔÉÌÅ×ÙÈ ÒÅËÏÍÅÎÄÁÃÉÊ. GS> HÅ ÌÀÂÌÀ ÏÂÓÕÖÄÁÔØ "ÓÆÅÒÉÞÅÓËÉÈ ËÏÎÅÊ × ×ÁËÕÕÍÅ". óÌÉÛËÏÍ GS> ÂÏÌØÛÏÊ ÒÁÚÂÒÏÓ × ÒÅÁÌØÎÙÈ ÌÉÓÔÉÎÇÁÈ...

HÁ ÓÕÂßÅËÔÉ×ÎÏÓÔØ ÏÃÅÎËÉ ÍÏÖÎÏ ÍÎÏÇÏÅ Ó×ÁÌÉÔØ, ÎÏ ÏÔ ÜÔÏÇÏ ÎÅ ÌÅÇÞÅ.

Wed Jan 21 2004 17:09, Dima Orlov wrote to Dimmy Timchenko:

DO> HÏ ÞÁÓÔÏ ÐÅÒÅÇÒÕÖÅÎÎÙÊ ÒÁÎÔÁÊÍÏ×ÙÍÉ ÐÒÏ×ÅÒËÁÍÉ É ÐÏ ÜÔÏÊ ÐÒÉÞÉÎÅ DO> ÎÅÜÆÆÅËÔÉ×ÎÙÊ.

Hi Oleksandr.

DT> äÁ, ÚÎÁÀ ÔÁËÏÊ, ÈÏÔÑ ÓÁÍ ÎÅ ÐÏÌØÚÏ×ÁÌÓÑ. OR> á ÜÔÏÔ ÏÞÅÎØ ÎÅÐÌÏÈ É ×pÏÄÅ ÂÙ ÎÁ ÍÅÓÔÅ ÎÅ ÓÔÏÉÔ. [] OR> HÏ ÅÇÏ ÍÁËpÏ×ÏÚÍÏÖÎÏÓÔÉ ËÁË ÍÉÎÉÍÕÍ ÎÅ ÍÅÎØÛÅ aspic.

OR> ïÂÍÅÎÑÔØ ÍÅÓÔÁÍÉ Ä×Á pÅÇÉÓÔpÁ ÍÏÖÎÏ ÔÏÌØËÏ ÁÖ ÔpÅÍÑ ËÏÍÁÎÄÁÍÉ OR> eor Rd,Rs OR> eor Rs,Rd OR> eor Rd,Rs OR> ÐpÉޣÍ ÎÅÁÔÏÍÁpÎÏ :-(

OR> ×ÐÏÌÎÅ ÐpÉÍÅÎÉÍÏ

OR> in Rtemp, PORTB OR> eor Rtemp, Roldbuttons ; × Rtemp ÍÁÓËÁ ÉÚÍÅÎÉ×ÛÉÈÓÑ OR> eor Roldbuttons, Rtemp ; Á × Roldbuttons ÎÏ×ÏÅ ÚÎÁÞÅÎÉÅ

Dimmy.

Hello, Ilia Tarasov !

HÁÐÒÉÍÅÒ × ÎÁÌÉÞÉÉ × ðÁÓËÁÌÅ ×ÌÏÖÅÎÎÙÈ ÆÕÎËÃÉÊ É ÉÈ ÏÔÓÕÔÓÔ×ÉÉ × ó. ðÒÅÐÒÏÃÅÓÓÏÒÏÍ ÎÅ ÒÅÛÁÅÔÓÑ.

Hello, Ilia Tarasov !

HÅÌØÚÑ. åÓÌÉ ÐÅÒÅÍÅÎÎÏÊ ÚÁÄÁÎ ÄÉÁÐÁÚÏÎ 10..20, ×ÙÈÏÄ ÚÁ ÎÅÇÏ ÐÒÉ ÉÎËÒÅÍÅÎÔÅ ÍÏÖÎÏ ÐÒÏ×ÅÒÉÔØ ÔÏÌØËÏ × ÒÁÎÔÁÊÍ. þÅÍ É ÚÁÎÉÍÁÅÔÓÑ rtl × ÔÕÒÂÏ-ÐÁÓËÁÌÅ ÐÒÉ ×ËÌÀÞÅÎÎÏÍ ËÏÎÔÒÏÌÅ ÚÁ ÉÎÄÅËÓÁÍÉ × ÍÁÓÓÉ×ÁÈ.