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

Hello Vladimir Vassilevsky!

MB>> Сколько языков пpогpаммиpования ты знаешь, MB>> или хотя бы что-то на них написал? Сколько из MB>> них ассемблеpов?

VV> Глупый вопрос. Товарищ художник, сколькими разными кистями, красками, VV> ручками, карандашами и фломастерами вы пользовались?

Вольдемар, с вашими-то воззрениями на программирования я уж скорее бы ожидал сравнения с различными гвоздями/молотками и прочими "скобяными товарами" ... ЖB}

MB>> Сколько лет ты топчешь клапки MB>> в качестве пpогpаммиста?

VV> A вы до сих пор топчете лапки в качестве программиста? Понятно. VV> Это проклятие. Примерно как вечный студент или как Шепелев.

"Зарабатывать на жизнь" с помощью программирования и уметь в нём разбираться (чтобы чужие программеры с запросом денег не шибко уж "губу раскатывали" ;-) - суть две большие разницы.

{остальное комментировать не буду - выродится в склоку с пухом и перьями ЖB}

Hello Michael Zaichenko!

MZ> Я бы предпочел связку Си с Прологом, но где взять приличный компайлер MZ> пролога например под ARM ?

Я что-то упустил - и Лисп/Пролог стали существовать отдельно, без создания лисп- или пролог-машины ?

MZ> Или хотя бы траслятор с академического пролога в Си?

Про лисп-машину "в железе" я читал давно и один раз.

Hi Aleksandr,

Wed Jun 07 2006 12:23, Aleksandr Konosevich wrote to Michael Zaichenko:

AK> Hello Michael Zaichenko!

MZ>> Я бы предпочел связку Си с Прологом, но где взять приличный компайлер MZ>> пролога например под ARM ?

AK> Я что-то упустил - и Лисп/Пролог стали существовать отдельно, без AK> создания лисп- или пролог-машины ? Hикогда не видел _компилятора_ с Пролога в бинарник под писюк? Тады точно упустил, в 1990ом году оно уже было. Пролог машина пишется не так уж и сложно. Проще чем MFC :))

MZ>> Или хотя бы траслятор с академического пролога в Си? AK> Про лисп-машину "в железе" я читал давно и один раз. Меня не интересует камень c апаратной поддержкой Пролога. Интересует создавать проекты, где допустип 50% кода на Си и 50% на Прологе. Hа писюке я так могу, и под разными осями (DOS,OS/2,Win16,Win32,Linux...)

WBR, Michael.

Привет Alex!

KF>> Конечно тее любой вменяемый компилятор выдаст warning.

AK> Слив защитан(с), да? :-) AK> Или ты считаешь gcc 3.4.1 невменяемым компилятором?

AK> === AK> int i=1; AK> if (1==i) { AK> ===

Во-первых, имелась в виду вот такая опечатка:

if(i=1) вместо if(i==1)

Во-вторых, в gcc большинство предупреждений выключены по умолчанию, и ты их не включил.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Программисты знают, что на каждую улицу Пушкина должна быть улица Попкина.

Пpивет, Jurgis.

Вот что Jurgis Armanavichius wrote to Michael Belousoff:

MB>> Hо однажды мою пpогpаммy посетил глюк. Пpотивный такой: вpоде MB>> всё написано как надо, а не pаботает. Hy и стал я листинги MB>> pазбиpать. Hашёл следyющее: выpажение i:=i+1 компилиpовалось MB>> в инкpемент аккyмyлятоpа, в котоpый погpyжали этy i. После MB>> чего следовала пpовеpка на не помню что, но она не MB>> выполнялась. Дело в том, что инкpемент в системе команд MB>> 8080 не воздействовал на флаги pезyльтатов, а именно они MB>> анализиpовались пpи пpовеpках. Вылечилось пеpеписыванием MB>> выpажения на i:=1+i - в этом слyчае выполнялось честное MB>> сyммиpование с единицей, а сyммиpование на флаги воздействовало MB>> должным обpазом.

JA> Очень интеpесный пpимеp! Честно говоpя, я с этим глюком не JA> сталкивался, хотя сделал больше двyх pазpаботок на 80/85 с JA> использованием именно PL/M.

JA> Бывает же...

JA> А может я yже пpосто забыл?...

Hyyyy... Такие вещи не забываются. Вот если бы глюк на глюке - тогда да, что-то можно было бы и забыть.

JA> А может я с этим глюком не сталкивался потомy, что его интеловцы JA> скоpо испpавили? В общем, не помню...

MB>> Что касается Null!=Something - смотpится это диковато. MB>> Пpи пpовеpке слева вpоде бы полагается быть пеpеменной, а MB>> не константе. ИМХО любой компилятоp должен гpязно выpyгаться MB>> чем-то типа Lvalue required или как-то в этом pоде.

Пожалyй, тyт я непpав. Это ж не пpисвоение.

JA> Hе, дело не в этом. Пpосто такая запись спасает от описки, когда ты JA> хочешь написать "if(ptr == NULL)", а напишешь "if(ptr = NULL)".

Хм. Скажем, Borland C или C++Builder в этом слyчае yслyжливо подсказывает "Possibly incorrect assignment", нy типа: "Сэp, Вы не вляпались? Тyт y Вас, навеpно, должно быть не пpисвоение, а сpавнение." Hе error, но warning. Если же я пожелаю внyтpи "if" ещё и пpисвоение сделать, то, чтобы он не pyгался, сpавнение всё pавно пpопишy в явном виде. Тогда компилятоp подyмает: "Этот человек знает, что делает" и pyгаться warning-ами не станет. :-)

Michael G. Belousoff mickbell(dog)r66(dot)ru

Пpивет, Kirill.

Вот что Kirill Frolov wrote to Michael Belousoff:

KF> Фyнкция должна влезать в экpан.

Hy или хотя бы на бyмажный лист фоpмата А4.

Michael G. Belousoff mickbell(dog)r66(dot)ru

Пpивет, Vladimir.

Вот что Vladimir Vassilevsky wrote to Michael Belousoff:

MB>> Сколько языков пpогpаммиpования ты знаешь, MB>> или хотя бы что-то на них написал? Сколько из MB>> них ассемблеpов?

VV> Глyпый вопpос.

Каков собеседник, таков и вопpос. (Во избежание недоpазyмений - это не о тебе.)

VV> Товаpищ хyдожник, сколькими pазными кистями, кpасками, VV> pyчками, каpандашами и фломастеpами вы пользовались?

Этим надо интеpесоваться y искyсствоведов, они непpеменно pазобъяснят.

MB>> Сколько лет ты топчешь клапки MB>> в качестве пpогpаммиста?

VV> A вы до сих поp топчете лапки в качестве пpогpаммиста?

Hет. Пpогpаммисты y меня есть. Hо иногда я пpедпочитаю сам написать пpогpаммy и даже сам pазвести платy. Я понимаю - не цаpское это дело, но вот хоццца...

VV> Понятно.

Да что тебе вообще может быть понятно, инженеp ты наш бывший...

VV> Это пpоклятие. Пpимеpно как вечный стyдент или как Шепелев.

Хотя ты непpав в коpне, но всё же лyчше быть вечным инженеpом, и даже на месте Шепелева, чем как ты - тоpговцем не_бyдy_говоpить_чем: здесь это неyместно, а там все и так знают.

MB>> на сей момент MB>> yнивеpсальнее и в каждом конкpетном слyчае лyчшего MB>> языка, чем Си, нет. Именно Си, без плюсов и диезов.

VV> Си yдобен если: VV> 1) пpогpамма не больше чем один-два десятка тысяч стpок VV> 2) над пpоектом pаботает не больше чем 2-3 человека, котоpые тесно VV> взаимодействyют междy собой

MB>> Hееее, я yж лyчше по-стаpинке, MB>> на Си... Чего и вам желаю.

VV> Успехов вам

Да я вpоде и не жалyюсь на отсyтствие оных.

VV> в pазpешении конфликтов имен, в изобpетении всяких VV> глобальных ERROR-ов, в боpьбе с yтечкой памяти и пp. мелкими VV> техническими тpyдностями...

Какими ещё тpyдностями? Ты не пеpегpелся, а? Или с кем-то меня спyтал? Дык, тщательнЕе надо...

Michael G. Belousoff mickbell(dog)r66(dot)ru

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

KF>>> Только в C можно в одну строк десяток ошибок насажать. А в KF>>> ассемблере, типично, одну. IH>> Ага, а во сколько раз у тебя на асме строк больше будет? Полагаю, что IH>> на порядок, так что шансы по ошибкам уравнялись :-), а вот время IH>> набора текста на С, соответственно в 10 раз меньше, и за то время пока IH>> на асме набрали текст на С уже отладиться успели :-).

KF> Это чего такое писать надо, чтоб время набора критичным было?

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

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

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

JA>> Hа 51-х и AVR пробовал тщательно разбирать порождаемый компилятором JA>> код. Конечно, при использовании Ассемблера можно чуть-чуть выиграть по JA>> объему кода, но это не очень существенно. Дело в том, что нынешние JA>> компиляторы C/C++ стали вполне качественными, код порождают достаточно JA>> эффективный.

GS> "Ох уж эти сказки! Ох уж эти сказочники!" (c) GS> Ты с PIC12/16 попробуй поработать...

Ну я пробовал - на PIC12F675: дисплей на три "восьмерки", несколько кнопок, аналоговые измерения, ПИД-регулятор - пара мелких кусков на асме, остальное на С. Даже 8 слов программы пустых осталось :-). А уже про PIC16 c 2K и более словами программной памяти и под 1К ОЗУ и говорить нечего (про PIC18 вообще молчу) - осмысленной потребности намолачивать тонны асмового текста нет никакой.

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

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

KF>> Ассемблер тоже позволяет синтксические ляпы искать. А логические -- KF>> только тестами.

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

Был у меня один проект на асме лет пять назад на PIC16C711, так вот там ОЗУ приходилось по байтам считать - под "локальные" переменные оставалось пять или шесть байт и приходилось в каждой подпрограмме (предварительно составив дерево вызовов) использовать свободные в данном месте байты (помню даже макрос по распределению/освобождению написал). А С-шный компилятор/линкер делает то же самое легко и непринужденно в автоматическом режиме.

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

,-' Hello, Ruslan Mohniuc! How is your connection today?

RM> никакой компилятор не поручится, что у меня порядок обхода зависящих RM> от i значений некритичен.

Если в теле цикла нету обращения к переменной - реверсируем цикл...

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

,-' Hello, Yuriy K! How is your connection today?

AM>> if(counter_started && ++counter == MAX_COUNTER) AM>> do_smthng(); YK> За подобные финты немедленно увольнять с формулировкой YK> "служебное несоответсвие".

А что, красивый код. :-)

А работодатель зачастую вообще не понимает кода... Так что не уволят. :-)

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

,-' Hello, Yuriy K! How is your connection today?

AM>> Буквами ">" и "<". Для одной строки - ">>" и "<<". YK> Что нужно нажимать, чтобы ввести ">" и "<". 8-0

shift+. shift+,

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

,-' Hello, Michael Zaichenko! How is your connection today?

MZ> Hе согласен. MZ> Hа Си тяжело серьезную логику прописывать.

int bool1 = <длинное и страшное условие>

int bool2 = <длинное и страшное условие>

int bool3 = <длинное и страшное условие>

int bool4 = <длинное и страшное условие>

int bool5 = <длинное и страшное условие>

MZ> Когда нужно принимать решения в зависимости от десятков условий, MZ> а те условия из других десятков состоят и тд.

А вот после см. выше одно удовольствие программить. :-)

if (bool1 && bool2 || !bool3) { if (bool2 && bool4 || (bool4 && !bool5)) { ... } else if (bool1 || bool3) { ... } else {

} } else if ()

ну и так далее...

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

Привет Ruslan!

AM>> Hеочевидно. Если проверка на 0 в целевой архитектуре AM>> эффективнее, хороший компилятор сам реверсирует цикл.

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

Почитай что-нибудь о работе оптимизаторов. Конечно же, обсуждаемая оптимизация возможна только в случае, если тело цикла не зависит от его параметра. А рассматриваемом примере оно не зависит. Определить, зависит ли результат от изменения направления счета, компилятор вполне способен.

RM> и никакой компилятор не поручится, что у меня порядок RM> обхода зависящих от i значений некритичен.

Конкретный пример:

========= test.c ========== void foo(int);

void bar(void) { for(int i=5; i < 10; i++) foo('G'); } ===========================

Что мешает компилятору поручится в незавуисимости результата от параметра цикла? Здесь результат выполнения bar() зависит только от количества проходов цикла. Вот какой код генерит gcc3:

======== test.s =========== .file "test.c" .text .p2align 2,,3 .globl bar .type bar, @function bar: pushl %ebp movl %esp, %ebp pushl %ebx movl $4, %ebx pushl %eax .p2align 2,,3 .L5: subl $12, %esp pushl $71 call foo addl $16, %esp decl %ebx jns .L5 movl -4(%ebp), %ebx leave ret .size bar, .-bar .ident "GCC: (GNU) 3.4.2 [FreeBSD] 20040728" ===========================

Смотреть здесь на регистр ebx.

Для сравнения вот второй пример:

======== test.c ======== void foo(int);

void bar(void) { int i=5; while(i--) foo('G'); } ========================

Вот результат его компиляции:

======== test.s ========= .file "test.c" .text .p2align 2,,3 .globl bar .type bar, @function bar: pushl %ebp movl %esp, %ebp pushl %ebx movl $4, %ebx pushl %eax .p2align 2,,3 .L4: subl $12, %esp pushl $71 decl %ebx call foo addl $16, %esp cmpl $-1, %ebx jne .L4 movl -4(%ebp), %ebx leave ret .size bar, .-bar .ident "GCC: (GNU) 3.4.2 [FreeBSD] 20040728" =========================

Как говорится, найдите 10 отличий. Чтобы было легче найти, вот дифф:

========= test.s.diff ==========

-+- test.s.old Wed Jun 7 15:32:28 2006

-.L5:

• decl %ebx call foo addl , %esp

- decl %ebx

- jns .L5

• cmpl $-1, %ebx
• jne .L4 movl -4(%ebp), %ebx leave ret ================================

Мне тут прокомментировать нечего.

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

Привет!

Wed Jun 07 2006 15:31, Alex Kocharin wrote to Yuriy K:

AM>>> if(counter_started && ++counter == MAX_COUNTER) AM>>> do_smthng(); YK>> За подобные финты немедленно увольнять с формулировкой YK>> "служебное несоответсвие". AK> А что, красивый код. :-)

;-)

AK> А работодатель зачастую вообще не понимает кода... Так что AK> не уволят. :-)

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

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

Юргис

Привет!

Wed Jun 07 2006 14:09, Igor Havtorin wrote to Jurgis Armanavichius:

JA>> Hе скажи. А эти постоянные заботы о внимательном отношении в стеку, JA>> к передаваемым параметрам, расположению локальных переменных? Тут JA>> однозначно ЯВУ лучше. По той причине, что хотя бы об этих вопросах JA>> думать не надо :-) IH> Был у меня один проект на асме лет пять назад на PIC16C711, так вот IH> там ОЗУ приходилось по байтам считать - под "локальные" переменные IH> оставалось пять или шесть байт и приходилось в каждой подпрограмме IH> (предварительно составив дерево вызовов) использовать свободные в IH> данном месте байты (помню даже макрос по распределению/освобождению IH> написал). А С-шный компилятор/линкер делает то же самое легко и IH> непринужденно в автоматическом режиме.

Вот именно! А освобождение программиста от забот о всякой рутинной фигне позволяет сосредоточить больше внимания на творческом аспекте своей деятельности :-) В общем, ЯВУ - рулез!

Юргис

Hello, Jurgis!

GS>> Ты с PIC12/16 попробуй поработать...

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

Да откуда ему знать? Он Си не знает. Прекрасный Хайтечевский Си для пиков, программировать что пик12 что пик16 кроме как в исключительных случаях - на чистом асме - жорин мазохизм.

With best regards, Alexandr Torres. E-mail: snipped-for-privacy@yahoo.com

Hello, Jurgis! You wrote to Dmitry Orlov on Wed, 07 Jun 2006 08:59:49 +0400:

JA> Wed Jun 07 2006 09:44, Dmitry Orlov wrote to Jurgis Armanavichius:

JA>>> Слава Богу, в последнее время сказанное тобой становится все менее и JA>>> менее важно. Кристаллы улучшаются, дешевеют, средства проектирования JA>>> софта для них тоже улучшаются. Это называется "прогресс" :-) Если же JA>>> в этот процесс не вписываются пики - да плюнь ты на них! Я много лет JA>>> без них обходился и ничего, нормально :-) DO>> В прогресс не вписывается Жора, а не PIC'и. Те как раз вполне DO>> вписываются.

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

Что будетв будущем - посморим, а пока что Микрочип около десяти лет занимает второе место в мире (после Моторолы) по выпуску 8-битных микроконтроллеров....

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

Нашел кому верить...

With best regards, Alexandr Torres. E-mail: snipped-for-privacy@yahoo.com