Вопросы начинающих PIC ASM

[BOB51]

А с какого бодуна подпрограмма следует сразу же за вызовом???
И тем более с вызовом call при последующих двух (вероятно условных) возвратах по goto (без "гашения" стека).
Там вполне ветвления по условию достаточно с оформлением в макрос.
Помимо прочего вопрос по инициализации, тем "темным лошадкам". что в виде прочерков и содержимому pclath (его "неприкосновенности").
Фокусы со стеком требуют внимательного рассмотрения ВСЕЙ программы, а не только отдельно взятого фрагмента.
Вот той части и не предоставлено.

Можно использовать и retlw n при последующем анализе содержимого W в точке возврата и безусловном переходе или по goto (с индексированием по текущему pcl или непосредственной загрузкой pcl=0).
Однако такой вариант значительно более громоздкий, чем простой макрос может получиться
поскольку помимо call proc потребуется добавить несколько команд анализатора возврата в каждом месте применения вызова call proc

[КРАМ]

Нет там никаких проблем со старшим адресом РС, патамушта такого рода выкрутасы делают только при очень коротком и примитивном коде. Вопрос был синтетический. Поэтому иные решения без вызовов не имеют смысла.
Анализ аккумулятора после возврата займет ровно ДВЕ инструкции. Собственно выход с аккумулятором для этого и создан. Вернуть значение вычисляемой функции. Кейс связанный с этим значением - частный случай.

[BOB51]

Ну уж не только при примитиве - 8 разрядный стек практически у всех "среднемладших" - а там можно и с достаточно сложными задачами столкнуться.
Тем более, что в прикладных ситуациях три младших бита pcl весьма подпакостить могут при операциях с pcl в качестве результата (вычисляемый переход).

[КРАМ]

Ответ как раз и состоял в локальной применимости подобного решения. В более сложных задачах переполнять стек не выйдет.

[BOB51]

МНДЯаа....
Не зря таки я те "шпоргалки" с перечнем всех имеющихся команд рисовал...
Позволяют таки весьма быстро вспомнить после длительного отсутствия практики...
Да сориентироваться чего удобнее из имеющегося арсенала применить.

[КРАМ]

Дело не в шпаргалках.
Следует понимать для чего в системе команд присутствует та или иная инструкция, ане применять их рандомно и по наитию.

Добавлено after 3 hours 10 minutes 34 seconds:
[uquote="yor",url="/forum/viewtopic.php?p=3581229#p3581229"]Подскажите, пож-ста[/uquote]

Код: Выделить всё

Init:
--
Start: call Delay
--
call TrueFalse
addlw  0
btfsc   STATUS, Z
goto   Start
--
TrueFalse:
--
retlw  0
--
retlw  0
--
retlw  1
Delay:
--
return

[yor]

[uquote="КРАМ",url="/forum/viewtopic.php?p=3581369#p3581369"]Для искомого Вами двойного выхода из функции есть команда retlw <const>, с помощью которой, НЕ РАЗРУШАЯ СТЕК, можно спокойно ветвить исполнение ПОСЛЕ ШТАТНОГО ВЫХОДА из функции.[/uquote]
То есть, если я правильно понял, выходим по retlw <const> на адрес за вызовом, потом по W анализируем причину и уходим в соотв. место? Двойная работа, сначала анализировать рабочие состояния, а потом куда идти. Более удачно было бы даже просто уходить по RETURN с естественным образом, в процессе работы загруженным W. Как справедливо замечено, код простой и короткий.

Ответ как раз и состоял в локальной применимости подобного решения. В более сложных задачах переполнять стек не выйдет.

Мне думается, что так можно делать в любой сложности задачах, если избегать этого во вложенных вызовах, разве нет?

Ну да, изящно, спасибо, не так уж и сложно выглядит. Но мой способ экономит 3 команды

[BOB51]

Но нам то сами условия, задаваемые в исходной задаче неизвестны...
Так же как и способы получения "выхода по ....."условию"" в результате которого yor
упирается в досрочный goto start.
Наверняка в исходной задаче можно гораздо более оптимальный алгоритм применить.
А относительно именно "голого примитива" для пробы - при корректной начальной инициализации проброс адресов стека практически роли не играет.
Аналогия - сброс МК по аварийной ситуации (все виды сброса кроме начальной подачи питания).
Но то уже разговор не о переполнении стека, а о грамотной реинициализации программы (soft reset).
Тема достаточно серьезная и самый большой источник сбоев МК у начинающих авторов.

[КРАМ]

[uquote="yor",url="/forum/viewtopic.php?p=3581539#p3581539"]Но мой способ экономит 3 команды [/uquote]
Ваш способ ничего не экономит.
Это полный бред - экономить путем написания кривого кода, чтобы потом все переписывать заново.
Я уже не говорю о том, что экономия трех строк в невыровненном по исполнению коде В КОРОТКОЙ ВЕТКЕ является глупым и никчемным мероприятием.
Возьмите более дешевый и более быстрый МК, например 12F1571 и запустите его на 8 мипсах.
Что за задачу Вы решаете такую?

Добавлено after 36 minutes 25 seconds:
[uquote="yor",url="/forum/viewtopic.php?p=3581539#p3581539"]Мне думается, что так можно делать в любой сложности задачах, если избегать этого во вложенных вызовах, разве нет?[/uquote]
Код пишут для решения задач, а не для выкрутасов.

[yor]

Ну с высоты профессионализма Вы можете, конечно, смотреть свысока Как это не экономит, если отвлечься от культуры программирования, или как там его? Ровно 3 команды, а если таких мест больше, то умножай на три. И потеря возможности передать значение в W при выходе из ПП. Это выльется ещё в лишние команды и регистры, потерю быстродействия. Не то чтобы это мне прямо сейчас надо, укладываюь с большим запасом, но может и пригодиться. Я не призываю к такому, как Вы считаете, беспределу Я выборочный перфекционист, и стремлюсь к своему идеалу лишь ради любви к искусству Но разобраться не повредит.

Экстенсивный метод - не наш путь Дешёвый это можно, а быстрый мне ни к чему. Задача так себе, ничего особенного, неспешная обработка медленно и беспорядочно изменяющегося напряжения с температурного датчика с влиянием на цепь того же датчика (шунтирование, обратная связь, кольцо). Практической пользы ноль, подбираюсь к более сложным задачам. Так как я не профи, как многие справедливо заметили, то иду от простого к сложному. Постепенно усложняя, дополняя и т.д. Практически линейная программа, с парой-тройкой подпрограмм. Первая версия была около 400 байт, сейчас уже шестая - около 700. Мастерство растёт, медленно и неуклонно

Можете слегка просветить насчёт "в невыровненном по исполнению коде В КОРОТКОЙ ВЕТКЕ"? Когда-то в далёкой юности, во времена MS-DOS я мучал ассемблер интеловских процессоров, там выравнивание имеет место быть, а тут?

[uquote="КРАМ",url="/forum/viewtopic.php?p=3581640#p3581640"]Код пишут для решения задач, а не для выкрутасов.[/uquote]Ну на название темы-то посмотрите, мы ж не на семинаре

[КРАМ]

[uquote="yor",url="/forum/viewtopic.php?p=3581717#p3581717"]Я выборочный перфекционист, и стремлюсь к своему идеалу[/uquote]
Только вот придете Вы к нелепому и смешному результату.
Вы даже начали совершенно с конца.
Сначала нужно выстроить АЛГОРИТМ, а лишь потом писать код. Вы же вообще никакого алгоритма не придумали. Пишите как Бог на душу положит всякие глупости и полагаете себя перфекционистом.
Еще раз предлагаю озвучить свою КОНЕЧНУЮ задачу. Тогда и поговорим о "выборочности" Ваше го перфекционизма...
Изощренность в устройстве короткого замыкания в бытовой сети не свидетельствует об уме его устроителя. Изощренная глупость глупостью и остается...

Добавлено after 4 minutes 44 seconds:
[uquote="yor",url="/forum/viewtopic.php?p=3581717#p3581717"]Можете слегка просветить насчёт "в невыровненном по исполнению коде В КОРОТКОЙ ВЕТКЕ"?[/uquote]
Все очень просто. Выход по goto из вызова находится в короткой ветке исполнения по сравнению со штатным выходом. Нет никакого прока там что либо экономить.
И в догон. Возврат значения функций через аккумулятор делать совершенно беспонтово. Функция может возвращать значения разной разрядности. Худший метод написания программы - хаотичность соглашений. Гарантирую полный тупик уже при паре сотен строк кода.

[yor]

Ну как же без алгоритма, он есть у меня Вот даже про поиски программы для его отладки, может чего подскажете и по этой теме? Вы как алгоритм составляете, на бумажке или? Или это делают специально обученные люди? А я-то один за всех отдуваюсь
https://unixforum.org/viewtopic.php?f=122&t=146260

Задачу я не готов обнародовать, ещё бабушка надвое сказала, да и смеяться будете

Выход по goto из вызова находится в короткой ветке исполнения по сравнению со штатным выходом. Нет никакого прока там что либо экономить.

Непонятно почему. В контексте всей программы байт килобайт бережёт Когда прижмёт, можно купить более мощный контроллер - это экстенсивный путь,, а можно оптимизировать программу - интенсивный.

[BOB51]

[uquote="КРАМ",url="/forum/viewtopic.php?p=3581640#p3581640"]...
Возьмите более дешевый и более быстрый МК, например 12F1571 и запустите его на 8 мипсах....[/uquote]
ОЙ!!!

Только не надо "энхансед" с четырьмя цифирьками предлагать тому, кто с классической "среднемладшей"
только разбираться начинает!

Это ж гибрид с 18-й по устройству ядра...(и стека в том числе!).
Да и набор команд там значительно отличается.
Таким можно и кого поподготовленнее "добить"...


Кстати...
yor я ведь также "на листочке с карандашиком" алгоритмы составляю - и никаких особых вопросов.
Помимо прочего - МК (в том числе и наиболее приемлемого для конкретных условий семейства) подбирается под задачу.
Благо есть из чего выбирать. Но то вопрос для другой темы.

[КРАМ]

[uquote="BOB51",url="/forum/viewtopic.php?p=3581857#p3581857"]Это ж гибрид[/uquote]
Какой еще гибрид?
Обычный 12-ый пик с некоторыми дополнительными возможностями НИКАК НЕ ВЛИЯЮЩИМИ на реализацию алгоритма.
А даже облегчающие работу на АСМе.
Есть доступ к гладкому адресному пространству при косвенной адресации. Есть автоматическое сохранение контекста. Есть переключение банков через BSR. Есть пяток команд облегчающих обработку массивов и еще пяток разномастной арифметики. Собственно и все, если говорить о ядре.
Почему нужно сводить кодинг к фокусам с системой команд? Есть совершенно определенные АЛГОРИТМИЧЕСКИЕ методы решения задач. Система команд ЗАТОЧЕНА под эти методы. Практически во всех платформах. И не следует изобретать велосипеды с квадратными колесами. Круглые едут гораздо надежнее и плавнее.

Добавлено after 5 minutes 27 seconds:
[uquote="yor",url="/forum/viewtopic.php?p=3581852#p3581852"]смеяться будете[/uquote]
Смеюсь я над Вашими уже озвученными глупостями.
Если человек приходит с ВОПРОСОМ - это не может быть смешно. Смешно, когда человек приходит с глупым ОТВЕТОМ.
Не стесняйтесь, озвучьте задачу. Практически 100%, что она имеет гармоничное решение, а не уродские игры со стеком.
Кстати, это в примитивных МК подобное издевательство со стеком проходит невозбранно. На 16-разрядной платформе Микрочипа программа улетит на трап ошибки стека. И там придется разгребать глупое решение.

Добавлено after 3 minutes 51 second:
[uquote="yor",url="/forum/viewtopic.php?p=3581852#p3581852"]Вы как алгоритм составляете, на бумажке или? Или это делают специально обученные люди?[/uquote]
Конечно сам. Работа с МК не предусматривает иерархию программирования для универсальных компьютеров. Даже разделение кодинга и схемотехники обычно плачевно для результата.
Алгоритм пишу в произвольной форме. Иногда в классической блок-схеме. Иногда в метакодах. Непринципиально.

Добавлено after 3 minutes 41 second:
[uquote="yor",url="/forum/viewtopic.php?p=3581852#p3581852"]В контексте всей программы байт килобайт бережёт[/uquote]
Какой, к ядрене фене, килобайт? Вы в своем уме? Я работаю с МК с 1991 года. Не было НИ ОДНОГО СЛУЧАЯ, чтобы мне не хватило флеша при написании на АСМе.
Может не хватать скорости. Но работа против правил лишь усугубит проблему и сделает ее неразрешимой в принципе.

[yor]

[uquote="BOB51",url="/forum/viewtopic.php?p=3581857#p3581857"]не надо "энхансед" с четырьмя цифирьками предлагать тому, кто с классической "среднемладшей" только разбираться начинает![/uquote]
Да ладно, этот срднемладший конкретно напрягает отсутствием CMP и ещё чего-то там.

На 16-разрядной платформе Микрочипа программа улетит на трап ошибки стека. И там придется разгребать глупое решение.

Там применим решение поумнее.

Какой, к ядрене фене, килобайт?

Вот с чем с чем, а с юмором у Вас затруднение Говорят, сразу видно программиста

Но работа против правил лишь усугубит проблему и сделает ее неразрешимой в принципе.

Я бы не стал так усугублять, всегда можно начать с нуля, или сделать поправку на нарушение правил. НЕт, я, конечно, за, когда всё по уму, но то чего-то не знаешь, что-то кажется излишним, мне же не выставлять программу на олимпиаду

[BOB51]

Ну уж так и не "гибрид"!

Аккумулятор как регистр в адресном пространстве (причем отображается в спецблоке в каждом регистровом банке);
Автоматическое сохранение контекста при прерывании (правда второй уровень не добавили);
Структура стека (и его размер);
Способы адресации "коротких векторов" весьма удачно расширенны (Callw)....
а BRW и BRA выполняются без участия pclath;
Косвенная адресация с автодекрементом/автоинкрементом (как пред так и пост)
что позволяет вести речь о пересылках регистр-регистр как в однократном режиме, так и массив-массив;
Расширены вращение и сдвиг;
Программный reset (по функционалу аналогия активации внешнего вывода сброса при аварийном сбое);
Насчет линейного адресного пространства "с дырками" - это надо соответствующей задачей проверять...
Это несколько иной "способ разметки" нежли в типовых среднемладших, как с ним удобнее обращаться - надо весьма помудрить.
Так что по части добавок таки "гибрид" и весьма неплохой.


yor
среднемладшие имеют все необходимое для сравнения/тестирования данных.
Другой вопрос - это все-таки РИСК система команд - для чего аналогичного CMP надо одну- три команды применить.

[КРАМ]

[uquote="BOB51",url="/forum/viewtopic.php?p=3581967#p3581967"]что позволяет вести речь о пересылках регистр-регистр[/uquote]
Не позволяет. Только через аккумулятор.
В целом, архитектура ядра 18-х мало чем отличается от архитектуры 12-16-х.

Добавлено after 2 minutes 46 seconds:
[uquote="yor",url="/forum/viewtopic.php?p=3581955#p3581955"]с юмором у Вас затруднение[/uquote]
Сначала научитесь шутить. Ваши "шутки" основаны на примитивных глупостях. Впрочем, это нынче мейнстрим - ржать над тупым кривлянием.
Да и не программист я. Моё профессиё - радиоинженер...

[BOB51]

Ладушки... обшибся - через аккумулятор...

Ежли учесть, что ближним ПИКом занимался пол года тому... а вспоминашку делаемс с 15 часов по "быстрой памяти" да наскоро (между сладкой дремой)
ШКЛЕРОЗЬ ешшо не полностью одолел!

[otest]

Пол года это не срок. Надо менять память.

[КРАМ]

[uquote="otest",url="/forum/viewtopic.php?p=3582051#p3582051"]менять память.[/uquote]
На DDR5?


К теме.
Современные 8-битные ПИКи - это по сути не МК, а интеллектуальная периферия. Задача ядра в которых лишь в перенастройке оной периферии и некоторых несложных вычислениях для этого. Скажем, тот самый 12F1572 - это чип для RGB светодиода с управлением по UART. Естественно, что с дополнительными возможностями.
Основа - три независимых PWM модуля с возможностью их взаимной синхронизации.

[uquote="BOB51",url="/forum/viewtopic.php?p=3581967#p3581967"]Насчет линейного адресного пространства "с дырками" - это надо соответствующей задачей проверять...
Это несколько иной "способ разметки" нежли в типовых среднемладших, как с ним удобнее обращаться - надо весьма помудрить.[/uquote]
Не надо ничего мудрить. Начиная с адреса 0x2000, следует линейное адресное пространство ОЗУ общего назначения, за исключением расшаренной во все банки области.
Назначение сей приблуды - упростить размещение массивов. Доступ только косвенный. Но массивы и не требуют непосредственной адресации.
Начиная с адреса 0x8000, следует доступ к младшему байту флеша как к ОЗУ.