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

Аналогия switch case в Си всего то...

Так и обходите молчанием, что же может (даже не произойдёт), а только может произойти? Биты на байты налезут, или стек через своп в астрал улетит? Если логика продумана, то будет работать железно хоть так хоть этак. На то оно, как там его, железная логика)) Или имеете в виду возможное внесение косяков при изменении программы?
Что будет-то на железном уровне? Просто "харам" - это не доказательство. Или это не для начинающих.

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

Проблема в том, что в спагетти-коде невозможно "продумать логику" так, чтобы она была действительно продумана.
Разве только для самых примитивных задач.
Чем более упорядочен код, тем проще с ним работать сейчас и вообще возможно работать в некоем не слишком далеком будущем.
Иначе смотришь на свой код как баран на новые ворота и не понимаешь зачем ты сделал странные действия...

У нас исходно сделать выбор в случае с текущим значением бита...
Можно по командам проверки состояния бита, а можно и по условному переходу, представив бит в адрес вектора перехода (табличный селектор).
То уж как интересно будет.
Да и на BTFSS/BTFSC переключатель соорудить можно только по каждой команде свое условие делается, а не два условия с одной команды.

Ну это только если проццессор слабоват, или ОЗУ недостаточно))

Это да, полностью согласен. Но комментарии спасают.

А вот скажите пож-ста, я, конечно, знаю, что объявление переменных и регистров следует делать в начале листинга. Для удобочитаемости. Но ведь гораздо удобнее (пусть не всегда, временами) делать это в части, относящейся к какой-то процедуре, прямо перед ней. Неудобно мотаться далеко в начало, или в другое окно переключаться. Два монитора бы спасли, это лучший вариант.

К Вашему примеру селектора:

Спойлер

Код:

; саму проверку вызываем как CALL TEST ибо надо фиксировать точку возврата
; к исходной программе (а она таки одна)
CALL TEST

TEST
BTFSS R0,N ; проверка на 1
BTFSC R0,N; если не 1 то проверяем на 0
goto point_a ; безусловный переход на точку
                   ; вызова подпрограммы при бите = 1
point_b ; точка вызова подпрограммы при бите = 0
       ;ТЕЛО ПРОГРАММЫ ДЛЯ БИТА РАВНОГО 0
       ;................................
ret ; или reti

point_a ; точка вызова подпрограммы при бите = 1
       ;ТЕЛО ПРОГРАММЫ ДЛЯ БИТА РАВНОГО 1
        ;................................
ret ; или reti

Надеюсь понятно, почему там CALL за btfss/btfsc не слишком корректна...

Увы нет. То есть совсем нет. Невозможно описать головоломную конструкцию, где заплатка погоняет заплаткой. У вас не хватит словарного запаса. У языка нет такого словарного запаса.


Все давно придумано в MPLABX. Там есть возможность открыть два экземпляра одного листинга в одной среде. Справа в верхнем углу листинга есть крестик. Потяните за него влево. Дверка с золотым ключиком откроется...

Если метка относится только к некоторому участку кода и нигде более не используется - проблем особо нет. Это объявление локальной метки действующей в ограниченной области кода. Тут главное не сделать повторного объявления ранее уже определенного регистра или данных.
Другое дело, когда определенная где-то в одном месте метка в дальнейшем будет использоваться в других частях программы.
Ежли "ниже по коду" это вполне возможно (хош и путаница в поиске первоисточника самой метки будет еще хуже, чем просмотр единого файла заголовка с определением меток).
А вот ежли "выше по коду" - тогда придется изворачиваться с #define и опять таки со списком определений в отдельном разделе (файле) в начале программы.
Да и никто не ограничивает возможность вставлять в начале текста программы проекта подключаемые файлы, к примеру:

а уже в них укладывать все объявления.
Такой вариант легко просматривается/обрабатывается в любом текстовом редакторе с несколькими одновременно открытыми файлами даже на одном мониторе.

Не подскажете идею, как определить старший единичный бит в байте? btfss-ами долго и муторно получается.

Что значит определить?
Перейти по условию? Тогда это btfss.
И что такое"долго и муторно"?
Опять же все зависит от семейства МК. В 18-х и 24-х есть иные варианты.

Почему долго?
Одного btfss (или btfsc -зависит от логики задачи) вполне достаточно.
Другое дело если тот бит контролируется в комплекте с остальным содержимым регистра или с дополнительными параметрами.
Альтернатива - сдвиг RLF Rx,w с последующей проверкой флага C регистра status.
Или хочется классическую инверсию бита в зависимости от его исходного состояния с помощью связки из тех btfss/btfsc замутить?
Чтой-то у Вас "творческий спад" наблюдается...
Не захворали ли часом?

А был ли подъем?

Вам тоже надо как процессору объяснять))


Определить позицию старшего единичного бита в байте, для вычисления его веса (^2), 128 64 ... 2 1, 16f648.

Начинаем со старшего, и в худшем случае пока до младшего дойдёшь, 8 циклов. Наоборот смысла нет. Да ещё и восемь раз повторять эти btfss с изменяющимся номером бита. В смысле, в цикл затруднительно засунуть, в связи со сложностью динамической смены номера бита, команд получится много.

Спасибо, я до этого тоже уже додумался, но те же 8 циклов

А больше, похоже, никак, в один присест не получится. Хотя, если учесть последующие действия, может чего и придумается. Это для того, чтобы из То есть в этом случае 64-> PS[2:0]=101


И это мне ещё повезло, что остальные биты OPTION всегда нулевые будут, и можно просто писать

Наверное нужно сначала думать, а лишь потом формулировать вопрос.
Определить старший единичный байт и определить позицию старшего единичного байта - это две большие разницы.
Однако да, подобные задачи не компактны, поэтому в системе команд PIC24/dsPIC есть специальные инструкции FF1L/FF1R позволяющие вернуть позицию первого единичного бита слева или справа. Причем за один машинный цикл.
Так же есть инструкция определяющая позицию первого слева ИЗМЕНИВШЕГОСЯ бита - FBCL. Для положительных значений это будет первая слева 1 после 0, а для отрицательных - первый слева ноль после 1. И тоже за один машинный цикл.

AND по маске это понятно, а вот первые две команды как приложить - ума не приложу.

Вопрос исходно совсем некорректно задан был!

Для такого простейшего определения или функция препроцессора (есть в ассемблерах у атмела для авр/mcs51) или программный табличный обработчик - у ПИКовых для такого есть RETLW (табличное преобразование)

yor, Rx - это регистр, куда загружено исходное значение 001xxxxx