ICC AVR и стpоки

Wed Sep 24 2003 18:34, Harry Zhurov wrote to Yuriy K:

HZ>>> Во-первых, при обращении к переменной, инкапсулированной в модуле HZ>>> (единице трансляции), придется либо делать ее открытой, либо вводить HZ>>> функцию доступа.

YK>> Либо вводить макрос-псевдофункцию для доступа

HZ> Вот именно, что псевдо!

Да хоть горшком назови, лишь бы работало.

YK>> и эмулировать пространства имен префиксами.

HZ> Hе смеши!

Убедительно. :) Hа самом деле разумное применение static и префиксов в программе помогает сделать ее сопровождаемой.

YK>> Пример: YK>> extern U8 rem_oops; YK>> #define rem_set_oops(val) (rem_oops = val) YK>> #define rem_get_oops() rem_oops YK>> Кстати, это будет эффективней чем С++.

HZ> Hе будет! Уверен, сам догадаешься, почему.

Да, inline поможет, убедил.

HZ> А ты, видимо, макросы любишь?

Hет. Просто иногда без них не обойтись.

YK>> Hе понял. Как это без потери эффективности? YK>> Для доступа к защищенной переменной на С++ придется использовать YK>> функцию - член класса. YK>> Для доступа к static переменной на С придется использовать функцию.

YK>> Где потеря эффективнсти?

HZ> А ты про inline функции что-нибудь слышал? Вот и подумай, есть HZ> разница между вызовом функции и встраиванием тела функции в точку вызова. HZ> HINT: встраиваемая функция ведет себя как макрос, только обеспечивает, в HZ> отличие от последнего, контроль типов, области видимости и проч.

Убедил, потери эффективности не будет. Выигрыша тоже. (inline vs. макрос).

Да, нет контроля типов и области видимости, это плохо, но совсем не смертельно.

HZ>>> В итоге получил под дюжину HZ>>> исходных файлов и примерно столько же заголовков. HZ>>> Проект тогда был около 8 кбайт (прошивка).

YK>> И всего-то дюжина файлов. :-))) YK>> 28 *.с + 5 *.asm + 38 заголовков для проекта на 16К кода. Hикаких YK>> проблем. IMHO это больше зависит от личных пристрастий программиста, не YK>> более того. Я, например, не могу сказать чей подход правильней.

HZ> 71 исходник!! Hа таком проекте!! Без комментариев!.. (Hе знаю, как в HZ> смайликах обозначается офигение)

Ж8-0, например :-) Hаверно и другие варианты есть.

HZ> Поди еще и батником собираешь?

IARской IDE. Впрочем можно было бы и батником, разница небольшая. Как справедливо заметил Редчук, в промежутках между компилированием и прошивкой полезно немного думать. :-Р Хотя обычно и лень...

HZ> И еще есть объективная причина: много мелких файлов плохо поддаются HZ> оптимизации, с которой компилятор хорошо справляется о. Особенно это заметно при HZ> оптимизации по размеру.

Мне размера флэша за глаза хватает. Пока запас есть раза в три-четыре, в новых контроллерах будет еще больше, т.к. надо переходить на новые MCU, где флеша меньше 64К не бывает.

HZ> И если уж тут проценты оверхеда плюсов вылавливают,

_Я_ не вылавливаю. Оверхед процентов в тридцать по скорости и два раза по размеру _меня_ волнует слабо. Критичные куски можно и на асме написать.

Вопрос в точности высказываний. Если сказано, что есть - надо доказать что есть. Если сказано, что нет - надо доказать что нет.

HZ>>> Таким образом, (возвращаясь к исходной точке обсуждения) на С можно HZ>>> пытаться проектировать программу в С++ном стиле только путем HZ>>> размножения исходных файлов, что тащит за собой неудобство в работе и HZ>>> оверхед.

YK>> Извини, но я не вижу ни неудобства, ни оверхеда.

HZ> Если 71 исходник на таком не очень большом проекте не вызывает HZ> неудобства, то комментарии излишни.

Еще раз. У _меня_ не вызывает. У кого-то может вызывать. Это характеристика программиста, а не подхода. Причем характеристика не "плохой-хороший", а просто "разный".

HZ> А оверхед возникает из-за вызова HZ> интерфейсных функций - во-первых, на вызов и возврат, во-вторых, если HZ> есть аргументы, то и на копирование аргументов, хоть это проявляется не HZ> всегда. Т.ч. С тут пролетает.

#define тебе поможет.

HZ>>> Поэтому реально, afaik, придерживаются компромисса - пытаются HZ>>> рассовать по файлам наиболее взаимосвязанное, стремясь минимизировать HZ>>> количество файлов.

YK>> Hе надо минимизировать число файлов. Места в директории всем хватит. :)

HZ> Любопытный критерий!

Дык!

YK>> P.S. Я ничего не имею против С++, хороший и полезный язык.

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

YK>> Hо и каких-либо особенных преимуществ по сравнению с _хорошо_ написанной ^^^^^^^^^^^^^^^^^^^^^ YK>> программой на С тоже не усматриваю.

HZ> Сколько программ ты написал на С++? Аналогичных тем, которые до этого HZ> писал на С? Hу, чтобы сравнивать/усматривать?

Hа микроконтроллеры - ни одной. Под РС - десяток-другой написал.

WBR, Юрий.

Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov on Tue, 23 Sep 2003 13:09:20

+0400:

AB> 22 Sep 03 20:44, you wrote to me:

HZ>>>> вполне работоспособен, хотя это и грязный хак, имхо. С не-POD HZ>>>> типом такое не пройдет. AB>>> Почему? HZ>> Что почему? Почему грязный хак?

AB> Вообще-то я спрашивал почему не пройдет.

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

HZ>> Да потому, что действует в обход HZ>> системы типов и компилятор тут не может проверить соответствует ли HZ>> адресуемая память типу объекта, к которому приводится.

AB> В приведенном тобой примере - пройдет.

HZ>> И в случае HZ>> неправильного приведения получишь безобразный баг во всей красе.

AB> Hо ты сделал правильное приведение, не так ли?

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

...so long!

### Пришлите четыре крышечки от унитаза, и вы получите бесплатный рулончик туалетной бумаги.

Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov on Tue, 23 Sep 2003 13:26:52

+0400:

[...]

AB> Hа классах есть только один способ и оптимизировать там нечего. Только на AB> компилятор приходится надеятся.

С чего ты это взял?

AB>>> А в Си inline отменили? HZ>> А в Си inline не было от рождения! Только сейчас в С99 его, вроде HZ>> бы, включили. То, что это есть в любимом GCC,

AB> Повезло мне. А что в ИАР С нету inline?

В ИАР, как и положено сишному компилятору, встраиваемых функций нет.

...so long!

### Брюки важнее жены, потому что существует немало мест, куда можно пойти без жены.

Yuriy K wrote to Harry Zhurov on Tue, 23 Sep 2003 17:24:31 +0400:

[...]

HZ>> Т.е. сделать именно то, что на ++ получается нативно. HZ>> И после этого еще не считать ++ную модель лучшей, чем сишную!

YK> Стоп, стоп, стоп. Если мы хотим сравнивать С++ и С, то надо сравнивать YK> _аналогичные_ подходы.

HZ>> Hо и тут при таком подходе в С два недостатка.

HZ>> Во-первых, при обращении к переменной, инкапсулированной в модуле HZ>> (единице трансляции), придется либо делать ее открытой, либо вводить HZ>> функцию доступа.

YK> Либо вводить макрос-псевдофункцию для доступа

Вот именно, что псевдо!

YK> и эмулировать пространства имен префиксами.

Не смеши!

YK> Пример:

YK> --------------------------------------- YK> "rem.h" YK> --------------------------------------- YK> extern U8 rem_oops; YK> #define rem_set_oops(val) (rem_oops = val) YK> #define rem_get_oops() rem_oops YK> --------------------------------------- YK> --------------------------------------- YK> "rem.c" YK> --------------------------------------- YK> U8 rem_oops; YK> --------------------------------------- YK> --------------------------------------- YK> "bla-bla-bla.c" YK> --------------------------------------- YK> if(!rem_get_oops() && is_it_good_time()) YK> { YK> rem_set_oops(OOPS_TIME); YK> } YK> --------------------------------------- YK> Кстати, это будет эффективней чем С++.

Не будет! Уверен, сам догадаешься, почему.

А ты, видимо, макросы любишь?

HZ>> ++ предоставляет простой и логичный способ достичь защищенности HZ>> без потери эффективности.

YK> Hе понял. Как это без потери эффективности? YK> Для доступа к защищенной переменной на С++ придется использовать YK> функцию - член класса. YK> Для доступа к static переменной на С придется использовать функцию.

YK> Где потеря эффективнсти?

А ты про inline функции что-нибудь слышал? Вот и подумай, есть разница между вызовом функции и встраиванием тела функции в точку вызова. HINT: встраиваемая функция ведет себя как макрос, только обеспечивает, в отличие от последнего, контроль типов, области видимости и проч.

HZ>> Во-вторых, и в-главных, такой подход красиво выглядит для таких HZ>> достаточно больших и законченных модулей, как описанный UART, когда для HZ>> него можно выделить отдельный файл. А что делать, когда модулей много и HZ>> они не такие крупные и функционально законченные? Каждому отдельный файл?

YK> Да. Я именно так и делаю.

HZ>> Делал я так! Именно пытался растолкать модули по разным файлам, помещая в HZ>> каждый не более двух-трех (в среднем). В итоге получил под дюжину HZ>> исходных файлов и примерно столько же заголовков. HZ>> Проект тогда был около HZ>> 8 кбайт (прошивка). Впоследствии этот же проект развивался далее, и HZ>> программа была переписана под ... Все удобно разместилось в трех файлах HZ>> при размере (прошивки) около 12 кбайт.

YK> И всего-то дюжина файлов. :-))) YK> 28 *.с + 5 *.asm + 38 заголовков для проекта на 16К кода. Hикаких проблем. YK> IMHO это больше зависит от личных пристрастий программиста, не более того. YK> Я, например, не могу сказать чей подход правильней.

71 исходник!! На таком проекте!! Без комментариев!.. (Не знаю, как в смайликах обозначается офигение)

Поди еще и батником собираешь?

И еще есть объективная причина: много мелких файлов плохо поддаются оптимизации, с которой компилятор хорошо справляется (отыскивание похожих кусков, использование одинаковых прологов/эпилогов и проч.), т.к. на малом размере и оптимизировать нечего. Особенно это заметно при оптимизации по размеру. И если уж тут проценты оверхеда плюсов вылавливают, то потеря эффективности оптимизации из-за сильной фрагментации проекта даст проигрыш не меньший (но оверхедом это не считается - такие вот критерии оценки).

HZ>> Таким образом, (возвращаясь к исходной точке обсуждения) на С можно HZ>> пытаться проектировать программу в С++ном стиле только путем размножения HZ>> исходных файлов, что тащит за собой неудобство в работе и оверхед.

YK> Извини, но я не вижу ни неудобства, ни оверхеда.

Если 71 исходник на таком не очень большом проекте не вызывает неудобства, то комментарии излишни. А оверхед возникает из-за вызова интерфейсных функций - во-первых, на вызов и возврат, во-вторых, если есть аргументы, то и на копирование аргументов, хоть это проявляется не всегда. Т.ч. С тут пролетает.

[...]

HZ>> Поэтому реально, afaik, придерживаются компромисса - пытаются HZ>> рассовать по файлам наиболее взаимосвязанное, стремясь минимизировать HZ>> количество файлов.

YK> Hе надо минимизировать число файлов. Места в директории всем хватит. :)

Любопытный критерий!

YK> Hадо названия давать осмысленные.

По любому не без этого. Только это само по себе непростая задача - выбор удачных имен, - и префиксно/постфиксные схемы ее только усложняют на пустом месте.

HZ>> Hо и того формализованного способа проектирования, который возможен в HZ>> С++, тут уже нет! О чем и речь.

YK> Да, заставить программистов писать код правильно - непростая задача, увы.:( YK> Возможно с применением классов это сделать проще, хотя и не факт

YK> P.S. Я ничего не имею против С++, хороший и полезный язык. YK> Hо и каких-либо особенных преимуществ по сравнению с _хорошо_ написанной YK> программой на С тоже не усматриваю.

Сколько программ ты написал на С++? Аналогичных тем, которые до этого писал на С? Ну, чтобы сравнивать/усматривать?

...so long!

### ""Хоть одним глазком взгляну на Париж..." - мечтал Кутузов." (с) из школьного сочинения.

Hello, Harry Zhurov !

Даже если это и так (в чем я лично ну очень сомневаюсь), переносимость C++ программы на другой кристалл гораздо ниже чем С по той причине, что С есть для всех, а С++ по сути только для AVR.

Она не хуже, но она в несколько раз дороже стоит...

С уважением, Дима Орлов.

23-Sep-03 14:26 Alexey Boyko wrote to Oleksandr Redchuk:

HZ>>> 9100.... LDS R16,(slon + 2) HZ>>> 2300 TST R16 HZ>>> F031 BREQ ??main_0 OR>> В C-шном варианте это выглядело бы как OR>> rcall SlonIsTrue OR>> tst r16 OR>> breq OR>> либо call для мега16 и выше. Т.е. inline не короче. OR>> А если там проверка битового флага в поле, то инлайновый вариант OR>> ещё толще будет.

AB> А если подумать? [...] AB> А во вторых, ты не учел тот факт, что вызов функции сразу же делает AB> невалидными половину регистров, в которых могло быть что-то полезное AB> и потребует повторную загрузку. Ой, ну да, это я сильно привык к KeilC51 global register optimisation :-) В этих условиях привычные #define (вместо inline) оказалось в очень многих случаях выгодно заменить на подпрограммы, возвращающие результат проверки в carry (кстати, было бы весьма неплохо и для AVR - в C или в T возвращать bit_bool :-). Так что в данном случае надо уточнять "по месту".

AB> Можно, конечно, попробовать сделать функцию просто static, и проверить AB> будет ли компилятор смотреть, какие регистры портит вызываемая функция. Кажется, пока не умеет. Да, точно не умеет - в одном месте два уарта (аппаратный и софтовый) вызывают из обработчиков прерываний подпрограммы заталкивания байта в буфер (с раскруткой SLIP) и взятия следующего байта бля передачи (с подстановкой SLIP). Подпрограммы объявлены выше обработчиков как static и сам больше никого не вызывают. Обработчики делают push/pop всем регистрам, которые имеет право испортить "обычная" подпрограмма, хотя на самом деле там и половины их не испорчено.

wbr,

23-Sep-03 13:14 Harry Zhurov wrote to Oleksandr Redchuk:

HZ>>> void uartInit(BYTE* Rx_buf, HZ>>> BYTE Rx_size, HZ>>> BYTE* Tx_buf, HZ>>> BYTE Tx_size, HZ>>> BYTE Baud_rate); OR>> Я не понял - почему тут куча параметров, а у конструктора OR>> ниже только baud rate? Значит, это _разные_ по поведению OR>> системы, если там конструктор распределяет себе буфера по своему OR>> усмотрению.

HZ> По функциональности одинаковые. Просто в сишном варианте все сделано Нет. Разные. В С-шном варианте с самого "пользовательского" уровня можно произвольно задать размещение и размер буферов, а в C++ - ном эти вещи забиты где-то внутри реализации.

HZ> традициях С: работа с аппаратным UART'ом, кольцевые буфера, функциональность HZ> протокола обмена пакетами и прочее "живет" отдельно, и весь модуль HZ> представляет HZ> собой конгломерат этих частей. В плюсатом варианте все эти детали HZ> инкапсулированы внутри класса. Соответственно, на С вызывается функция, Точно так же инициализацию буферов фиксированного размера можно сделать внутри С-шной функции и передавать ей только скорость. Или у тебя конструктор через 4-е измерение догадывается, гди и какого размера ты хотел сделать буфера. Нет? Фиксированные распределяет? Ну тогда и C-шному разреши фиксированные распределять.

HZ>>> BYTE UART_block_buf[BLOCK_BUFFER_SIZE]; OR>> Опять - в "классовой" версии буфер из воздуха взялся? OR>> Всё равно где-то кто-то его распределяет.

HZ>>> что нужно держать в голове) не выглядит "исчезающе малой"!!! OR>> Ну так не показывай наружу всё! OR>> На то и существует static в C, чтобы видимость имён ограничить OR>> файлом, в котором они заданы.

HZ> Все это так. И в данном случае, это, конечно, выход для С. И все это HZ> (объявление внутренних программных элементов статическими) попытка HZ> сделать по ++ному. :-))))))))))))))))))))))))))))) Ну извини, развеселил. Если в C объявление как static переменных и функций, которые НЕ НУЖНО показывать наружу - это "попытка сделать по ++ному", то тогда мне только остаётся сказать, что в C++ то, что по умолчанию все члены класса - закрытые, это попытка сделать по-ассемблерному, так как там если не сказано по поводу метки public, то она невидима за пределами файла.

HZ> Т.е. сделать именно то, что на ++ получается нативно. И после HZ> этого еще не считать ++ную модель лучшей, чем сишную! И необходимость писать в классах слова private - это то, что на ассемблере получается нативно.

HZ> Таким образом, (возвращаясь к исходной точке обсуждения) на С можно HZ> пытаться проектировать программу в С++ном стиле только путем размножения HZ> исходных файлов, что тащит за собой неудобство в работе и оверхед. Если Это не есть "попытка проектировать в C++ном стиле".

OR>> Да нет, если стековый кадр нужен, то в прологе порождается OR>> frame pointer на Y и дальше всё "как обычно". Если стековый кадр не OR>> нужен, то Y используется как хочется.

HZ> А как тогда быть с прерываниями? Т.е. вот вошли в функцию, скопировали HZ> SP в HZ> Y, начали использовать Y, и тут - бац! - прерывание! Какой поинтер будет HZ> использоваться в прерывании? Если прерыванию надо, то оно себе сделает, если не надо - делать не будет. Не понимаю, в чём проблемы, что тебе непонятно. Это аналогично push bp / mov bp,sp / sub sp,8 на 80x86, вместо bp идёт Y, sp как sp.

HZ>>> остальной части абзаца комментарий следующий: HZ>>> В энный раз повторяю: все зависит от конкретных условий!!! OR>> О чём и разговор - в огромном количестве "конкретных условий" OR>> за C++ могут быть только два аргумента - "не сбивать руку" OR>> и "очень уж эта мысля понравилась". Остальные расписания "плюсов плюсов" OR>> как-то мало в тех "конкретных условиях" дают.

HZ> Кому как... Но поскольку все уже высказались, то и... закончим, HZ> пожалуй?! Фф-ф-у-у-ухххх :-)

HZ>>> передаче более двух, то это уже повод задуматься о том, нет ли ошибки HZ>>> проектирования; OR>> memcpy(dst, src, len);

HZ> Весьма нечастая низкоуровневая библиотечная функция. Количество ее EEwrite( offset, *pbuf, len); // EEread, EEverify RTCwrite( offset, *pbuf, len); // read, vеrify SendPacket(type, *pdata, len); DisplayInt(position, value, digits); // это у меня для 7-сегментника CompareDates( struct date *da, struct date *db, u08 len); (сравнение дат на раньше/равно/позже, len - это глубина сравнения -- год, год и месяц, .... до секунд включительно, _одним_ operator< эту функцию не заменить). fseek(*stream, offset, whence) fwrite(*ptr, itemsize, items, *stream), в конце концов.

HZ> неприемлемо для низкоуровневого кода). При прочих равных ей лучше HZ> предпочесть HZ> нечто более высокоуровневое и безопасное вроде операторов присваивания Угу. Остаётся только забабахать EEstream << pos(offset) << record; и для каждого типа записей в EEPROM написать отдельный operator<< Спасибочки.

HZ>>> если больше трех, то это причина задуматься о том же; OR>> AT45D_write( chip_no, offset, buf, len);

HZ> Да, а у меня:

HZ> TDataFlash::ReadBuffer(word addr, byte N); HZ> TDataFlash::ReadMemory(word PageAddr, word ByteAddr); Ты тут сделал как бы с двумя аргументами, но либо это синглет для работы с одним чипом (и эти функции могут быть даже статические), либо (я-то говорил про несколько чипов!) на каждый чип надо заводить экземпляр класса и chip1.ReadBuffer() и один из аргументов функции таки приписан слева.

HZ> А если два чипа, то и тем более классы рулят! :) Заводишь два HZ> объекта, при И вместо того, чтобы передать в функцию доступа индекс чипа (один байт) и не заводить никаких переменных в ОЗУ -- передавать в функцию доступа указатель (this. не ты, не ты. компилятор. но код всё равно есть) на объект в ОЗУ, который там надо ещё завести.

HZ> Блин, я с этой дискуссией никак не могу толком взяться за изучение HZ> gcc (известно для чего ;-)) :-))) Мне тоже есть что делать, кстати :-)

wbr,

23-Sep-03 12:50 Boris Popov wrote to Oleksandr Redchuk:

BP> -O2 -Wa,-ahlms=gcc161/main.lst BP> -g -mmcu=atmega161 -W -Wall -Wstrict-prototypes -funsigned-char BP> -funsigned-bitfields -fpack-struct -fshort-enums -finline-functions А зачем ты ему на автомате разрешил решать -- какие функции инлайнить? Он при этом достаточно большие функции начинает инлайнить и при этом если они не объявлены как static -- ещё и не-inline копию оставляет. Проверь это место.

BP> GCC(1) параметры указанные выше, GCC(2) без -finline-functions. BP> Весь проект собранный GCC(1)/-Os - 17638, GCC(2)/-Os - 19442.

BP> Действительно, при оптимизации по размеру (ИАР оптимизировал BP> по скорости), соотношение намного лучше - 1.15. На досуге попробую BP> посмотреть, что еще можно поправить в коде или подкрутить в опциях.

Немного игрался.

-fnew-ra -- иногда уменьшает объём кода. Иногда сильно увеличиват. детально не исследовалось.

-fno-reorder-blocks -- как это ни странно, но в одном проекте 20 байт на фоне ~3KB уело. при том, что IAR на этом проекте давал всего байт

100 выиграша (1 файла с -s9, 2файла с -z9).

В этом проекте для gcc стоит -mcall-prologues, который ещё байт 50 экономит за счёт "вызова" подпрограмм для создания/удаления стекового кадра. Кстати, для SIGNAL()-функций он автоматически не использует call-prologues, несмотря на этот ключ, поэтому не нужно было указывать специальные ключи для файла с обработчиками прерываний (OC1A, ADC, UART), как для IAR.

Остальное практически не влияло (ничего не добавляло к -O2).

wbr,

22-Sep-03 13:40 Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov:

OR>>> Я таки попробую (исключительно из любопытства) плюсы если не на OR>>> AVR, то на MSP HZ>> А что, для него уже оно появилось? G++, в смысле?

AB> Если ты не в курсе, то кодогенертор в gcc не знает ни про Си, ни про AB> Си++. AB> Он преобразует из некоторого абстрактного языка в ассемблер. Так что AB> если AB> написан кодогенератор для msp-430, то Си++ появляется как бы автоматически. AB> Hужно только в библиотеке некоторую поддержку дописать. Ну вот она-то, насколько я знаю, ещё и не написана.

HZ>> Еще мне гораздо комфортнее когда доступ к переменной из другого HZ>> файла делается не прямым обращением к ней, а с помощью функции, HZ>> определяющей конкретное действие. Только на С будет оверхед на вызов, HZ>> а в плюсах эту функцию просто делаешь инлайновой.

AB> А в Си inline отменили? Ещё не все C-компиляторы для однокристалок поддерживают C99, в котором, afaik, inline появился. IAR C (не C++) про inline ничего не слышал.

HZ>> Про шаблоны и говорить нечего.

AB> Возьми avr-gcc. Только, насколько я помню - WinAvr с avrfreaks не собран AB> с Си++, так что придется самому собирать. Не с avrefreaks, а с winavr.sourceforge.net Уже с год как с C++ идёт.

wbr,

22-Sep-03 12:31 Alexey Boyko wrote to Oleksandr Redchuk:

OR>>>> void UartInit(void) __attribute__ ((section(".init3"))) OR>>>> __attribute__ ((naked)); HZ>>> Т.е. нестандартные расширения? OR>> Да, нестандартные. OR>> Hо одинаковые для avr-gcc, msp430-gcc, arm-gcc, ..... :-)

AB> Ты уверен?

AB> То есть __attribute__ ((section)) есть во всех, Я это и имел ввиду -- нестандартные расширения языка.

AB> а вот секции .init[0..9] AB> есть только в avr-gcc, причем появились не так давно. А это касается запускалки.

AB> А arm-gcc вообщем-то сделан для arm-linux, а не для микроконтроллеров, и AB> стартап, мне например, пришлось вообще свой писать. И если тебе захочется, ты в запускалке себе сделаешь .init[0..9] и из C будешь распихивать инициализационный код куда надо. Разве не так?

wbr,

В статье snipped-for-privacy@p4.f.n4624.z2.ftn> Alexey Boyko написал(а):

Нет, с моим кодом.

результаты 'wc -l соответсвующие-исходники' в студию.

Во 1-х, это зависит от целевой платформы, во 2-х, хоть я и провожу аналогию между поддержкой C++ для модулей ядра линукс и настоящей вделанной платформой, они все-таки отличаются. в 3-х, в отличие от g++, в случае ядра линукс, нужно прилагать немало усилий для обхода ограничений этой среды, использованию C++ активно сопротивляющейся, а потому там около половины объема исходников занимают всякие макросы и условия.

Oleksandr Redchuk wrote to "Harry Zhurov" snipped-for-privacy@online.nsk.su> on Wed, 24 Sep 2003 14:52:16 +0000 (UTC):

[...]

HZ>> Т.е. сделать именно то, что на ++ получается нативно. И после HZ>> этого еще не считать ++ную модель лучшей, чем сишную! OR> И необходимость писать в классах слова private - это OR> то, что на ассемблере получается нативно.

В классах писать private не надо - объявляешь приватное сразу, потом пишешь public для открытого и вуаля. :) Т.ч. все нативно. :))

[...]

HZ>> А как тогда быть с прерываниями? Т.е. вот вошли в функцию, скопировали HZ>> SP в HZ>> Y, начали использовать Y, и тут - бац! - прерывание! Какой поинтер будет HZ>> использоваться в прерывании? OR> Если прерыванию надо, то оно себе сделает, если не надо - делать не OR> будет. Не понимаю, в чём проблемы, что тебе непонятно.

Мне не понятно вот что: зашли в функцию, скопировали SP в Y, начали с ним работать - разместили в этой памяти локальные объекты, Y, ессно, модифицировался - TOS "уплыл" от исходного значения SP на величину размера локальных объектов + место под адрес возврата на случай прерывания/вызов функции. Теперь возникает прерывание, на входе снова берется SP и копируется в Y, и по той же схеме используется память стека. Но это та же самая память, которая уже используется в прерванной функции!? Вот если использовать для прерываний отдельный стек, то тогда, вроде, должно получиться.

[...]

HZ>> неприемлемо для низкоуровневого кода). При прочих равных ей лучше HZ>> предпочесть HZ>> нечто более высокоуровневое и безопасное вроде операторов присваивания OR> Угу. Остаётся только забабахать OR> EEstream << pos(offset) << record; OR> и для каждого типа записей в EEPROM написать отдельный operator<<

Зачем же так извращаться? :) У тебя же не этот убогий ЕС++, а нормальный С++ - один раз пишешь шаблон, и для любого нужного типа инстанцируешь объект. :))

OR> Спасибочки.

Welcome! :)))

...so long!

### Этот газ вызывает головные боли в мышцах и костях.

24-Sep-03 17:59 Harry Zhurov wrote to Oleksandr Redchuk:

HZ>>> SP × HZ>>> Y, ÎÁÞÁÌÉ ÉÓÐÏÌØÚÏ×ÁÔØ Y, É ÔÕÔ - ÂÁÃ! - ÐÒÅÒÙ×ÁÎÉÅ! ëÁËÏÊ ÐÏÉÎÔÅÒ ÂÕÄÅÔ HZ>>> ÉÓÐÏÌØÚÏ×ÁÔØÓÑ × ÐÒÅÒÙ×ÁÎÉÉ? OR>> åÓÌÉ ÐÒÅÒÙ×ÁÎÉÀ ÎÁÄÏ, ÔÏ ÏÎÏ ÓÅÂÅ ÓÄÅÌÁÅÔ, ÅÓÌÉ ÎÅ ÎÁÄÏ - ÄÅÌÁÔØ ÎÅ OR>> ÂÕÄÅÔ. îÅ ÐÏÎÉÍÁÀ, × ?Í ÐÒÏÂÌÅÍÙ, ÞÔÏ ÔÅÂÅ ÎÅÐÏÎÑÔÎÏ.

HZ> íÎÅ ÎÅ ÐÏÎÑÔÎÏ ×ÏÔ ÞÔÏ: ÚÁÛÌÉ × ÆÕÎËÃÉÀ, ÓËÏÐÉÒÏ×ÁÌÉ SP × Y, ×ÙÞÌÉ ÉÚ SP ÒÁÚÍÅÒ ÌÏËÁÌØÎÙÈ ÐÅÒÅÍÅÎÎÙÈ HZ> ÎÁÞÁÌÉ Ó ÎÉÍ ÒÁÂÏÔÁÔØ -

HZ> ÆÕÎËÃÉÉ. ôÅÐÅÒØ ×ÏÚÎÉËÁÅÔ ÐÒÅÒÙ×ÁÎÉÅ, ÎÁ ×ÈÏÄÅ ÓÎÏ×Á ÂÅÒÅÔÓÑ SP É õÖÅ ÍÏÄÉÆÉÃÉÒÏ×ÁÎÎÏÅ ÉÌÉ, ÅÓÌÉ ÎÅ ÍÏÄÉÆÉÃÉÒÏ×ÁÎÎÏÅ (ÎÅ ÕÓÐÅÌÉ), ÔÏ É ÐÅÒÅÍÅÎÎÙÅ × ÔÏÊ ÏÂÌÁÓÔÉ Å? ÎÅ ÒÁÚÍÅÝÅÎÙ.

HZ> Y, É ÐÏ ÔÏÊ ÖÅ ÓÈÅÍÅ ÉÓÐÏÌØÚÕÅÔÓÑ ÐÁÍÑÔØ ÓÔÅËÁ. îÏ ÜÔÏ ÔÁ ÖÅ ÓÁÍÁÑ HZ> ÐÁÍÑÔØ, ËÏÔÏÒÁÑ ÕÖÅ ÉÓÐÏÌØÚÕÅÔÓÑ × ÐÒÅÒ×ÁÎÎÏÊ ÆÕÎËÃÉÉ!? ôÙ ÞÔÏ, Å? ÎÅ ÒÁÚÂÉÒÁÌÓÑ ËÁË ÜÔÏ ÓÄÅÌÁÎÏ Õ MSP Ó ÏÄÎÉÍ ÓÔÅËÏÍ? îÕ É 80x86-ÏÅ (16-ÂÉÔÎÏÇÏ ÒÅÖÉÍÁ) push BP mov BP,SP sub SP,8 ; ÓËÁÖÅÍ, 8 ÂÁÊÔ ÌÏËÁÌØÎÙÈ ÐÅÒÅÍÅÎÎÙÈ Ñ ÕÖÅ ÐÉÓÁÌ ËÁË ÐÒÉÍÅÒ

HZ> ÷ÏÔ ÅÓÌÉ ÉÓÐÏÌØÚÏ×ÁÔØ HZ> ÄÌÑ ÐÒÅÒÙ×ÁÎÉÊ ÏÔÄÅÌØÎÙÊ ÓÔÅË, ÔÏ ÔÏÇÄÁ, ×ÒÏÄÅ, ÄÏÌÖÎÏ ÐÏÌÕÞÉÔØÓÑ. ä×Á ÓÔÅËÁ (ÄÁÎÎÙÈ É ÕÐÒÁ×ÌÅÎÉÑ) -- ÍÙÓÌØ ÄÏ×ÏÌØÎÏ ÎÅÐÌÏÈÁÑ. îÏ, Ó ÄÒÕÇÏÊ ÓÔÏÒÏÎÙ, ÔÒÅÂÕÀÝÁÑ ÂÏÌÅÅ ÁËËÕÒÁÔÎÏÇÏ ÒÁÓÐÒÅÄÅÌÅÎÉÑ ÐÁÍÑÔÉ -- ËÁÖÄÏÍÕ ÓÔÅËÕ ÎÁÄÏ ÄÁÔØ, É ËÁÖÄÏÍÕ ÞÔÏÂÙ È×ÁÔÉÌÏ. ó ÔÒÅÔØÅÊ - ÎÅÕÖÅÌÉ ÎÅÔ gcc ÄÌÑ sparc? á Õ ÎÅÇÏ, ÅÓÌÉ Ñ ÐÒÁ×ÉÌØÎÏ ÐÏÍÎÀ, ÓÒÁÚÕ ÐÏ ÖÉÚÎÉ Ä×Á ÕËÁÚÁÔÅÌÑ ÓÔÅËÁ.

wbr,

-- /* Oleksandr Redchuk, Brovary, Ukraine */ /* real '\x40' real '\x2E' kiev '\x2E' ua */

24-Sep-03 14:34 Harry Zhurov wrote to Alexey Boyko:

AB>> ðÏ×ÅÚÌÏ ÍÎÅ. á ÞÔÏ × éáò ó ÎÅÔÕ inline?

HZ> ÷ éáò, ËÁË É ÐÏÌÏÖÅÎÏ ÓÉÛÎÏÍÕ ËÏÍÐÉÌÑÔÏÒÕ, ×ÓÔÒÁÉ×ÁÅÍÙÈ ÆÕÎËÃÉÊ ÎÅÔ.

ëÏÍÐÉÌÑÔÏÒÕ, ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÍÕ

INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:1999 Programming languages - C

inline ÉÍÅÔØ ÐÏÌÏÖÅÎÏ. õÖÅ 3 ÇÏÄÁ ËÁË.

wbr,

-- /* Oleksandr Redchuk, Brovary, Ukraine */ /* real '\x40' real '\x2E' kiev '\x2E' ua */

Hello Harry.

24 Sep 03 21:59, Harry Zhurov wrote to Oleksandr Redchuk:

HZ>>> ô.Å. ÓÄÅÌÁÔØ ÉÍÅÎÎÏ ÔÏ, ÞÔÏ ÎÁ ++ ÐÏÌÕÞÁÅÔÓÑ ÎÁÔÉ×ÎÏ. é ÐÏÓÌÅ HZ>>> ÜÔÏÇÏ ÅÝÅ ÎÅ ÓÞÉÔÁÔØ ++ÎÕÀ ÍÏÄÅÌØ ÌÕÞÛÅÊ, ÞÅÍ ÓÉÛÎÕÀ! OR>> é ÎÅÏÂÈÏÄÉÍÏÓÔØ ÐÉÓÁÔØ × ËÌÁÓÓÁÈ ÓÌÏ×Á private - ÜÔÏ OR>> ÔÏ, ÞÔÏ ÎÁ ÁÓÓÅÍÂÌÅÒÅ ÐÏÌÕÞÁÅÔÓÑ ÎÁÔÉ×ÎÏ. HZ> ÷ ËÌÁÓÓÁÈ ÐÉÓÁÔØ private ÎÅ ÎÁÄÏ - ÏÂßÑ×ÌÑÅÛØ ÐÒÉ×ÁÔÎÏÅ ÓÒÁÚÕ, ÐÏÔÏÍ HZ> ÐÉÛÅÛØ public ÄÌÑ ÏÔËÒÙÔÏÇÏ É ×ÕÁÌÑ. :) ô.Þ. ×ÓÅ ÎÁÔÉ×ÎÏ. :))

ÔÅÍÎÉÛØ :) ÈÏpÏÛÉÊ ÓÔÉÌØ ××ÅpÈy pÁÚÍÅÓÔÉÔØ public, Á ÎÉÖÅ ÎÅÇÏ - private

Alexey

Hello Vladimir.

24 Sep 03 18:35, Vladimir Vassilevsky wrote to Yuriy K:

VV> äÁ ÄÁÖÅ ÍÅÎÀÛÎÙÊ ××ÏÄ/×Ù×ÏÄ ÎÁ Ä×ÕÈÓÔÒÏÞÎÉË ÕÄÏÂÎÅÅ ÐÉÓÁÔØ ÎÁ ++.

ÔÙ ÐpÏ pÅÁÌÉÚÁÃÉÀ ÉÌÉ ÉÓÐÏÌØÚÏ×ÁÎÉÅ? ðpÏ pÅÁÌÉÚÁÃÉÀ ÄÅpÅ×Ï ÍÅÎÀ pÅÁÌÉÚyÅÔÓÑ Ó×ÑÚÎÙÍ ÓÐÉÓËÏÍ, ÐpÉÞÅÍ ÔyÔ ó/ó++/ÌÀÂÏÊ ÄpyÇÏÊ ÑÚÙË ? ðpÏ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÅÓÔØ ÎÁÂÏp ÍÏÄyÌÅÊ, ËÏÔÏpÙÍ Ñ ÐÏÌØÚyÀÓØ ÄÌÑ ×Ù×ÏÄÁ ÎÁ ÜËpÁÎ 16È4 öëé (ÎÁ ÓÁÍÏÍ ÄÅÌÅ ÉÎÆÁ ÐÏÓÙÌÁÅÔÓÑ ÞÅpÅÚ CAN × ÍÏÄyÌØ, Ë ËÏÔÏpÏÍy ÐÏÄËÌÀÞÅÎ öëé)

=== Begin Windows Clipboard === /* ÓÔÉÒÁÅÍ ÄÉÓÐÌÅÊ É ×Ù×ÏÄÉÍ ÓÔÁÔÉÞÅÓËÕÀ ÉÎÆÏÒÍÁÃÉÀ ÎÁ ÄÉÓÐÌÅÊ */ SsScrPutStr (" ÷ÅÒÓÉÑ ðï", 0, SCR_CONST_STR_FLG | SCR_DISP_CLR_FLG); SsScrPutStr (" "VERSION_STR, 0, SCR_POS_L2 | SCR_POS_P1 | SCR_CONST_STR_FLG); === End Windows Clipboard ===

çÌÁ×ÎÏÅ ÐpÏÂÌÅÍÁ × ++ ÄÌÑ ÍÅÎÑ - ÎÁÄÏ _ÐÏ-ÄpyÇÏÍy_ ÐpÏÅËÔÉpÏ×ÁÔØ. óÉ++ ÐÏËÁ ÎÅ ÐpÉÍÅÎÑÌ, ÎÏ ÔÁÍ ÅÓÔØ ×ËyÓÎÏÓÔÉ ×pÏÄÅ ÛÁÂÌÏÎÏ× (ÎÏ ÉÈ ÎÅÔ × EC++), inline, (pÅÖÅ ÎÁÄÏ ÄÅÌÁÔØ cast.

Alexey

Hello "Harry.

24 Sep 03 17:34, you wrote to me:

AB>> ÷ÏÏÂÝÅ-ÔÏ Ñ ÓÐÒÁÛÉ×ÁÌ ÐÏÞÅÍÕ ÎÅ ÐÒÏÊÄÅÔ. HZ> ðÏÔÏÍÕ ÞÔÏ, ÎÁÐÒÉÍÅÒ, ÅÓÌÉ ÅÓÔØ ÏÂßÑ×ÌÅÎÎÙÊ ÐÏÌØÚÏ×ÁÔÅÌÅÍ HZ> ËÏÐÉÒÕÀÝÉÊ ÏÐÅÒÁÔÏÒ ÐÒÉÓ×ÁÉ×ÁÎÉÑ, ÔÏ ÜÔÏÔ ÏÐÅÒÁÔÏÒ ÐÏÄÒÁÚÕÍÅ×ÁÅÔ HZ> ÏÐÒÅÄÅÌÅÎÎÕÀ ÓÅÍÁÎÔÉËÕ HZ> ËÏÐÉÒÏ×ÁÎÉÑ, Á ÐÒÏÓÔÏÅ ÐÏÂÉÔÏ×ÏÅ ËÏÐÉÒÏ×ÁÎÉÅ ÉÍÅÅÔ ×ÐÏÌÎÅ ÏÐÒÅÄÅÌÅÎÎÕÀ HZ> ÓÅÍÁÎÔÉËÕ ËÌÏÎÉÒÏ×ÁÎÉÑ, ÞÔÏ ÐÏÚ×ÏÌÑÅÔ ÓÏÚÄÁ×ÁÔØ ÏÂßÅËÔÙ ÎÅÒÁÚÒÅÛÅÎÎÙÍ HZ> ÓÐÏÓÏÂÏÍ. éÌÉ ÅÓÌÉ ÅÓÔØ ÐÒÉ×ÁÔÎÙÅ ÐÏÌÑ, ÔÏ ÄÏÓÔÕÐ Ë ÎÉÍ ÄÏÌÖÅÎ ÂÙÔØ HZ> ÔÏÌØËÏ ÞÅÒÅÚ ÏÐÒÅÄÅÌÅÎÎÙÊ ÉÎÔÅÒÆÅÊÓ, É ÅÓÌÉ ÐÒÏÓÔÏ ÐÏÂÉÔÏ×Ï HZ> ËÏÐÉÒÏ×ÁÔØ, ÔÏ ÜÔÏ ÚÎÁÞÉÔ ÐÏÌÕÞÉÔØ Ë ÎÉÍ ÄÏÓÔÕÐ × ÏÂÈÏÄ ÓÉÓÔÅÍÙ ÔÉÐÏ×, HZ> ÞÔÏ ÅÓÔØ ÅÝÅ ÂÏÌÅÅ ÇÒÑÚÎÙÊ ÈÁË.

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

AB>> ÷ ÐÒÉ×ÅÄÅÎÎÏÍ ÔÏÂÏÊ ÐÒÉÍÅÒÅ - ÐÒÏÊÄÅÔ. AB>> HÏ ÔÙ ÓÄÅÌÁÌ ÐÒÁ×ÉÌØÎÏÅ ÐÒÉ×ÅÄÅÎÉÅ, ÎÅ ÔÁË ÌÉ?

HZ> üÔÏ ÓÌÉÛËÏÍ ÐÒÏÓÔÏÊ ÐÒÉÍÅÒ.

÷ÏÔ Ë ÎÅÍÕ Ñ É ÐÒÉÃÅÐÉÌÓÑ. ðÌÏÈÉÅ ÐÒÉÍÅÒÙ ÍÙ ÔÕÔ ×ÓÅ ÐÒÉ×ÏÄÉÍ. (É ÎÅ ÔÏÌØËÏ × ÜÔÏÍ ÔÒÅÄÅ)

HZ> á ÐÒÅÄÓÔÁ×Ø ÓÅÂÅ, ÞÔÏ ËÏÐÉÒÏ×ÁÎÉÅ HZ> ÐÒÏÉÚ×ÏÄÉÔÓÑ × ÏÄÎÏÊ ÅÄÉÎÉÃÅ ÔÒÁÎÓÌÑÃÉÉ, Á ÐÒÉ×ÅÄÅÎÉÅ × ÄÒÕÇÏÊ.

þÔÏ ÅÓÔØ ÅÄÉÎÉÃÁ ÔÒÁÎÓÌÑÃÉÉ?

Alexey

Hello "Harry.

24 Sep 03 17:34, you wrote to me:

AB>> HÁ ËÌÁÓÓÁÈ ÅÓÔØ ÔÏÌØËÏ ÏÄÉÎ ÓÐÏÓÏÂ É ÏÐÔÉÍÉÚÉÒÏ×ÁÔØ ÔÁÍ ÎÅÞÅÇÏ. AB>> ôÏÌØËÏ ÎÁ ËÏÍÐÉÌÑÔÏÒ ÐÒÉÈÏÄÉÔÓÑ ÎÁÄÅÑÔÓÑ. HZ> ó ÞÅÇÏ ÔÙ ÜÔÏ ×ÚÑÌ?

ru.embedded ÐÏÞÉÔÁÌ ;)

HZ> ### âÒÀËÉ ×ÁÖÎÅÅ ÖÅÎÙ, ÐÏÔÏÍÕ ÞÔÏ ÓÕÝÅÓÔ×ÕÅÔ ÎÅÍÁÌÏ ÍÅÓÔ, ËÕÄÁ ÍÏÖÎÏ HZ> ÐÏÊÔÉ ÂÅÚ ÖÅÎÙ.

;)

Alexey

Hello "Harry.

24 Sep 03 17:34, you wrote to me:

AB>> ðÏ ÉÎÄÅËÓÕ × ÍÁÓÓÉ×Å. ïÄÎÏÍÅÒÎÙÅ ÍÁÓÓÉ×Ù ÎÅ ÅÓÔØ ÞÅÍ-ÔÏ ÏÞÅÎØ AB>> ÓÌÏÖÎÙÍ É ÔÑÖÅÌÙÍ ÄÌÑ ÐÏÎÉÍÁÎÉÑ. HZ> á ÏÎÉ × ó/ó++ ÔÏÌØËÏ ÏÄÎÏÍÅÒÎÙÍÉ É ÂÙ×ÁÀÔ. int A[5][4] - ÜÔÏ ÔÏÖÅ HZ> ÏÄÎÏÍÅÒÎÙÊ ÍÁÓÓÉ× ÒÁÚÍÅÒÏÍ [5]*[4].

??? ÞÅÇÏ-ÔÏ ÔÅÂÑ ÎÅ × ÔÕ ÓÔÅÐØ ÐÏÎÅÓÌÏ.

AB>> á ÔÁË ÒÕËÁÍÉ ÎÕÖÎÏ ÏÐÉÓÙ×ÁÔØ ÒÁÚÎÙÅ ËÌÁÓÓÙ. åÓÌÉ × ÐÒÏÇÒÁÍÍÕ Ó AB>> ÍÁÓÓÉ×ÁÍÉ ÎÕÖÎÏ ÄÏÂÁ×ÉÔØ ÅÝÅ ÏÄÎÏ ÚÎÁÞÅÎÉÅ, ÎÕÖÎÏ ÐÒÏÓÔÏ ÕÄÌÉÎÎÉÔØ AB>> ÍÁÓÓÉ×Ù, HZ> HÅ, ÎÅ ×ÓÅ ÔÁË ÂÅÚÏÂÌÁÞÎÏ. ðÒÉÄÅÔÓÑ ÏÂßÑ×ÉÔØ ÆÕÎËÃÉÀ É ÐÏÍÅÓÔÉÔØ HZ> ÕËÁÚÁÔÅÌØ ÎÁ ÎÅÅ × _ÓÔÒÏÇÏ_ _ÏÐÒÅÄÅÌÅÎÎÏÅ_ ÍÅÓÔÏ × ÍÁÓÓÉ×Å, É ÎÅ ÄÁÊ HZ> âÏÇ ÏÛÉÂÉÔØÓÑ. á ÅÝÅ ÕÞÔÉ, ÞÔÏ ÆÕÎËÃÉÑ ÎÅ ÏÄÎÁ, ÉÈ ÎÅÓËÏÌØËÏ - × ÎÁÛÅÍ HZ> ÎÅÂÏÌØÛÏÍ ÐÒÉÍÅÒÅ ÉÈ ÂÙÌÏ ÔÒÉ. ô.Å. ÎÕÖÎÏ ÓÏÚÄÁÔØ ÔÒÉ ÆÕÎËÃÉÉ É HZ> ÐÏÍÅÓÔÉÔØ ÕËÁÚÁÔÅÌÉ ÎÁ ÎÉÈ × ÔÒÉ ÒÁÚÎÙÈ ÍÁÓÓÉ×Á ÐÏ ÏÄÉÎÁËÏ×ÏÍÕ HZ> ÉÎÄÅËÓÕ. ÷ÓÅ ÜÔÏ ÒÕËÁÍÉ. é ÎÅ ÏÛÉÂÉÔØÓÑ, Ô.Ë. ËÏÍÐÉÌÑÔÏÒ ÜÔÏ ÎÅ ÓÍÏÖÅÔ HZ> ÐÒÏ×ÅÒÉÔØ. ëÏÒÏÞÅ, ËÕÞÁ ÍÁÎÉÐÕÌÑÃÉÊ, ÔÒÅÂÕÀÝÁÑ ÐÒÅÄÅÌØÎÏÇÏ ×ÎÉÍÁÎÉÑ.

÷ÉÖÕ, ÔÙ ÏÞÅÎØ ÓÉÌØÎÏ ÚÁÐÌÀÓÏ×ÁÌÓÑ. HÉËÁËÉÈ ÆÕÎËÃÉÊ ÐÉÓÁÔØ Ñ ÎÅ ÐÒÅÄÌÁÇÁÌ. ÷ ÍÁÓÓÉ×ÁÈ max, min, delta Ñ ÐÒÅÄÌÁÇÁÌ ÈÒÁÎÉÔØ ÞÉÓÌÁ, Á ÎÅ ÁÄÒÅÓÁ ÆÕÎËÃÉÊ.

AB>> Á ÎÁ ó++ - ÓÏÚÄÁÔØ ÎÏ×ÙÊ ËÌÁÓÓ. óËÏÌØËÏ ÅÝÅ ÓÔÒÏË ÐÏÎÁÄÏÂÉÔÓÑ? HZ> á ÔÙ ÞÔÏ, ÔÒÕÄÏÅÍËÏÓÔØ × ÓÔÒÏËÁÈ ÉÚÍÅÒÑÅÛØ?

÷ ËÏÎÃÅ ËÏÎÃÏ× ×ÓÅ Ó×ÏÄÉÔÓÑ Ë ËÏÌÉÞÅÓÔ×Õ ÓÔÒÏË.

HZ> åÓÌÉ ÔÏÌØËÏ ÒÁÄÉ HZ> ×ÉÒÔÕÁÌØÎÙÈ ÆÕÎËÃÉÊ, ÔÏ ÓÔÒÏË ÎÅ ÂÏÌØÛÅ ÐÏÎÁÄÏÂÉÔÓÑ - × ÓÌÕÞÁÅ ÒÕÞÎÏÊ HZ> ÏÒÇÁÎÉÚÁÃÉÉ ÔÏÖÅ ÐÉÓÁÎÉÎÙ ÅÓÔØ: ×ÐÉÓÙ×ÁÔØ × ÍÁÓÓÉ×Ù ÕËÁÚÁÔÅÌÉ, HZ> ÐÒÏÐÉÓÙ×ÁÔØ ÄÏ ÜÔÏÇÏ ÐÒÏÔÏÔÉÐÙ. ðÏ ËÏÌÉÞÅÓÔ×Õ ÐÉÓÁÎÉÎÙ ÏÎÏ ÇÄÅ-ÔÏ HZ> ÓÏÉÚÍÅÒÉÍÏ, Á ×ÏÔ ÐÏ ÂÅÚÏÐÁÓÎÏÓÔÉ É ÕÄÏÂÓÔ×Õ ×ÉÒÔÕÁÌØÎÙÅ ÆÕÎËÃÉÉ HZ> ÒÕÌÑÔ.

ïÎÏ-ÔÏ ËÏÎÅÞÎÏ ÄÁ. åÓÌÉ ÓÏÚÄÁ×ÁÔØ ÎÁ óÉ ÍÁÓÓÉ×Ù ÕËÁÚÁÔÅÌÅÊ ÎÁ ÆÕÎËÃÉÉ, ÔÏ ÉÌÉ ÚÁÓÔÒÅÌÉÔØÓÑ ÉÌÉ ÐÅÒÅÊÔÉ ÎÁ ó++. HÏ Ñ ÐÒÅÄÌÁÇÁÌ ÎÅ ÓÏÚÄÁ×ÁÔØ ÆÕÎËÃÉÉ.

AB>> ÷ÏÏÂÝÅ-ÔÏ ÍÅÎÑ ó++ ÎÅ ÕÓÔÒÁÉ×ÁÅÔ, ÐÏÔÏÍÕ-ÞÔÏ Ó ÎÉÍ ÐÏÌÕÞÁÅÔÓÑ AB>> ÍÎÏÇÏ×ÁÔÏ ÕËÁÚÁÔÅÌÅÊ ÎÁ ÆÕÎËÃÉÉ, HZ> üÔÏ ÇÄÅ ÜÔÏ ÔÁÍ ÏÎÏ ÐÏÑ×ÌÑÅÔÓÑ?

÷ÍÅÓÔÅ Ó ×ÉÒÔÕÁÌØÎÙÍÉ ÍÅÔÏÄÁÍÉ.

AB>> Ó ËÏÔÏÒÙÍÉ á÷òÕ ÎÅ ÏÞÅÎØ ÕÄÏÂÎÏ ÒÁÂÏÔÁÔØ. HZ> á ÜÔÏ ÅÝÅ ÐÏÞÅÍÕ? é ËÏÍÕ ÔÏÇÄÁ ÕÄÏÂÎÏ?

ldd ZL, Y+N ldd ZH, Y+N+1 icall

(ÜÔÏ ÅÓÌÉ Y Ó×ÏÂÏÄÎÙÊ)

ÐÒÏÔÉ×:

rcall

HÁ ARM:

ËÏÓ×ÅÎÎÙÊ mov LR, PC ldr PC, [R0, #N] ÐÒÏÔÉ×:

bl

Alexey