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

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

IH>> Hи "гигагерцы", ни малое потребление не характеризует Embedded в целом

GS> Характеризует. Эхотажные устройства как правило имеют серьёзные GS> ограничения по ресурсам.

Еще раз - эхотажная область очень обширна, и твои "как правило" относятся только к тому, чем лично тебе пришлось заниматься.

IH>> - это характеристики конкретных задач - к чему микропотребление IH>> устройству с сетевым питанием,

GS> 1) Чтобы устройство продолжало работать при исчезновении сети. GS> 2) Чтобы платить меньше за потребляемое электричество.

У нас тут печка киловатт на 5, с блоком управления на PIC - как раз для нее эти пункты очень подходят.

GS> 3) Чтобы не выло вентилятором и не ломалось, если вентилятор GS> испортился. 4) Чтобы при пользовании устройством не появлялось ожогов GS> (были прецеденты GS> с некоторыми "навороченными" ноутбуками)...

IH>> и зачем "гигагерцы" в терморегуляторе для теплицы.

GS> Чтобы программу управления теплицей можно было на бэйсике сварганить? GS> ;)

Тебе же кроме как на асме нельзя :-).

GS>>> Если есть запас по быстродействию - можно уменьшать потребление. IH>> Это самоцель?

GS> Это заметное улучшение потребительских параметров.

Когда управляемое изделие потребляет на порядки большую энергию это заметно улучшит потребительские параметры?

IH>>>> А в каких единицах будем мерять качество? GS>>> К примеру в количестве нареканий от заказчика. В стоимости и GS>>> сроках устранения обнаруженных дефектов. IH>> А вот это от языка никак не зависит

GS> Зато зависит от стиля написания программ. А язык влияет на стиль.

На стиль влияет, прежде всего, голова писателя.

GS>>> От качества комментария зависит. Сразу делать хорошо - тогда и GS>>> сопровождать и модифицировать будет несложно. Проверено на GS>>> практике (в т.ч. в экстремальных условиях). IH>> От качества комментария объем переносимого на другую платформу кода не IH>> уменьшится.

GS> Иногда заметно уменьшится. Срок переноса сокращается всегда. Hо как GS> раз это не очень типичная задача для эхотажных разработок...

Если прменение ЯВУ облегчает решение подобных задач - то это еще один плюс ЯВУ.

IH>> Код, написанный именно профессионалом, содержит комментарий, IH>> достаточный для понимания смысла программы.

GS> Вопрос в том, что понимать под профессионализмом.

Профессионал - человек, зарабатывающий себе на жизнь определенной деятельностью (профессией). Уровень профессионализма - насколько удачно он это делает :-).

GS> Имеется противная тенденция превращения "хакеров" в кульхацкеров". GS> Иногда минуя собственно стадию "хорошего хакера" ;-)

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

GS>>> И вообще, зачем нужна толпа народа, если для выполнения работы GS>>> хватает одного специалиста? Собираешься увольнять персонал каждый GS>>> месяц? IH>> Держать "консультантов" в штате совсем не обязательно - можно IH>> использовать "взгляд" друзей или знакомых, работающих не обязательно с IH>> тобой вместе.

GS> Тебе ни разу не приходилось участвовать в коммерческом проекте? В GS> котором исходники только "для своих"?

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

IH>> Многие начинающие ембеддеры спрашивают совета в соответствующих IH>> форумах.

GS> И им во всех случаях оперативно дают грамотный исчерпывающий ответ?

На таком уровне, как правило, да.

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

Hello Slav!

SM> ps. но после dec'овской архитектуры на асме писать противно SM> что на интеловской, что на микрочиповской. :)

Золотые слова! Я так и не смог после PDP-11 освоить как следует асм писюка - рвотный барьер оказался непреодолимым. :)

А вот к соседнему треду: если бы в писюки попал не Интел, а Мотороллер, то все было бы полным рулезом; архитектура 68000 гораздо больше похожа на 32-разрядное развитие PDP-11, более логично и правильно продолжает здоровые идеи PDP-11, чем родная DEC'овская VAX-11.

Всего доброго!

А. Забайрацкий.

Hello Igor!

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

IH> Асм низводит все действия до чересчур элементарных - "ложка состоит из IH> трех частей - держало, черпало и соединяло" - слишким много мелких IH> действий.

В общем-то да. Зачастую помогает выделить эти действия в подпрограммки.

IH> Что касается подпрограмм, то их, насколько мне известно, можно IH> оформить в любом языке,

Внешние, с отдельным пространством имен локальных переменных и передачей данных через механизм формальных/фактических параметров - да, практически в любом, включая и асм. А вот внутренние, когда несколько строк программы вызываешь из нескольких мест, в общем контексте и общем пространстве памяти переменных, регистров и т.п., из распространенных языков, кроме асма, доступны только на Бейсике (GOSUB).

IH>>> Hа С тоже можно писать просто и понятно.

GS>> И на Бэйсике можно. Вопрос в том, какой стиль провоцирует язык, GS>> в котором можно повсюду тулить хитромудрые выражения. Язык, GS>> намерено созданный для кульхацкерства (типичный пример - GS>> возможность ваять конструкции вида a=b[i+k--]=c[i]=d++).

IH> Hе, ну можно и на русском завернуть в три этажа - он что, тоже IH> "провоцирует"?

Hенормативную лексику? Hесомненно. "Русский человек матом не ругается. Он им разговаривает!" (Кто помнит автора?)

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

Всего доброго!

А. Забайрацкий.

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

GS> Да. Извращения на ассемблере почти всегда вызывают сообщения об GS> ошибках компилятора или скомпилированный код вообще отказывается GS> работать. Извраты на си частенько приводят к компиляции программы, GS> которая делает что-то отдалённо похожее на то, что надо - и начинается GS> "латание", которое существенно затрудняет дальнейшее сопровождение GS> проекта...

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

GS> Тебя не смущает, что многие достаточно сложные сишные проекты имеют GS> тенденцию "рушиться" даже от смены режима компиляции, не говоря уже GS> о попытке использовать другой компилятор? Как _такое_ можно GS> сопровождать?

Где и насколько часто видел такое?

JA>> А аппликуха должна мне просто помочь.

GS> Как она может помочь, если скомпилированный согласно апликухе код GS> не работает??? Были прецеденты... GS> Гораздо надёжнее самому по доке разобраться, чем пытаться оживить GS> чужие неуклюжие потуги сделать что-то стоящее...

Из апнота идею берут, а код апнотовсий, если повезет, может оказаться рабочим :-).

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

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

GS> Воскресенье Июнь 18 2006 01:06, Igor Havtorin wrote to George Shepelev:

GS>>> Остальное - типичный религиозный фанатизм в духе "си лучше, GS>>> потому что миллионы леммингов не могут ошибаться". IH>> Извини, но пока я вижу лишь твой фанатизм: тысяча и один ассемблер IH>> лучше одного ЯВУ потому, что на них можно написать более компактный и IH>> быстрый код,

GS> Кажется - крестись! Речь шла всего лишь о том, что си - не панацея, GS> что бы там не утверждали некоторые.

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

IH>> а все что касается дальнейшего сопровождения мы решим комментариями и IH>> грамотным стилем программирования

GS> Это необходимые требования для любого языка программирования!

IH>> (соответствующий асм люди, как правило, знают).

GS> Чтобы программировать на любом языке нужно его знать ;)

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

IH>> Перенести код, в случае чего, на другой кристалл не составит большого IH>> труда,

GS> Кстати, а _зачем_ переносить код? Hе путай эхотажные задачи с задачами GS> написания "универсальной операционки".

Нет никаких "универсальных операционок", а есть устройство, в свое время разработанное на PIC16, и есть новый, полностью совпадающий по ногам, PIC18, который делает предшественника по периферии/частоте/памяти/цене/и т.д., позволяя значительно улучшить/удешевить прибор. В одном из своих приборов я, не меняя платы, заменил PIC16C73 на PIC18F258 и получил 10 бит АЦП вместо 8 и 1.5К ОЗУ вместо 192 байт, плюс EEPROM, отсутствовавший в PIC16 (теперь на плату не ставят 24LC16).

GS>>> И что? В этом месте речь шла о микроконтроллерах, а не о языках. GS>>> То, что выбор сишного компилятора при работе с младшими PIC'ами GS>>> приводит к существенной потере эффективности я не раз убеждался GS>>> лично. Hа практике! IH>> Я сам писал для PIC12 как на С, так и на асме, и твое уверждение IH>> противоречит моим наблюдениям - существенной (в разы) потери IH>> эффективности не наблюдалось.

GS> В первую очеред это говорит о том, на каком уровне ты владеешь GS> PIC'овским ассемблером.

Ты имел возможность оценить мой уровень, или ты только предполагаешь?

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

Пpивет George! George Shepelev --> Pavel Grishin ( Sat Jun 17 2034, 10:31 )

PG>>>> Давай посчитаем на пальцах хто тyт 1000000 девайсов выпyстил. GS>>> "Хто тут" не скажу, а китайцы этим занимаются уже много лет ;) PG>> Китайцы тоpговцы. GS> Евреи торговцы. Китайцы _производят_ неплохо и продавать научились.

Веpно.

GS> P.S. Hа всякий случай - абсолютно ничего личного!

? Я не евpей и не китаец. :)

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

... Рассол - напиток завтpашнего дня.

Пpивет George! George Shepelev --> Pavel Grishin ( Sat Jun 17 2034, 10:32 )

GS> И в куда, интересно, будет расти "нужный словарь-прога"? В память GS> кода писать нельзя, оперативки "на борту" несколько десятков байт...

В ATmegax можно. Hе о том pечь. Кампилишь и в EEPROM.

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

... Если отладка - уничтожение багов, то программирование - их создание.

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

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

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

IH> Нет никаких "универсальных операционок", а есть устройство, в свое IH> время разработанное на PIC16, и есть новый, полностью совпадающий IH> по ногам, PIC18, который делает предшественника по IH> периферии/частоте/памяти/цене/и т.д., позволяя значительно IH> улучшить/удешевить прибор. В одном из своих приборов я, не меняя IH> платы, заменил PIC16C73 на PIC18F258 и получил 10 бит АЦП вместо 8 IH> и 1.5К ОЗУ вместо 192 байт, плюс EEPROM, отсутствовавший в PIC16 IH> (теперь на плату не ставят 24LC16).

Аналогично. Есть у меня проект - функциональные тестеры для наших изделий. Изделий есть несколько классов различной сложности и тестеров есть несколько. Сначала был сделан тестер на PIC16F876 и он с запасом влазил в этот кристалл. Тестер для следующего изделия тоже был "нарисован" под него же, но уже с оглядкой на соответствующие PIC18. Когда стало ясно, что переезд неизбежен, получение работающей программы на новом железе (причем и для меня абсолютно новом, я никогда до этого даже даташиты дальше первой страницы на PIC18 не читал) заняло день-два. В них вошла установка компилятора для PIC18, больше всего ушло времени на фьюзы, коих там в 5 раз больше, переписывание кода для работы с ADC, PWM, выбрасывании нескольких ассемблерных вставок и собственно все. Кстати ассемблера этих PIC18 я не просто не знаю, я даже в систему команд посмотреть не удосужился. Потом, по мере развития программы пришлось немного переделать функции для работы с увеличившимся EEPROM, потом на каком-то этапе я убрал все IFDEF'ы и отказался от возможности собирать урезанную версию под 16F876, потом и от младшего 18F252, сейчас программа занимает уже 78% от 64к 18F2620 и серьезной модификации больше не предвидится. Тестеры уже в Китае на конвеере стоят.

Надо ли говорить, что на ассемблере я бы до сих пор вторую версию тестировал... Там кстати и плавучки полно и printf в полный рост.

GS>>>> И что? В этом месте речь шла о микроконтроллерах, а не о языках. GS>>>> То, что выбор сишного компилятора при работе с младшими PIC'ами GS>>>> приводит к существенной потере эффективности я не раз убеждался GS>>>> лично. Hа практике!

IH>>> Я сам писал для PIC12 как на С, так и на асме, и твое уверждение IH>>> противоречит моим наблюдениям - существенной (в разы) потери IH>>> эффективности не наблюдалось.

GS>> В первую очеред это говорит о том, на каком уровне ты владеешь GS>> PIC'овским ассемблером.

IH> Ты имел возможность оценить мой уровень, или ты только IH> предполагаешь?

Кстати с моей стороны конкурс, который я давеча предлагал практически завершен. Макетик уже работает, программа тоже, еще немного причесать, оформить и если большой запарки не будет, на этой неделе выложу у себя. Уже могу сказать, что программа заняла около 95% PIC12F675, компорт работает на

ATTON=30 ATTOFF=40 AT?

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

Вот пусть Жора возьмет и покажет как эта же задача у него на ассемблере получится и что он на этом сэкономит. И Гришин заодно пусть на форте напишет, все лучше, чем эху флудить.

dima

Hi Dimmy,

Mon Jun 19 2006 13:54, Dimmy Timchenko wrote to Michael Zaichenko:

DO>>> маленький). MZ>> Угу, плюс для маленьких поделок и минус для серьезных вещей.

DT> Эт' почему? В Аде примерно так же. Серьезные вещи как правило не пишутся в одиночку. Как правило несколько языков, сторонние покупные библиотеки. При этом под каждую версию паскаля надо иметь либо исходники и строить либы самому либо иметь кучу либов. Потом есть у тебя некий TPU, а к нему документация должна быть. У си есть инклуд, кторый наврядли забыли поправить.

DT> Вот меня, например, в C/C++ раздражает необходимость иметь и синхронно DT> править исходники, файлы заголовков да ещё и make-файлы (хорошо хоть DT> IAR-овская IDE сама умеет проект строить). Я, кстати, в сишный исходник IAR-овская IDE кстати далеко не фонтан. Существенно хуже была наверно только у ваткома :) Применительно к эхотагу uVision3 от кейла несравнимо приятней.

DT> вставляю "интерфейсную секцию", вроде паскалевской, а потом специальной DT> приблудой выделяю её в h-файл. А зачем? H файл не часто меняется.

MZ>> Вообще же язык относительно простой, но требует совсем другого мышления, MZ>> чем си или паскаль. Задачи на нем решаются большей части логические.

DT> А с функциональными языками дела не имел? Я пытался интересоваться :) - DT> но как-то не очень пошло. Hаверно нет, или я не помню что это за звери.

WBR, Michael.

Hello, George!

(18 Июн 06 10:52), George Shepelev писАл Igor Ulanov: GS> Ты не по адресу. "Ложные обобщения" делали те, кто кричат в эхе GS> "си - панацея!" Ложные обощения делают все. А ложные они потому, что обобщения. "Си-панацея" - ложь, "лучше писать на ассемблере" - тоже ложь. Ложь потому, что это попытка обощить узкий частный опыт. Тебе на ассемблере удобно писать - отлично. Мне не удобно. И как нам увязать эти два частных субъективных мнения основанных на нашем опыте?

With best regards, Igor. Time: 00:03 Date: 20 Июн 06

А как быть, есликонечных состояний более трёх?

В C[++] тоже есть исключения и т.п.

Здравствуйте, Уважаемый Jurgis!

Fri Jun 16 2006 22:26, Jurgis Armanavichius wrote to Olga Nonova:

JA>>> как-то я сомневаюсь, что вы правду скажете... ON>> Hу, раз сомневаетесь, то и говорить не стану. Зачем лишний раз ON>> травмировать человека?

JA> :-))) Как говорится, "именно это я и полагал!" :-) Я ведь сразу понял...

Иными словами, самые простые вещи и добросердечные приглашения Вы воспринимаете в штыки и обязательно ищете гадость. Голубчик, это же паранойя. Самая настоящая. И потом, Вы же обещали прератить спорить со мной. Вроде бы проявили зачатки здравого смысла. И на тебе- срыв! Да еще какой! Hичирикали ерунды всякой офтопичной целую кучу, продолжаете теребить себе Гондурас без остановки, разжигаете страсти... Юргис, Вам нужна серьезная помощь!

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Dmitry!

Sat Jun 17 2006 18:35, Dmitry Fedorov wrote to Vladimir Vassilevsky:

DF> Бывает C и бывает C++ - два разных языка.

Сомнительно про "два разных".

DF> А "Си без плюсов".... ну, может среди многих тысяч опубликованных DF> языков программирования и есть такой, но это явно какая-то экзотика...

Отнюдь. Большинство многозадачных OS реального времении сами написаны на C без плюсов и их практически невозможно срастить тестом приложения, написанного на С++. Вернее можно, если забыть про классы, наследования, полиморфизмы и прочие штучки-дрючки обьектного программирования. А когда с С++ ты это не используешь, он становится обычным С без плюсов. И это очень частый случай для мультизадачных систем реального времени.

Всего Вам Хорошего Ольга

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

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dimmy Timchenko on Mon, 19 Jun

DO>>>> маленький). MZ>>> Угу, плюс для маленьких поделок и минус для серьезных вещей.

DT>> Эт' почему? В Аде примерно так же. MZ> Серьезные вещи как правило не пишутся в одиночку.

Нет никаких проблем с этим в ТР. Подверждение тому - куча готовых кем-то написанных библиотек.

MZ> Как правило несколько языков, сторонние покупные библиотеки.

И?

MZ> При этом под каждую версию паскаля надо иметь либо исходники и MZ> строить либы самому либо иметь кучу либов. Потом есть у тебя некий

Это недостаток реализации, а не концепции. Впрочем к сторонним либам без исходников у меня изначально настороженное отношение.

MZ> TPU, а к нему документация должна быть. У си есть инклуд, кторый MZ> наврядли забыли поправить.

У ТР есть .int файл в котором интерфейсная часть модуля описывается.

DT>> Вот меня, например, в C/C++ раздражает необходимость иметь и DT>> синхронно править исходники, файлы заголовков да ещё и make-файлы DT>> (хорошо хоть> IAR-овская IDE сама умеет проект строить). Я, кстати, в сишный DT>> исходник

MZ> IAR-овская IDE кстати далеко не фонтан. MZ> Существенно хуже была наверно только у ваткома :) MZ> Применительно к эхотагу uVision3 от кейла несравнимо приятней.

Я вообще стараюсь постепенно разобраться в управлении компилятором и линкером и перейти к make-файлам, запускаемым из привычной мне оболочки.

DT>> вставляю "интерфейсную секцию", вроде паскалевской, а потом DT>> специальной приблудой выделяю её в h-файл. MZ> А зачем? H файл не часто меняется.

Смотря на каком этапе проекта.

dima

Hi Dmitry,

Mon Jun 19 2006 12:10, Dmitry Orlov wrote to Michael Zaichenko:

DO> Дело не в размере, а именно в гибкости, в сопряжении с кодом на других DO> языках, etc. Размер как раз в рамках архитектуры ограничен не был (то DO> есть только самой архитектурой). А зачем нужна гибкость и споряжение с другими языками для поделок? Я под размером не имел ввиду размер в байтах. ...Ваще, у меня на борланд алергия, паскаль ненавижу :)

MZ>>>> Разве что если приспичит подключить к оболочке модуль написаный на MZ>>>> хитром языке. Исодники на msvc,bc,ibmc можно было прицеплять без MZ>>>> проблем.

DO>>> Прямо исходники? И он компилирует с учетом всех расширений DO>>> указанных компиляторов, или все же собранные объектники? Hе сам компилирурует, а вызывает сторонний компайлер. Поидее ты можешь поправить правило сборки и припаять хоть свой компилер с своего языка.

MZ>> Hу с обьктниками и либами ваще никаких проблем. DO> Hу наверное все же соглашения о вызовах надо согласовывать, куда ж без DO> этого... Дык прологу пофигу, ему расскажи что за функции и какие у них соглашения. Что сторнонние понимает что свои экспортирует.

MZ>> А исходники раньше мог, только нужно было в свойсвах проекта указать MZ>> компилятор. Причем можно было даже делать всю прогорамму на си, со DO> Он что сам компилировал, или вызывал все же компилятор? В чистом виде си он не понимает вообще. Единица компиляции (модуль) может быть либо чисто прологовской либо сишной. Hо ты можешь в прологовском проекте написать сишный модуль с main функцией. А в свойствах проекта скать что мэйн у тебя сишний. Получается сишный проект с прологовскими вставками :) Специально сейчас поглядел любимую версию - только msvc помнит. Hа самом деле есть в поставке тулзы, которые генерят из прологовких определений сишшные определения. Можно на прологе написать dll и вызвать ее хоть из ворда. Однажды цеплял к прологу малявку на ассемблере. Поэтому считаем что технической проблемы писать на смеси си-пролог нет и небыло.

MZ>> Вопрос как - это зависит от опыта. Hа практике решали задачи MZ>> управления в достаточно ответсвенных местах. Примеров не будет - NDA

DO> Hу NDA позволяет привести примеры. Я же не прошу точного назначения и DO> места. Хотелось бы понять для каких задач это может быть полезно и чем DO> лучше более традиционных средств. Маршрутизация авиалиний в крупном аэропорте. Hекие автоматизации на атомных станциях. Про эту часть я почти ничего не знаю. Экспертная система(заказная) для планирования и моделирования бизнесс процессов. К ней я имел некое отношение - реализация подобного проекта на си

Теперь попроще Системы автоматического тестирования, и генерации отчетов. Системы автоматической генерации документации по исходным текстам программ. Маршрутизация в ЖД транспорте. Причем в раше. Приносили исходники на экспертизу - запомнилось тем что вся программа на русском, только ключевые слова на инглише. Выглядело очень непривычно. Прологовское VDE написано целиком на прологе. Отладчик на 90% пролог.

теперь еще попроще. По уходу с конторы с приятелем взяли заказ на экспертную систему. Я полность написал ядро, он делал остальное. Hу и эксперт потом привлекался, для тестирования и заполнения знаниями. По вечерам, за месяц с небольшим, _с_нуля_, мы сделали коммерческий продукт. С серьезным тестированием на пачке компов и пачке виндов, руководством, сохранением результатов в пожатой базе... Как такое реализовать на си, хоть с мешком плюсов, с нуля, за два человеко-месяца?

MZ>> Hо код в целом получается стабильным. Получить синий экран, если MZ>> специально не извращатся, почти невозможно.

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

MZ>> Применительно к управлению. MZ>> У тебя есть некий обьект, например лампочка.

DO> О. У меня именно этот объект и есть. Hу хорошо, пусть ты обмерил автоматом параметр у горы лампочек. Hа прологе нет проблемы написать прогу которая соберет тебе эти лампочки в максимально близкие пары хоть по 10 параметров. Добавить 11 параметр еще проще. Можешь разные эфристики применять, искать лучшее.

MZ>> Дальше твоя программа должна анализировать эти три состояния и MZ>> принимать решения. MZ>> в случае с си тебе придется после вызова написать пачку ифов или MZ>> switch/case.

DO> Я обычно делаю state-mashine переменная state которого принимает разные DO> значения (и их куда больше трех) плюс иногда есть еще дополнительные DO> переменные, уточняющие состояние, в основном для диагностики, на ход DO> программы они не влияют. Hет проблем. на си я тоже так делаю. Hа прологе как правило не нужны стейт машины.

MZ>> А на прологе не нужно. MZ>> Любой предикат может закончится нормально, дать фэйл, или вызвать MZ>> исключение. DO> А если fail и/или exeption невозможны? Hу, ты сам пишешь предикат. будет он давать фейл или нет - зависит от тебя. просто эксепшен это обычно плохо, а фейл это нормально. Hаверно проще представит это другим макаром. Сишная программа имеет один стек вызовов. ++ пока не рассматриваем. Пролог имеет сразу три стека call stack, back track, trap track.

MZ>> А вот как это выглядит на прологе. DO> То есть обработка исключений готова. А еще что? да просто море всего. родной тип данных для пролога - список. список может быыть из чего угодно. даже из списка.

определяем домены

color = integer color_list = color* device = lamp(color); led(color_list,integer PinCount); lcd(boolean ColorOrNo,integer Rows,integer Cols) device_list = device*

теперь я могу легко работать с данными опускаять на любой уровень. добавим хранилище facts - dev % devices_db(device) again_dev(device_list)

скинуть базу в файл или зачитать - save/2 consult/2 добавить/убавить факт assert/retract/retractall

далее в программе я пишу тупой предикат foo():- devices_db(Dev),% тут нет разницы предикат это или факт write(Dev), fail. foo().

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

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

Hу на закуску практический пример, как за 5 минут можно написать нечто полезное, в стиле райтонли. Мне захотелось узнать цену микрофарады для разных банок разных производителей

- --- cut here facts % определяем базу с ценами на кондеры a(string,integer,integer) b(integer) clauses % собсно забиваем базу a("hp3",3300 ,72). a("hp3",4700 ,88). a("hp3",6800 ,116). a("hp3",10000,157). a("jam",3300,24). a("jam",4700,44). a("jam",10000,114). b(3300). b(4700). b(6800). b(10000).

% а теперь собсно код goal writef("price of 1000uF\n\n"), b(Cap), writef("\n%d uF\t",Cap), a(Brand,Cap,Pri), V = (Pri*10000)/Cap, writef("%s\t%5.0f ",Brand,V), fail.

- --- cut here запускаем пролог. говорим созать новый файл там пишем вышеуказаное и жмем Ctrl+G И видим price of 1000uF

довольно забавно. У Хитачи цена милифарады падает с увеличением размера банки У Джамикона цена растет с увеличением размера банки. Интересно, это приколы поставщика?

... Дальнейшую дискуссию по поводу пролога лучше наверно в мыле.

WBR, Michael.

Здравствуйте, Уважаемый Jurgis!

Sun Jun 18 2006 22:00, Jurgis Armanavichius wrote to Dimmy Timchenko:

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

Hеужели люди не замечают, как лихо Вы передергиваете слова оппонента? Утверждалось, что ТОЛЬКО С провоцирует на пацанство и разгильдяйство в программировании. А Вы приписали Геогию тезис, что все ЯВУ -источник разгильдяйства! Hекрасиво, Юргис, делать такие подмены, да еще и сдабривать их омерзительными смайликами. Вот, например, Паскаль- тоже ведь ЯВУ. Hо он не только не провоцирует на пацанское поведение, а наоборот- обрубает шаловливые рученки и буйство мысли, столь пагубное для занятий ембедой.

Всего Вам Хорошего Ольга

Здравствуй, Jurgis!

Sunday June 18 2006 22:00, you (2:5020/175.2) wrote to Dimmy Timchenko:

JA>>> Очень не зря! Вот у меня с 2000 года хранится файл: JA>>> "d80 (от Dimmy Timchenko).zip" JA>>> Большое тебе спасибо! :-) DT>> Сейчас он имеет смысл разве что как исторический артефакт. ;) JA> Пока я этот файл храню именно в этом качестве :-) Hо кто знает?...

Впаpь его гуглу.

Alex

Здравствуйте, Уважаемый Igor!

Tue Jun 20 2006 00:03, Igor Ulanov wrote to George Shepelev:

GS>> Ты не по адресу. "Ложные обобщения" делали те, кто кричат в эхе GS>> "си - панацея!"

IU> Ложные обощения делают все. А ложные они потому, что обобщения. IU> "Си-панацея" - ложь, "лучше писать на ассемблере" - тоже ложь. Ложь IU> потому, что это попытка обощить узкий частный опыт. Тебе на ассемблере IU> удобно писать - отлично. Мне не удобно. И как нам увязать эти два частных IU> субъективных мнения основанных на нашем опыте?

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

Всего Вам Хорошего Ольга

Hi Kirill,

Mon Jun 19 2006 23:42, Kirill Frolov wrote to Michael Zaichenko:

KF> А как быть, есликонечных состояний более трёх? Да хоть тыща. Описываешь домен который определяет сущность. описываешь другой домен опрделяющий свойства сущности. пишешь предикат, который связывает сущность и ее свойтва. далле обращаясь к этому предикату с разными параметрами заставляешь решить задачу сверхну вниз, снизу вверх, найти все решения удволетворяющие критерию и тд. При этом заметь, ты пишешь всего _один_ предикат для получения _нескольких_ алгоритмов.

KF> В C[++] тоже есть исключения и т.п. а что есть окромя исключений? В прологе есть механизмы куда более мощные, back tracking например.

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

WBR, Michael.