возврат из подпрограмм

Jurgis, ты ещё здесь сидишь?

Пятница Июнь 09 2006 12:26, Jurgis Armanavichius wrote to Aleksandr Konosevich:

JA> (Позже) Вот посмотрел на PIC18F2450: 48 MHz performance (12 MIPS). JA> Т.е., надо полагать, это осталось. Впрочем, если кварц 48 MHz... :-)

Кварц на 12 МГц. Встроенный синтезатор частот умножает эту частоту на четыре, "пиковское" процессорное ядро традиционно выполняет машинный цикл за 4 такта, отсюда 12 MIPS.

Hо на очень большом тираже всё равно считают каждую комейку...

Георгий

Michael, ты ещё здесь сидишь?

Суббота Июнь 10 2006 02:09, Michael Zaichenko wrote to George Shepelev:

PG>>> Бывает и баpсике пpогpаммят. Абы pесypсов хватало. PG>>> Уже не модно yкладывать пpодвинyтые пpоги в 1K. :) GS>> Тут важна не мода, а тираж устройств. Сэкономишь на миллионном GS>> тираже по доллару - набежит прибыли миллион баксов. Это не GS>> деньги, говоришь? ;) MZ> Ты пробовал делать милионный тираж?

Ты не веришь в существование милионных тиражей? ;)

Георгий

Пpивет Jurgis! Jurgis Armanavichius --> Aleksandr Konosevich ( Fri Jun 09 2034, 13:26 )

JA> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с памятью JA> в 0.25 кслов, то тогда конечно, не до С будет... ;-)

Тpи ypовня стека - этого мало. Бyдет пpодолжение до, хоть, 64 байт - это бyдет весчь!!!

Уже в 512 EPROM и 64 SRAM бyдет ФОРТ кpyтится запpосто. А великолепие коpпyса SOT-23-6 - #_ЭТО_МОЯ_МЕЧТА_# !!! :))

Ты что-то там пpо си гpил? :)

-= Брест. Павел Гришин =-

... │││ ЭТО ЕСТЬ HЕ ФАКТ, А ГОЛАЯ ПpАВДА │││

AK> íÏÖÅÔ ËÔÏ É ÓÞÉÔÁÅÔ ÁÔÍÅÌÙ "ËÒÉ×ÙÍÉ", ÎÏ ÂïÌØÛÕÀ ÞÁÓÔØ ËÏÍÁÎÄ ÏÎÉ AK> ×ÙÐÏÌÎÑÀÔ ÒÏ×ÎÏ ÚÁ ÔÁËÔ (Á ÐÏ ÔÁËÔÏ×ÏÊ ÎÅËÏÔÏÒÙÅ É ÚÁ 20 íçà AK> "ÐÅÒÅÛÁÇÎÕÌÉ", ×ÒÏÄÅ ?)

-= âÒÅÓÔ. ðÁ×ÅÌ çÒÉÛÉÎ =-

... úÁËÕÓËÁ ÂÅÚ ×ÏÄËÉ ÎÁÚÙ×ÁÅÔÓÑ ÅÄÁ.

Приветствую Вас, Jurgis!

Однажды 09 Июн 06 в 13:26, Jurgis Armanavichius писал(а) к Aleksandr Konosevich...

JA> А Григорий тут на меня с Ассемблером наезжал! А ведь этот пик - как JA> раз одна из младших моделей, цена $2.99. И даже эту младшую модель JA> вполне можно программировать на C :-) JA>

JA> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с памятью в JA> 0.25 кслов, то тогда конечно, не до С будет... ;-)

Да вpяд ли в него нужно тяжелый алгоpитм пихать. А что-то малюсенькое, дешевое, лапками деpгающее - вполне на Си напишется.

С уважением, Виталий.

... -|O|-

Привет Andrey!

AM>> Во-первых, максимально компактный и максимально быстрый - AM>> часто противоречивое требование.

AB> Это все понятно. Речь шла о том, что компилятор все может AB> предусмотреть.

Hо он не может расставить приоритеты.

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

AB> Если компилятор выполняет программу в соответствием со стандартом, AB> то по идее, оптимизация не должна оказывать влияния.

По идее, программа не должна содержать ошибок. :) Ты никогда не встречал ситуацию, когда после смены компилятора программа перестает работать?

Hапример был у меня утянутый когда-то из какой-то библиотеки вот такой crtend.c:

typedef void (*fptr)(void);

static fptr ctor_end[1] __attribute__((section(".ctors"), __unused__)) = { 0 }; static fptr dtor_end[1] __attribute__((section(".dtors"), __unused__)) = { 0 };

и все работало. Перестало работать где-то в районе перехода с gcc-3.2 на gcc-3.3. Hовый gcc стал выкидывать неиспользуемые статические объекты.

Я неоднократно встречал такие диалоги:

- У меня программа XXX-1.2 падает!

- Отключи ей оптимизацию. У меня с -O2 тоже падала. К следующей версии обещают починить...

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

AB> Главное чтобы программа задачу выполняла.

Допустим, не выполняет: функция возвращает 45, а по моему мнению, должна возвращать 54. Как под отладчиком трассировать процесс вычисления, если весь код выродился в mov r1,#45; ret ?

AM>> (смотри последний пример, где оптимизатор вообще выкинул AM>> цикл, вычислив результат на этапе компиляции), поэтому для AM>> отладки приходится оптимизацию отключать.

AB> Если бы переменные в этом цикле определены были как надо, то AB> компилятор их не выкинул бы.

Они определены как надо. Для отладочной сборки проще изменить опцию компилятора с -O2 на -O0, чем менять объявления переменных.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Закрой свой Ворд!

Привет Alex!

AM>>> Во-первых, максимально компактный и максимально быстрый - AM>>> часто противоречивое требование. AB>> Это все понятно. Речь шла о том, что компилятор все может AB>> предусмотреть. AM> Hо он не может расставить приоритеты.

Значик все-таки компилятор не все знает на этапе компиляции. :-) Это опять возвращаясь к твоему примеру.

AM>>> Во-вторых, ничто не совершенно, и программы могут содержать AM>>> ошибки, проявляющиеся при определенных типах оптимизации, AM>>> поэтому должна быть возможность их отключения. AB>> Если компилятор выполняет программу в соответствием со AB>> стандартом, то по идее, оптимизация не должна оказывать влияния. AM> По идее, программа не должна содержать ошибок. :)

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

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

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

AM>>> В-третьих, сильно оптимизированный код почти невозможно AM>>> трассировать под отладчиком, т.к. выполняемый код мало похож на AM>>> исходный AB>> Главное чтобы программа задачу выполняла. AM> Допустим, не выполняет: функция возвращает 45, а по моему мнению, AM> должна возвращать 54. Как под отладчиком трассировать процесс AM> вычисления, если весь код выродился в mov r1,#45; ret ?

Hу ты же пишешь программу, значит не правильно написал. :-) Т.е. если хочешь от программы другого - пиши по другому.

AM>>> (смотри последний пример, где оптимизатор вообще выкинул AM>>> цикл, вычислив результат на этапе компиляции), поэтому для AM>>> отладки приходится оптимизацию отключать. AB>> Если бы переменные в этом цикле определены были как надо, то AB>> компилятор их не выкинул бы. AM> Они определены как надо. Для отладочной сборки проще изменить AM> опцию компилятора с -O2 на -O0, чем менять объявления переменных.

По моему если некое объявление переменных сделано как volatile или static, то это не случайно. :-) И именно оно (а не ключи) для компилятора предписывает определенные правила поведения компилятора для этих переменных.

С уважением, Andrey 10 Июн 06 года

Привет!

Fri Jun 09 2006 12:56, Ruslan Mohniuc wrote to Jurgis Armanavichius:

JA>> Да, с логикой у тебя не очень... При чем тут факты? Ты ж ни единого JA>> факта не привел, что ЯВУ для микроконтроллеров вреднО. А вот я привел JA>> свой практический опыт, на который тебе, конечно, наплевать, я JA>> понимаю. RM> Hе напрягайся, это разговор с глухим. Hе пробовал и не собирается RM> пробовать. Просто не трать время.

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

Юргис

Привет!

Fri Jun 09 2006 14:46, Dmitry Orlov wrote to Jurgis Armanavichius:

JA>> Спору нет, если младшие пики крайне просты - значит и не нужно их JA>> программировать на ЯВУ. DO> Младшие (12тибитные) PIC'и сегодня устарели безнадежно, а 14тибитные DO> (те что PIC16 и PIC12F) прекрасно на С программируются.

Это здорово!

JA>> Hо ведь не меньшая, а скорее бОльшая, часть микроконтроллеров как раз JA>> превосходно программируются на ЯВУ :-) JA>> Кстати, а ты можешь мне объяснить, какие недостатки младших пиков JA>> плохо ложатся на сишную концепцию? DO> Hелинейное адресное пространство, дорогая косвенная адресация, DO> ограниченный 8 уровнями стек возвратов. Что надо учитывать при DO> написании программ, но не более того.

Спасибо за информацию! Буду знать.

JA>> Hе скажи. Возьмем, к примеру, меня. Я совершенно не знаю ассемблера JA>> пиков. Hо представим, что у Микрочипа появился микроконтроллер, в JA>> котором реализован интерфейс USB 2.0 High Speed, и поэтому я его JA>> захочу применить. С применением C/C++ я это смогу сделать довольно JA>> быстро и безболезненно. А на ассемблере? Hа ассемблере мне будет JA>> гораздо тяжелее. DO> С++ вменяемых реализаций для PIC16 нет и врядли будут.

Мне именно плюс-плюс не критичен. Мне главное - простой C чтобы был. Если он есть и хорошо работает - прекрасно!

JA>> Кстати. Hе мог бы ты кратко объяснить преимущества пиков перед теми JA>> же 51-ми или AVR? А то пока я сам разберусь... DO> Соотношение набора периферии, потребления, помехоустойчивости и цены у DO> PIC'ов лучшее. Плюс к этому - очень широкий спектр хорошо совместимых DO> между собой изделий от одного производителя.

Большое спасибо еще раз! Я стал считать, что совершенно напрасно раньше не смотрел на это семейство ;-)

Юргис

Привет!

JA>> А это давно было? А то раньше такое частенько встречалось. AK> Может кто и считает атмелы "кривыми", но бОльшую часть команд они AK> выполняют ровно за такт (а по тактовой некоторые и за 20 МГц AK> "перешагнули", вроде ?)

Мне вообще это семейство очень нравится! Выбор кристаллов превосходный. Большинство команд выполняются за один такт. Рулез! :-)

JA>> extension, enabled as a device configuration option, has been JA>> specifically designed to optimize re-entrant application code JA>> originally developed in high-level languages such as C." AK> Знаешь, у меня со времён всяких х86 разные MMX/MMX2/SSE/3DNOW/SSE2/etc AK> не вызывают ничего, кроме кривой ухмылки (да, забыл же ENTER/LEAVE! 8-)

А меня в этом абзаце привлекло то, что делается упор на C. Я скачал парочку (ну может чуть по-больше) Аппликатион Hотес - все поголовно с примерами на C. А меня тут Георгий Ассемблером напрягает... ;-)

JA>> А Григорий тут на меня с Ассемблером наезжал! А ведь этот пик - как раз JA>> одна из младших моделей, цена $2.99. И даже эту младшую модель вполне JA>> можно программировать на C :-) AK> Компиляторы с Цэ сейчас имхо можно найти под любой МК, имеющий хоть AK> сколько-то SRAM на борту.

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

JA>> Впрочем... Если ориентироваться на какой-нибудь PIC10F200 с памятью JA>> в 0.25 кслов, то тогда конечно, не до С будет... ;-) AK> Для "интеллектуальной кофеварки" имхо даже тини15 - избыточен ... ЖB}

Я недавно контроллер для игрушечного вертолета программил (типа, поделка выходного дня). Так на C программу разрабатывал... ;-)

Юргис

Привет!

Fri Jun 09 2006 13:57, Ruslan Mohniuc wrote to Jurgis Armanavichius:

JA>> А вот насчет архитектуры, или вкусностей каких-нибудь? Есть у них JA>> своя изюминка? RM> Для меня это доступные контроллеры, которые работают так, как написано RM> в документации, и к которым есть софт. Сейчас сижу на них скорее по RM> привычке, я знаю как с ними работать, да и сопутствующий софт тоже RM> изучен. Про изюминки- это скорее не меня нужно спрашивать, я скорее RM> ремесленник, чем художник. RM> С ходу на ум приходит низкое энергопотребление в слипе. Работа с портами RM> как с ячейками памяти. Длинный модельный ряд, позволяющий оптимально RM> выбрать камень с нужными тебе ресурсами и корпусом в рамках одного RM> семейства. Поддержка и продолжение поставок давно вышедших из моды RM> микроконтроллеров.

Большое тебе спасибо за информацию! Похоже, что это достойное семейство обязательно должно быть включено в круг моего внимания :-)

JA>> Мне Георгий сказал, что младшие модели плохо на C ложатся. RM> Hа заборе тоже много чего пишут. Все там хорошо.

Hу и отлично! Следовательно, я Георгия про C больше не буду спрашивать ;-)

Юргис

Привет!

Fri Jun 09 2006 15:36, Igor Havtorin wrote to Jurgis Armanavichius:

JA>> А вот насчет архитектуры, или вкусностей каких-нибудь? Есть у них JA>> своя изюминка? Мне Георгий сказал, что младшие модели плохо на C JA>> ложатся. А как со старшими? (Я не из-за лени спрашиваю, а просто JA>> мне всегда приятнее с человеком пообщаться, чем по сайтам лазить :-) IH> Осталось спросить у Георгия как давно он пишет на С для PIC, и на IH> основании чего он сделал такой вывод.

Я понял так, что некоторые люди, по какой-то непонятной причине, не приемлют программирование на ЯВУ (например, на C). Hу, бывает... В таком случае нужно ориентироваться на свои собственные предпочтения, вместе с тем уважая позицию собеседника :-) Я когда-то, очень давно, тоже ЯВУ не любил. Пока не разобрался с компилятором PL (урезанной версии) на персональнике. Точнее, пока не попробовал самолично сделать оный. До конца я, правде, его не довел, но фишку просек, проникся... :-)

Юргис

Привет!

Fri Jun 09 2006 13:02, Sergey Brylew wrote to Jurgis Armanavichius:

JA>> Спору нет, если младшие пики крайне просты - значит и не нужно их JA>> программировать на ЯВУ. Hо ведь не меньшая, а скорее бОльшая, часть SB> Спор есть. Даже самые малые пики (например, 12F629) очень великолепно SB> программируются на С. Hо если из этой крохи пытаться выжать все его SB> предельные возможности, ну тогда только ассемблер. Или если интересен SB> не результат, а процесс. :))

Да, большое спасибо за информацию! Я понял: с пиками на C можно дружить :-)

Юргис

Привет!

Sat Jun 10 2006 02:03, Kirill Frolov wrote to Jurgis Armanavichius:

Понимаешь... Я как эмбеддед программист обладаю одним очень вредным качеством: люблю, чтобы исходящий от меня продукт был еще и красивым. А также, обращаю очень большое внимание на лёгкость сопровождения моих программ. Поэтому, кстати, я негативно отнесся к тому выражению, которое под if'ом пробегало недавно. Hу не люблю я, когда круто, но непонятно...

Юргис

Привет!

Fri Jun 09 2006 10:40, George Shepelev wrote to Jurgis Armanavichius:

GS>>> Если бы только адресация этого "полка регистров" не была такой GS>>> ублюдочной... JA>> Господи, так чем же это тебе номера AVR-овских регистров не угодили?! GS> Тем, что этот "полк регистров" разбит на множество блоков, с каждым GS> из которых можно проделывать специфический набор действий. В результате GS> даже элементарное действие над портом превращается в невразумительное GS> жонглирование данными "тудой-сюдой" :-/

Hе понял... Hормальные регистры, по-моему... Правда, я только на C программирую и только изредка в ассемблерный текст заглядываю. Однако ничего такого крамольного не замечал. Или тебе не понравилось, что три старшие пары могут объединяться в 16-разрядные адресные регистры? Так это наоборот плюс, IMHO...

Юргис

Hi Dmitry,

Sat Jun 10 2006 03:34, Dmitry Orlov wrote to Michael Zaichenko:

GS>>> Тут важна не мода, а тираж устройств. Сэкономишь на миллионном GS>>> тираже по доллару - набежит прибыли миллион баксов. Это не деньги, GS>>> говоришь? ;)

MZ>> Ты пробовал делать милионный тираж?

DO> Жора пробовал об этом рассуждать, а делать даже 10-тысячный не пробовал. Да и рассуждает криво. при переходе с десятков штук к сотням тысяч все производство меняется в корне начиная с идеологии. И экономить надо будет на тех поддержке, ремонте, качестве документации, что сразу переводит разработку в другой класс. В моей прошлой жизни был разовый тираж в 200к экземпляров, на тестировании мы чуть не рехнулись, потом разработали технологию автоматического тестирования...

DO> У наших разработок тираж в десятки тысяч в год, программы для PIC16 DO> _только_ DO> на С. Hичто другое всерьез вообще не рассматривается, никому не нужен DO> несопровождаемый и немодифицируемый ассемблерный код. Тем более, что Эт точно, щас на работе остался только один древний дозатор с кодом на ассемблере. Hа 80с517 камне, у него есть сопроцессор и заменить нынче нечем. Исходник на асме просто ужас, все константы числами, вменяемых имен нет. Придется выкинуть этот бред не глядя, посколько переход на другую платформу. А вообще, нынче семейство x51 еще смысл имеет, если считать что наработок под него нет?

DO> экономия в разы - это бывает только на мелких или специально подобранных DO> алгоритмах, обычно разница куда меньше и уменьшение просто так не дает Угу. Я однажды искал тяжелый глюк в сишной проге под c164 камень, и внимательно просматривал сгенеренный асм. Глюк нашелся быстро. Hо впечтлило меня качество кейловского комайлера сильно - путем дичайшей оптимизации полученого асма я смог бы выиграть отсилы 5-10 процентов.

DO> просто нет. Это любитель, которому ценен сам процесс может позволить DO> себе вылизывать ассемблерный код. Когда нужен и важен результат (а нужен DO> он обычно вчера) нужно применять DO> максимально ускоряющие разработку инструменты. Я нынче асм использую только для правки стартапов под c16x. Для AVR только чистый си, никаких проблем. За 2 года так и не удалось обнаружить хоть сколько нибудь заметный глюк у Иара и Кейла.

WBR, Michael.

Sat Jun 10 2006 22:44, Jurgis Armanavichius wrote to Igor Havtorin:

JA> Я понял так, что некоторые люди, по какой-то непонятной причине, не JA> приемлют программирование на ЯВУ (например, на C).

На ассемблере все очень просто, очевидно и понятно. Освоение языка требует усилий. Но самое противное в ЯВУ - это необходимость разбираться со стартапом и линкерным файлом. VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 10 Jun

JA>>> Speed, и поэтому я его захочу применить. С применением C/C++ я это JA>>> смогу сделать довольно быстро и безболезненно. А на ассемблере? JA>>> Hа ассемблере мне будет гораздо тяжелее. DO>> С++ вменяемых реализаций для PIC16 нет и врядли будут.

JA> Мне именно плюс-плюс не критичен. Мне главное - простой C чтобы был. JA> Если он есть и хорошо работает - прекрасно!

Есть и работает хорошо, хотя и не без огрничений. Скажем в PICC есть ограничение на реентерабельность, функции пользуются для хранения локальных переменных не стеком данных (ввиду его отсутствия), а статической перекрываемой (если позволяет дерево вызовов) памятью. Потому скажем рекурсия невозможна. Банки памяти надо распределять и указывать вручную.

dima

Sun Jun 11 2006 00:14, Michael Zaichenko wrote to Dmitry Orlov:

MZ> Я нынче асм использую только для правки стартапов под c16x. Для AVR MZ> только чистый си, никаких проблем. За 2 года так и не удалось обнаружить MZ> хоть сколько нибудь заметный глюк у Иара и Кейла.

Увы, у всех компилляторов C, которыми приходилось пользоваться (IAR, Cosmic, VDSP, CCS, TC/BC, Watcom, MSVC) бывают глюки. Это может проявляться в больших и сложных программах, и бывает очень неприятно. За IAR AVR замечена потеря локальных переменных при большом уровне вложенности и cross-call оптимизации, а также забывание про то, что SFR-ы являются volatile. Интересно, как нужно писать, чтобы минимизировать возможность глюков компилера.

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт