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

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

KF> KF> Точно также, например, как отличается русская и латинская раскладка KF> клавиатуры, Vim различает режим ввода текста и командный режим.

Жуть какая. Впрочем, наверно можно и к такому приспособиться.

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

Reply to
Yuriy K
Loading thread data ...

Hi George,

Fri Jun 09 2006 10:45, George Shepelev wrote to Pavel Grishin:

AK>>> Микроконтроллеры тоже на си предлагаешь программить? PG>> Бывает и баpсике пpогpаммят. Абы pесypсов хватало. PG>> Уже не модно yкладывать пpодвинyтые пpоги в 1K. :)

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

WBR, Michael.

Reply to
Michael Zaichenko

s/скажет/может сказат/. А может и не сказать.

Вот-вот. Надо нать что такое ERROR в данном контексте. И что такое ERROR в другом контексте...

Учитесь у создателей библиотеки языка C. Местами немного горбато, но всё же сильно лучше (хоь бы в силу простоты и понятности) чем в стиле микрософт.

Java. C-два-креста и C -- это всё же сильно разные языки.

Reply to
Kirill Frolov

f1, f2, f3...

Reply to
Kirill Frolov

Тебе -- засчитан.

-Wall?

Мандрейк суксь, дебиан рулит.

Reply to
Kirill Frolov

В религии. Ни в чём больше. Так же полагается скобочки расставлять строго по уставу и прочие маразмы.

Хотя тут действительно криминал есть. В самом понятии бинарного флага. Но к языку это никаким боком.

Reply to
Kirill Frolov

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

И я имею мнение, что код имеет возможность быть "write only". На уровне блока операторов, функции или модуля. Это называется разделение интерфейса от реализации. Значение имеет только интерфейс.

Reply to
Kirill Frolov

Точно также, например, как отличается русская и латинская раскладка клавиатуры, Vim различает режим ввода текста и командный режим.

Reply to
Kirill Frolov

Возможно, что через год, но работающую.

Reply to
Kirill Frolov


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

2006 09:45:11 +0400:

AK>>> Микроконтроллеры тоже на си предлагаешь программить? PG>> Бывает и баpсике пpогpаммят. Абы pесypсов хватало. PG>> Уже не модно yкладывать пpодвинyтые пpоги в 1K. :)

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

Вот их, Жора, и сэкономили убрав ISA из PC и rs232 из большинства лэптопов.

dima

formatting link

Reply to
Dmitry Orlov

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

KF> И я имею мнение, что код имеет возможность быть "write only". KF> Hа уровне блока операторов, функции или модуля. Это называется KF> разделение интерфейса от реализации. Значение имеет только интерфейс.

Да без проблем. В таком случае этот код ничем не полезнее, чем obj или lib. То есть оплачивается не как разработка, а как единица готового изделия. BTW, некоторые библиотеки так и продаются, в виде write-only кода, причем зачастую машинно-генеренного.

VLV

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

Reply to
Vladimir Vassilevsky

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

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to George Shepelev on Sat, 10 Jun

2006 02:09:26 +0400:

AK>>>> Микроконтроллеры тоже на си предлагаешь программить? PG>>> Бывает и баpсике пpогpаммят. Абы pесypсов хватало. PG>>> Уже не модно yкладывать пpодвинyтые пpоги в 1K. :)

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

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

Жора пробовал об этом рассуждать, а делать даже 10-тысячный не пробовал. У наших разработок тираж в десятки тысяч в год, программы для PIC16 _только_ на С. Ничто другое всерьез вообще не рассматривается, никому не нужен несопровождаемый и немодифицируемый ассемблерный код. Тем более, что экономия в разы - это бывает только на мелких или специально подобранных алгоритмах, обычно разница куда меньше и уменьшение просто так не дает ничего. Код или влазит в выбранный (прежде всего исходя из имеющейся периферии) контроллер или нет. Если влазит, то запас там двукратный, или 5% никого не волнует. Да и разница в цене между скажем одинаковыми по периферии F73 и F76 - значительно меньше доллара, особенно при многотысячных тиражах. Модифицируемость под нужды конкретного заказчика, сопровождаемость, переносимость и source-level наследуемость кода куда важней. Рынок очень гибок. С одни и тем же дизайном, на уровне железа и софта высеченным в камне далеко не уедешь, так что альтернатив ЯВУ просто нет. Это любитель, которому ценен сам процесс может позволить себе вылизывать ассемблерный код. Когда нужен и важен результат (а нужен он обычно вчера) нужно применять максимально ускоряющие разработку инструменты.

dima

formatting link

Reply to
Dmitry Orlov

Hello,Michael !

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

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

"Я вот поднимал штангу 500кг. Не может быть, говоришь ? Поднимал! Я же не сказал, что поднял :-) " (Из народного)

WBR G.G.

Reply to
Gena Gutnicky

Hello,Arcady !

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

AS> a 1/12 для i51 тебя не напрягли?

А как вам 52 цикла осциллятора на команду ? Это ST60 (бывший Томсон). Мне на этой пакости пришлось довольно солидный прибор лепить ( тип проца выбрал заказчик :-( Там даже сдвига вправо нет - программно. Можете представить мои чувства, кога из этого, гм... перешел на АВРы.

WBR G.G.

Reply to
Gena Gutnicky

Привет Alex!

09 Июн 06 года (а было тогда 13:54) Alex Mogilnikov в своем письме к Andrey Bivshih писал:

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

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

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

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

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

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

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

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

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

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

Да я так и поступаю.

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

formatting link
E-Mail:a_biv<саба>list,ru Jabber:Andrey_B@jabber,ru |СQ:226793191

Reply to
Andrey Bivshih

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

Пятница Июнь 09 2006 07:45, Jurgis Armanavichius wrote to George Shepelev:

GS>>>> И всё? А не маловато ли опыта, для столь глобальных обобщений? JA>>> Я считаю, что более чем достаточно. GS>> Hапрасно считаешь. JA> (Вкратчиво) А обосновать это утверждение сумеещь?

Уже обосновывал. Практическим опытом программирования для PIC-контроллеров. Hа сях многие делали (причём умеющие делать это хорошо), а получалось всегда заметно хуже, чем у меня на асме...

GS>>>> Ты с PIC12/16 попробуй поработать... JA>>> С пиками я не работал. GS>> А ты сперва поработай, тогда и пытайся "глобальные обобщения" GS>> выдумывать! JA> Hа твоих пиках свет клином сошелся?

Для довольно большого ряда задач - да. Подтверждается объективной статистикой выпуска контроллеров разных семейств.

JA>>> Если для пиков не существует хорошего компилятора, то можешь это JA>>> семейство микроконтроллеров вычеркнуть из списка программируемых JA>>> на C/C++. Все же остальные - только ЯВУ! GS>> Это из серии "если факты не укладываются в теорию - тем хуже для GS>> фактов" ;) По мере набора практического опыта - должно пройти... JA> Да, с логикой у тебя не очень... При чем тут факты?

Так это у тебя с логикой не очень, ведь именно ты факты игнорируешь ;-)

JA> Ты ж ни единого факта не привел, что ЯВУ для микроконтроллеров вреднО.

При чём тут вредность? Ты завёл разговор в духе "ЯВУ - панацея", а это абсолютно ошибочное высказывание! Точка.

Георгий

Reply to
George Shepelev

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

Пятница Июнь 09 2006 09:12, Jurgis Armanavichius wrote to George Shepelev:

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

Голословное утверждение. Существует множество систем, где на один мощный "центральный" контроллер приходятся десятки, сотни, а то и тысячи простейших "периферийных" контроллеров. Обычно решающих отличающиеся задачи, потому имеющие разные прошивки. Результат - бОльшая часть софта будет написана не на ЯВУ.

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

Hе могу не приветствовать перехода к более конструктивному обсуждению ;) Вот набор специфических проблем:

Крайне маленький стек, существенно ограничивающий вложенность подпрограмм.

Широкий набор очень удобных "битовых" и ниббловых операций, которые довольно криво описываются в "классическом" C.

Крайняя убогость работы с указателями, которые весьма широко используются в конструкциях "классического" C.

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

Очень эффективная реализация алгоритмов с "аккумулятором" и "флагами состояний" контроллера, если такие возможности не учитывать при написании программ - код получается крайне неэффективным.

"Кривая" реализация выборки значения из таблицы - через вызов команды retlw, причём адресация к таблице не должна выходить за 256 значений. Если эту особенность не учитывать при написании программ - опять получается крайне неэффективный код.

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

По сути единственный вектор прерывания контроллера существенно меняет концепции программирования при поддержке широкого набора "внутренней периферии", которой так богаты современные PIC'и.

Это так, навскидку...

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

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

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

Сперва пусть появятся эти самые мифические микроконтроллеры с реализацией High Speed USB...

Георгий

Reply to
George Shepelev

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

Пятница Июнь 09 2006 09:12, Jurgis Armanavichius wrote to George Shepelev:

JA>>> Хм... Заинтриговал ты меня... Hужно будет взглянуть на эти пики. GS>> С этого надо было начать ;-) JA> Дык... Лучше позже, чем никогда! ;-) JA> Кстати. Hе мог бы ты кратко объяснить преимущества пиков перед теми же JA> 51-ми или AVR?

Меньше потребление, существенно выше помехоустойчивость, очень неплохая совместимость в пределах семейства и даже между семействами, что даёт возможность без особого труда развивать проект, низкая цена, очень удачные модули ADC, PWM, USART, I2C...

Георгий

Reply to
George Shepelev

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

Пятница Июнь 09 2006 09:12, Jurgis Armanavichius wrote to Ruslan Mohniuc:

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

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

Георгий

Reply to
George Shepelev

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

Пятница Июнь 09 2006 11:56, Ruslan Mohniuc wrote to Jurgis Armanavichius:

RM> Совсем недавно 09 Jun 06 08:45, Jurgis Armanavichius писал к George RM> Shepelev: JA>> Да, с логикой у тебя не очень... При чем тут факты? Ты ж ни JA>> единого факта не привел, что ЯВУ для микроконтроллеров вреднО. А JA>> вот я привел свой практический опыт, на который тебе, конечно, JA>> наплевать, я понимаю. RM> Hе напрягайся, это разговор с глухим. Hе пробовал и не собирается RM> пробовать.

Тебя мама в детстве не учила, что лгать нехорошо?

RM> Просто не трать время.

"Hачни с себя" (c)

Это совет.

Георгий

Reply to
George Shepelev

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.