Да, патамушта директива banksel тупо генерирует одну или две строки (зависит от МК) с соответствующей аргументу директивы установкой банка.

Ну ведь может же? Как я понял, она смотрит, в каком банке переменная, и соответственно устанавливает биты выбора банка.

Так почему бы не сделать глобальный подстанов по всему листингу? Проверку при любом обращении к переменным и установку битов выбора банка?

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

Просто нужно тщательно планировать размещение данных и ресурсов в ОЗУ.
Тогда и переключений банков будет заметно меньше.

А компилятор об этом может знать?

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

Нет, не может. Потому что Ассемблер по сути компилятором в полном смысле не является.
Впрочем, и в Си невозможно анализировать рантайм.

Добавлено after 1 minute 57 seconds:

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

То есть ассtмблер, видя, например, var1, не может понять, что это - или регистр в ОЗУ или вообще левая переменная? А по контексту:

Разве непонятно?
Или портят дело усугубляющие случаи, непрямая адресация, индексное приращение или как там его?

Вы вообще понимаете о чем я вам пишу?
Еще раз.
Нет никакого смысла в автоматическом добавлении banksel, ибо это тупой оверхед.
В подавляющем количестве случаев обращение к ОЗУ делается так, чтобы не нужно было переключать регистры. То есть работают с одним банком. А потом в другом месте кода один раз переключают и работают уже с другим. А разбирать код, предсказывая его работу, Ассемблер не умеет. Линейный код - это частный случай. Чаще всего код ветвится и необходимость banksel является условной.
И вообще, если вам хочется забыть про банки, пишите на С.

а если ты например, видишь movlw 0x05 ... то что это? адрес, константа?
ассtмблер не должен что-то там "видеть", да ещё и домысливать/корректировать/добавлять, упаси его ... было бы довольно странно, если некая автоматика вмешивалась в это ... в том то и смысл асма - тупо заменять написанное (в простых к запоминанию нам словах) на соответствующие числовое представление.

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

movlw 0x05
будет однозначно определяться как загрузка константы 0x05 в регистр w
Что дальше с теми данными будет делаться для этой операции безразлично.
Другое дело операции, где подразумевается загрузка регистра ОЗУ/РСФ - там значение проверяется согласно информации из служебных файлов в составе проекта (для мпасма в мплабе).

Это мы в этом видим ту или иную однозначность а по факту эту запись тупо превратят в соответствующий опкод и поместят по соответствующему адресу, и всего то

А могли бы проявить чуть побольше чуткости и предсказательности))

Добавлено after 1 hour 26 minutes 56 seconds:
Есть способ из W вычесть число, в частности единицу? В 648 decf W не работает. И даже регистр из W не вычесть, только наоборот. Вот так аккумулято...
От 8 цикл до нуля, чтобы лишний вспомогательный регистр не заводить.

делай так:
addlw 0xFF
это незадокументированная специнструкция

При обработке мпасмом используется еще и линкер и два файла описания ресурсов *.inc и *_g.lkr - вот там все базовые параметры для вармингов и отработки ошибок искать надо (* - имя соответствующего МК).
Ежли по *.inc все достаточно понятно, то по*_g.lkr желательно у КРАМ данные поспрошать... Я ими только пользуюсь в том виде, что в IDE задан...

Насчет вычитания и работ с W у стандартных среднемладших таки малость не так, как у других (то же касается и флага С при вычитании) - но ЭТО ПИКи...

И никто не запрещает:
inc W -- addlw .1
dec w -- addlw 0xff
setb W.n -- iorlw 1<<n
clr W.n -- andlw 0xff-(0xff&(1<<n))

Старая шпора для "быстрых воспоминаний":

Инкремент-то понятно, и биты, а вот вычитание - прямо магия!
addlw 0xff на флаг Z как надо подействует? То есть при нуле он 1? Ну и для общего развития, что с флагами С && DC? Через С вычитает?

https://web.archive.org/web/20080221231 ... /mpasm.pdf
https://web.archive.org/web/20080221231 ... C16_29.pdf

Так из W можно только вычитать единицу, большее число никак?
Это всё конечно хорошо, а секретной команды деления на ноль нигде не описано?

Не осилит он.

А кто мешает математику вычитания отрицательного числа из положительного
заменить на сложение положительного числа с отрицательным?
Единственно что для однобайтовых ограничение диапазона от +127 до -127...
У стандартных среднемладших команд поддержки умножения/деления нету.
За исключением общего для практически всех МК умножения/деления на 2 (и степени двойки) сдвигами влево/вправо.

есть много всяких секретных команд ... для деления на ноль используют команду nop