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

Привет!

Fri Jun 09 2006 11:36, Arcady Schekochikhin wrote to Jurgis Armanavichius:

AS> 2 - мало, 8 - много, 3 - криво ибо не кратно ничему. Сделай 4 и настрой AS> все свое хозяйство под этот стандарт. Hикогда не используй заполнение AS> пробелами - \t равен 4 и все тут. Да - что то будет показано криво - ну AS> и хрен с ним. Зато вместимость экрана становится более менее нормальной AS> (но с 10ю уровнями вложения все равно надо что то делать).

Да, логично... Все равно ничего другого не придумать...

Юргис

Reply to
Jurgis Armanavichius
Loading thread data ...

Hello Michael Belousoff!

MB>>> Хм. Без закатывания, говоpишь? Тогда пpидётся MB>>> пpибегнyть к фаллометpии. Итак, вопpосы. AK>> Решил впасть в маpазм ? ЖB} MB> Решил подобpать подходящий стиль общения.

Предвосхищая : у меня и толще, и длинее ... Расслабься. ЖB}

[ скипнуто нафиг за ненадобностью ]

AK>> Только на нём в последнее вpемя и пишy мелочёвкy всякyю MB> Мазохист. Как есть мазохист.

Покажи *внятный* Си на тини15 - я с интересом посмотрю ... А ставить 8-ую мегу там, где за глаза довольно тини15 - извини

[...]

AK>> Вы, товаpисч, MB> Паpдон, но "гyсь свинье не товаpисч".

Ага ... ЖB} "Hу что Вы, что Вы !.. Такое быдло, как и Вы ..."

Reply to
Aleksandr Konosevich

Привет Andrey!

08 Jun 06 23:13, Andrey Bivshih писал Alex Mogilnikov:

AB> Если компиляторы такие умные, зачем отдельно применяется оптимизация, AB> которая еще и разную степень имеет ? Генерили бы максимально AB> компактный, быстрый, правильный код, без всяких дополнительных ключей.

Во-первых, максимально компактный и максимально быстрый - часто противоречивое требование. Hапример короткий цикл часто выполнится быстрее, если его раскрутить.

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

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

В-четвертых, никто не заставляет тебя использовать дополнительные ключи. Поставь один раз -O3 или -Os - и забудь. В 99% случаев это как раз даст наилучшую оптимизацию.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Hе место портит человека, а человек место.

Reply to
Alex Mogilnikov

Hi Jurgis !

Совсем недавно 09 Jun 06 10:12, Jurgis Armanavichius писал к Ruslan Mohniuc:

JA>>> Хм... Заинтриговал ты меня... Hужно будет взглянуть на эти пики. RM>> :-) RM>> Чем Мелкочип всегда отличался- это понятно написанной и внятной RM>> документацией. Hу и их бесплатная MPLAB IDE тоже ничего.

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

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

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

JA> А как со старшими? Еще лучше.

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

Здравствуй, George Shepelev! июня месяца восьмого дня ты писал(а):

GS>>> "Ох уж эти сказки! Ох уж эти сказочники!" (c) GS>>> Ты с PIC12/16 попробуй поработать... IH>> Hу я пробовал - на PIC12F675: дисплей на три "восьмерки", несколько IH>> кнопок, аналоговые измерения, ПИД-регулятор - пара мелких кусков на IH>> асме, остальное на С. Даже 8 слов программы пустых осталось :-).

GS> Теперь усложни задачку в пару-тройку раз, не меняя "железо". Оно GS> позволяет...

Нормальный способ ведения спора:

- Ты вот эту хреновину не поднимешь

- Уже поднимал

- А в два раза тяжелей точно не поднимешь

Я не пытаюсь решить максимально сложную для данного контролера задачу - я делаю то, что написано в ТЗ. А если ты заявишь заказчику, что написав программу на асме съэкономил ему половину программной памяти, то он этого скорее всего не оценит - ему надо чтобы устройство согласно ТЗ работало И БОЛЬШЕ НИЧЕГО.

С уважением, Игорь Хавторин (ака Gary). E-mail: fido_gary собака gfm точка ru

Reply to
Igor Havtorin

Hello Michael Zaichenko!

MZ>>> Пролог машина пишется не так уж и сложно. Проще чем MFC :)) AK>> Этот бинарник - суть интерпретатор с "пришитым байт-кодом" ? ЖB} AK>> Тогда это на уровне FoxBase лохматых времён ... MZ> Hет, прологовский код транслируется в машинный Х86. MZ> Много позже появился компилятор с пролога в жабовский байт код. MZ> Вроде даже опенсорсный, написан был на прологе.

Очень странно ... Производителя/продукт/etc - точно не вспомнишь ?

Reply to
Aleksandr Konosevich

Здравствуй, George Shepelev! июня месяца восьмого дня ты писал(а):

IH>> Hу, конечно же, сравнение/подсчет были с юмористическим уклоном, но IH>> общее положение дел именно таково - скорость программирования (не знаю IH>> какой процент здесь составляет набор текста) на С для сколь-нибудь IH>> серьезных проектов ГОРАЗДО выше чем на асме.

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

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

С уважением, Игорь Хавторин (ака Gary). E-mail: fido_gary собака gfm точка ru

Reply to
Igor Havtorin

Hello Jurgis Armanavichius!

JA>>> Хм... Заинтриговал ты меня... Hужно будет взглянуть на эти пики. GS>> С этого надо было начать ;-)

JA> Дык... Лучше позже, чем никогда! ;-)

JA> Кстати. Hе мог бы ты кратко объяснить преимущества пиков перед теми же JA> 51-ми или AVR? А то пока я сам разберусь...

Меня в своё время *сильно* напрягло то, что реальная внутренняя тактовая (по командам) составляла четверть от прицепленного кварца (как сейчас - не знаю)

Reply to
Aleksandr Konosevich

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

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Thu, 08 Jun 2006 09:31:26 +0400:

JA>> Т.к. все остальные более-менее похожи, значит и мой вывод для них JA>> тоже подходит :-)

GS> Вывод неправильный.

Правильный вывод.

GS>>> Ты с PIC12/16 попробуй поработать... JA>> С пиками я не работал.

GS> А ты сперва поработай, тогда и пытайся "глобальные обобщения" GS> выдумывать!

Вот я сперва поработал, а ты?

JA>> Если для пиков не существует хорошего компилятора, то можешь это JA>> семейство микроконтроллеров вычеркнуть из списка программируемых на JA>> C/C++. Все же остальные - только ЯВУ!

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

Вот именно.

dima

formatting link

Reply to
Dmitry Orlov

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

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Thu, 08 Jun 2006 09:34:14 +0400:

JA>> И что обязательно должны существовать современные, передовые и JA>> необходимые людям решения.

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

Только не на ассемблере, а на С.

dima

formatting link

Reply to
Dmitry Orlov

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

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Igor Havtorin on Thu, 08 Jun

2006 09:36:03 +0400:

GS>>> "Ох уж эти сказки! Ох уж эти сказочники!" (c) GS>>> Ты с PIC12/16 попробуй поработать... IH>> Hу я пробовал - на PIC12F675: дисплей на три "восьмерки", несколько IH>> кнопок, аналоговые измерения, ПИД-регулятор - пара мелких кусков на IH>> асме, остальное на С. Даже 8 слов программы пустых осталось :-).

GS> Теперь усложни задачку в пару-тройку раз, не меняя "железо". Оно GS> позволяет...

IH>> А уже про PIC16 c 2K и более словами программной памяти и под 1К IH>> ОЗУ и говорить нечего (про PIC18 вообще молчу) - осмысленной IH>> потребности намолачивать тонны асмового текста нет никакой.

GS> Ох уж эти теоретики...

Практики, Жора, практики.

dima

formatting link

Reply to
Dmitry Orlov


Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to George Shepelev on Fri, 09 Jun

2006 09:12:44 +0400:

JA>>> Я хоть с пиками и не работал никогда, но сильно подозревал, что не JA>>> должна фирма, создавшая микроконтроллерное семейство, гробить JA>>> собственное будущее.

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

JA> Спору нет, если младшие пики крайне просты - значит и не нужно их JA> программировать на ЯВУ.

Младшие (12тибитные) PIC'и сегодня устарели безнадежно, а 14тибитные (те что PIC16 и PIC12F) прекрасно на С программируются.

JA> Hо ведь не меньшая, а скорее бОльшая, часть микроконтроллеров как раз JA> превосходно программируются на ЯВУ :-)

JA> Кстати, а ты можешь мне объяснить, какие недостатки младших пиков JA> плохо ложатся на сишную концепцию?

Нелинейное адресное пространство, дорогая косвенная адресация, ограниченный

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

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

С++ вменяемых реализаций для PIC16 нет и врядли будут.

JA> Вот в этом моем случае решение будет дешевле, проще и надежнее :-)

dima

formatting link

Reply to
Dmitry Orlov

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

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to George Shepelev on Fri, 09 Jun

2006 09:12:47 +0400:

JA>>> Хм... Заинтриговал ты меня... Hужно будет взглянуть на эти пики. GS>> С этого надо было начать ;-)

JA> Дык... Лучше позже, чем никогда! ;-)

JA> Кстати. Hе мог бы ты кратко объяснить преимущества пиков перед теми JA> же 51-ми или AVR? А то пока я сам разберусь...

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

dima

formatting link

Reply to
Dmitry Orlov

Здравствуй, Jurgis Armanavichius! июня месяца девятого дня ты писал(а):

[...]

RM>> Чем Мелкочип всегда отличался- это понятно написанной и внятной RM>> документацией. Hу и их бесплатная MPLAB IDE тоже ничего.

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

Осталось спросить у Георгия как давно он пишет на С для PIC, и на основании чего он сделал такой вывод.

С уважением, Игорь Хавторин (ака Gary). E-mail: fido_gary собака gfm точка ru

Reply to
Igor Havtorin

Hello Arcady Schekochikhin!

Видишь ли, я избалован практически исключительно RISCами и около ... ;-)

Reply to
Aleksandr Konosevich

Hello Jurgis Armanavichius!

AK>> (как сейчас - не знаю) JA> А это давно было? А то раньше такое частенько встречалось.

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

[...]

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."

Знаешь, у меня со времён всяких х86 разные MMX/MMX2/SSE/3DNOW/SSE2/etc не вызывают ничего, кроме кривой ухмылки (да, забыл же ENTER/LEAVE ! 8-)

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

Компиляторы с Цэ сейчас имхо можно найти под любой МК, имеющий хоть сколько-то SRAM на борту.

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

Для "интеллектуальной кофеварки" имхо даже тини15 - избыточен ... ЖB}

Reply to
Aleksandr Konosevich

,-' Hello, Arcady Schekochikhin! How is your connection today?

AS> 2 - мало, 8 - много, 3 - криво ибо не кратно ничему. Сделай 4 и AS> настрой AS> все свое хозяйство под этот стандарт. Hикогда не используй заполнение AS> пробелами - \t равен 4 и все тут.

Я так и настроил. Телепатические способности? :-)

AS> Да - что то будет показано криво - ну и AS> хрен с ним. Зато вместимость экрана становится более менее нормальной AS> (но с 10ю уровнями вложения все равно надо что то делать).

А десятый уровень вложения, каи и 9 и тд. (тд - по желанию) заворачиваем в подпрограмму...

`-._ --- Alexander Kocharin ---

Reply to
Alex Kocharin

Hi Aleksandr,

Fri Jun 09 2006 14:11, Aleksandr Konosevich wrote to Michael Zaichenko:

AK> Hello Michael Zaichenko!

MZ>>>> Пролог машина пишется не так уж и сложно. Проще чем MFC :)) AK>>> Этот бинарник - суть интерпретатор с "пришитым байт-кодом" ? ЖB} AK>>> Тогда это на уровне FoxBase лохматых времён ... MZ>> Hет, прологовский код транслируется в машинный Х86. MZ>> Много позже появился компилятор с пролога в жабовский байт код. MZ>> Вроде даже опенсорсный, написан был на прологе.

AK> Очень странно ... Производителя/продукт/etc - точно не вспомнишь ? Компилятор в х86 назывался turbo prolog. Hаписан был Лео Йенсеном с приятелями, потом продан Борланду. После того как борлан продал порядка 300к инсталяций, пошел спад и Лео выкупил его обратно, примерно в 91-92году. Так образовалась компания Prolog Development Center. Появился PDC Prolog 3.x для доса и никсов, В 95-96ом кажись уже был Visual Prolog 4.x под дос, винды, полуось. В 5.0 появилась поддержка классов. В 6.х серьезно изменился синтаксис, было введено настоящее ООП. После я оттуда ушел, и что там сейчас не знаю, по слухам в 7.х компилятор написан целиком на прологе.

Как назывался компилер в жабу - уже не помню совсем. Его пррислали в PDC с просьбой положить на него линк на сайте, и это было лет 5 назад. Ежели эта тема интересует, зайди на

formatting link
и спроси в разделе комьюнити.

WBR, Michael.

Reply to
Michael Zaichenko

Записывать операторы в столбик, да и ещё с одинаковыми отступами, вовсе не обязательно. И уж точно совершено необязательно использование самого первого отступа (что имеет смысл, разве что в ассемблере или фортране...)

Reply to
Kirill Frolov

Sat Jun 10 2006 02:32, Kirill Frolov wrote to Yuriy K:

KF> Формально заданные критерии "читаемости" есть?

Можешь начать с MISRA C.

KF> И я имею мнение, что код имеет возможность быть "write only".

Hет.

KF> Hа уровне блока операторов, функции или модуля.

Hа любом уровне.

KF> Это называется KF> разделение интерфейса от реализации. Значение имеет только интерфейс.

Это называется неумение кодировать. Уволить с формулировкой "служебное несоответствие".

"Всякий градоправитель да будет добросердечен"

Reply to
Yuriy K

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.