при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
Не хотел ввязываться в этот бессмысленный флейм, но такие перлы, достойные второкурсника-двоечника, не позволяют промолчать.Когда мы работаем на языке высокого уровня - о каком ОЗУ может идти речь? Компилятор сам определяет, где ему хранить значения - в ОЗУ или регистрах. Раз уж этот флейм пошел в теме забытого за ненадобностью ТС о микроконтроллерах, то как быть с теми МК, у которых ОЗУ вообще нет?COKPOWEHEU писал(а): В глобальную переменную или по переданному адресу процедура не возвращает значения, а напрямую работает с ОЗУ. Эта область в процессе работы процедуры может быть изменена несколько раз и даже использована во время работы процедуры.
Куда-куда ? В код ?! Ну тут уж слов нет.возвращенное функцией значение именно передается в вызывающий код.
в том-то и дело, что для предложенного мною обсуждения вообще не надо лезть в отладчик, вообще не надо думать о том, как ведет себя компилятор! мы обсуждаем терминологию и классификацию, т.е. вещи, доступные программисту (а не компилятору). а программист, работающий с языками высокого уровня, должен быть максимально абстрагирован от аппаратных и платформозависимых компиляторов - он должен (в идеале, конечно!) видеть только текст программы и работать с ним.Jack_A писал(а):Если посвятить хотя бы половину времени, потраченного на ... прокрутку в отладчике тестового примера
сегодня не позволяет, завтра позволит - что изменится в жизни программиста? он как писал x = y + 1; так и будет писать, и принципиально ему должно быть все равно, где находятся x, y и откуда именно берется 1 - единственное, что его должно волновать, так это чтобы результат был именно тот, который ожидается при данной записи.Jack_A писал(а):Если архитектура фон Неймана, можно себе представить передачу данных именно в область кода, хотя это чересчур уж по-хакерски, и ни один компилятор такую мудотень не позволяет.
именно! если существует термин, понятный всем, то можно быть уверенным, что все пойму правильно этот термин. для математика функция, которая не возвращает результат - это абсурд. или результат, который функция возвращает, не может быть никак (в принципе никак!) использован - это тоже абсурд...Jack_A писал(а):Только при публикации будут проблемы с пониманием
вот именно, в конкретной реализации конкретного языка. а почему вообще допускается, что могут быть и иные варианты? потому что нет стопроцентно четкого непротиворечивого определения тех самых FunXXX и SubXXX, и остается лазейка для использования всяких вариаций "а так тоже можно".Jack_A писал(а):Если имеется туман в понимании некоторых вещей, то не зазорно и отладчиком пройтись, чтобы убедиться, что в конкретной реализации языка "при выполнении x = FunXXX (...) и SubXXX (...,&x,...)" будет одинаковый результат.
... или перенесет в отдельную ветку, бо рациональные зерна тут проскакивают, но к заявленной ТС-ом теме - никаким боком.Z_h_e писал(а): Интересно, как скоро придет лесник модератор и всех партизан разгонит за оффтоп???
Не реализован != не используется.если считать интерфейсом, как настаивал я, только видимую программисту часть в исходном коде, то, согласно вашим определениям
void func(void) - это процедура, т.к. никакого интерфейса передачи внутрь нет, и нет ничего для выдачи наружу.
Ага, на все протяжении споры вы пытаетесь приписать мне свои домыслы.и так на всем протяжении спора
А чем вам регистры не ОЗУ? Впрочем, согласен, сформулировал я неудачно. Но не знаю как это сделать лучше.Когда мы работаем на языке высокого уровня - о каком ОЗУ может идти речь? Компилятор сам определяет, где ему хранить значения - в ОЗУ или регистрах. Раз уж этот флейм пошел в теме забытого за ненадобностью ТС о микроконтроллерах, то как быть с теми МК, у которых ОЗУ вообще нет?
Верно. Во втором случае значение окажется во вполне конкретном месте ОЗУ, причем независимо от реализации, а в первом - оно может быть получено вызывающим кодом - через регистры, ОЗУ или стек, в зависимости от реализации, и уже этим вызывающим кодом присвоено переменной х. Что там натворит оптимизатор - одному ему ведомо.начит, при выполнении x = FunXXX (...) и SubXXX (...,&x,...) вычисленное значение окажется в разных местах - во втором случае - в ОЗУ, в первом - "в возвращаемом коде" ?
Сомневаюсь что кому-то из присутствующих придется писать публикации по таким философским дебрям.Только при публикации будут проблемы с пониманием
Заявленная ТС'ом тема исчерпана на первой же странице. Скорее всего, он использовал встроенный RC-генератор вместо внешнего кварцевого резонатора. Это не упоминая мелких правок по оформлению и оптимизации. Что еще тут можно обсуждать без участия самого ТСа?или перенесет в отдельную ветку, бо рациональные зерна тут проскакивают, но к заявленной ТС-ом теме - никаким боком.
Просто не могу не ответить на такую провокационную фразу:Ни к кому сейчас лично не обращался, обязательного возврата ответа не требуется.
Код: Выделить всё
return;COKPOWEHEU писал(а):[Верно. Во втором случае значение окажется во вполне конкретном месте ОЗУ, причем независимо от реализации, а в первом - оно может быть получено вызывающим кодом - через регистры, ОЗУ или стек, в зависимости от реализации, и уже этим вызывающим кодом присвоено переменной х.начит, при выполнении x = FunXXX (...) и SubXXX (...,&x,...) вычисленное значение окажется в разных местах - во втором случае - в ОЗУ, в первом - "в возвращаемом коде" ?
Ни в коем разе, для меня это процесс индивидуальный сиречь - непубличныйCOKPOWEHEU писал(а): P.S. А что, тоже захотелось поучаствовать в сраче?
а если приводит источники - тогда как?Jack_A писал(а):если кто-то утверждает, что А и В - разные сущности, но источников информации не приводит, а утверждающие противоположное - отвергает, то это и есть sratch, т.е. выдавание своего мнения за истину.
Код: Выделить всё
;Подпрограмма, преобразующая упакованный BCD-формат в формат binary
;На входе в R18 число в упакованном BCD-формате
;На выходе в R18 число в формате binary
BCD2BIN:
push R1 ;Сохранить на стеке
push R0 ;используемые
push R17 ;регистры
push R16 ;
mov R17,R18 ;Скопировать преобразуемое число в рег.R17
swap R17 ;Обмен нибблов местами - теперь разряд десятков в младшем полубайте,
;а разряд единиц - в старшем
andi R17,0x0F ;Маскировать разряд единиц
ldi R16,0x0A ;
rcall MUL8x8U ;Умножить разряд десятков на 10
andi R18,0x0F ;Маскировать разряд десятков в преобразуемом числе
add R18,R0 ;Сложить умноженный на 10 разряд десятков с разрядом единиц, теперь
;в рег.R18 число, преобразованное в формат binary
pop R16 ;Восстановить
pop R17 ;из стека
pop R0 ;использованные
pop R1 ;регистры
ret ;
Уже неполезна. Кажется, наиболее активным "гладиаторам" (мне и ARV) наскучило.Почитал я эту тему... Знаете, она полезна тем, что позволяет попрактиковаться в эристике.
Я бы не был столь категоричен. Эти алгоитмические единицы существуют во множестве языков, так что привязывать из к какому-то конкретному неправильно. Тем более что ARV утверждал, что крайне мало языков (я вот вообще ни одного припомнить не могу) реализуют их правильно, везде какие-то отклонения от теории.Лично мне кажется, что рассуждать на тему подпрограмм, процедур и функций в отрыве от языка и платформы вообще бессмысленно.
Подобный пример я уже приводил. Поскольку в ассемблере нет ничего более высокоуровневого, чем подпрограмма - это она и есть. При использовании внешним ЯВУ (хотя бы Си) это можно считать... эмулятором функции что ли... не могу с ходу подобрать подходящий термин. Дело в том, что передача значений реализована вручную, то есть с одной версией компилятора она будет работать нормально, а с другой - нет.Вот, к примеру, скажите, что спрятано под спойлером - подпрограмма, процедура или функция?