имеется asm-программа .
в MPLAB IDE 8.33 запущен отладчик MPLAB SIM.
двигаясь по шагам , перехожу на подпрограмму с адреса 0050 на адрес 0140.
в окне WATCH наблюдаю изменение PCL на 40, а PCLATH почему-то остается в 00,
хотя отладчик двигается дальше 0142.. и в PCLATH я ожидал видеть 01.

Вы неправильно понимаете смысл регистра PCLATH.
01 (так понимаю, это - хексы, поэтому не забывайте указывать 01h, или 0x01, и т.п.) у Вас в старшем регистре програмного счётчика.
PCLATH используется, когда опкод не содержит значение для в/у регистра.
Тогда предварительно надо в PCLATH записать значение, которое будет переписано в старший регистр програмного счётчика, при выполнении команд с таким опкодом.
Ну, и как принято говорить: читайте даташит.
Там всё очень хорошо разрисовано (за что люблю Майкрочип).

да, спасибо, как водится, пока 5 раз одно и тоже в даташите не прочитаешь, не поймешь.
добавил команду MOVF PCL и увидел в PCLATH реальный сегмент адреса.
тема собственно меня забеспокоила потому, что в вызове подпрограммы, которая размещается
в произвольном месте присутствует еще подпрограмма с т.н. вычисляемым переходом ADDWF PCL,
в результате которого у меня вместо 0318h происходит перескок на 0018h

Фигня какая-то.
В том-то весь и фокус, что операции с програмным счётчиком никак не влияют на содержимое регистра PCLATH.
Что туда запишите, то там и будет находиться до следующей перезаписи.
Реальный сегмент находится в PCH.

Если в произвольном, то надо делать пару десятков строк дополнительного кода.
В двух словах так:
Сперва пишите в PCLATH старшую половину адреса метки начала таблицы переходов.
Затем производите сложение PCL с переменной перехода, но с результатом в аккумулятор.
Если поднят флаг переноса, инкрементируете PCLATH.
Опять производите сложение с PCL, но уже результат в регистр.
Если необходимо сократить код и/или повысить быстродействие (т.е. сократить количество команд), есть вариант размещать таблицу переходов строго в пределах 256-строчного сегмента адресов (чтобы при сложении PCL гарантировано не было переполнения).

влияют
вот даташит говорит, что содержимое PC транслируется в PCLATH при любом чтении PC.
the upper two bytes of the program
counter are transferred to PCLATH and PCLATU by an
operation that reads PCL.
проверьте в отладчике , если сомневаетесь.

Давайте-ка по прядку.
Что у Вас за камень?

что такое PCH ? не нахожу в даташите на PIC18F2550
кстати, в отладчике среди SFR имеется PCLAT , тоже не понятно что это, ибо в даташите тоже не вижу,
по разрядам вроде соответствует счетчику, но изменяется тоже только в пределах 256

Тогда понятно.
Я говорил про 12-16 серии. Там такого не было, насколько помню.
В 18 подшаманили.

На десять строк выше Вашей цитаты.

Это, видимо PCLATH и PCLATU вместе взятые.
Разрядов-то сколько?
Такая же фигня и с TMR1H и TMR1L, например.
Удобнее смотреть целиком (ИМХО, разумеется).

Smen спасибо за содействие

с PCLATH я пока обошелся авантюрно-
перед ADDWF PCL выставил один оператор
MOVFF TOSH,PCLATH
и он меня спасает, если таблица и ее вызов находятся в одном сегменте.
пока для простой отладки мне достаточно.

PCLAT

видимо, не так. адреса разные.
а у PCL и PCLAT один и тот же адрес FF9, но разрядность у PCLAT 0x000000,
хотя изменения почему происходят только в младшем байте.
ну как водится со временем можно разобраться , если будет практическая необходимость.

Как-то совсем авантюрно.
Это сперва должен быть вызов ПП.
А чем не устраивает обычный


Да какие адреса? Это же виртуальный регистр.
Он существует только в отладчике для визуального удобства восприятия.
Судя по разрядности, это PCLATU + PCLATH + PCL

не совсем понимаю, что кроется под hight label.
мой замысел был таков
от строки вызова call pprog перехожу
к метке pprog ( в этом же сегменте)
делаю MOFF TOSH,PCLATH - записываю в PCLATH код сегмента вызывателя, чтоб потом
через ADDWF PCL и соответствующий retlw вернуться именно к вызывателю, а
не к вызывателю вызывателя, находящегося в другом сегменте




это просто констатация того, что изображает отладчик

Под hight label кроется номер сегмента, в котором размещена таблица.
Если таблица имеет размер более одного сегмента, то hight label нужно предварительно вычислить.
При выполнении команды RETLW в таблице, возврат произойдет БЕЗ ПРИВЯЗКИ К PCLATH, поскольку стек имеет ПОЛНУЮ РАЗРЯДНОСТЬ счетчика команд.
Из чего следует, что Ваши выкрутасы с вершиной стека не имеют никакого смысла и лишь приведут к разрушению стека.
Регистр PCLATH - это просто буфер, с помощью которого синхронизируют изменение младшего байта счетчика команд с изменением старшего байта того же счетчика.
Никакого отношения PCLATH не имеет к самому PC (PCL:PCH), который собственно и управляет выборкой из программного флеша очередной команды.

Старший (точнее средний) байт адреса метки (т.е. то, что должно находиться в PCLATH).
Выше я расписывал алгоритм.

Для retlw PCLATH не нужен, но он необходим при переходе на этот retlw.
И никакого разрушения стэка быть не должно, хотя я тоже считаю, что данная конструкция "через Ж".

balk, если у Вас вся таблица только из retlw (т.е. долько данные), то 18 семейство позволяет использовать специальные команды табличного чтения.
Может Вам посмотреть в эту сторону?

Нынче и все относительно новые 12...16-ые тоже позволяют. Причем даже проще, чем 18-ые. Флеш доступен, начиная с адреса оперативной памяти 0x8000.

У ТС 18F2550.

Я в курсе. Речь шла о Вашем упоминании.

Спасибо, друзья , за ценные замечания !
всё-таки один момент мне не стал понятнее,
как по команде ADDWF PCL программа перейдет на нужную RETLW, если при
выполнении ADDWF произойдет запись в PCH из PCLATH, в котором адресный байт другого сегмента. ?

в том то и дело , что до RETLW не доходим, а срываемся в другой сегмент.
вот собственно хребет , который всё наглядно может продемонстрировать
#include <p18f2550.inc>
org 0
goto start
nop
nop
nop
nop

org 0x20
start
call module

org 0x100
table
addwf PCL,1,0
retlw 0x50
retlw 0xde
retlw 0x62
retlw 0xc2
retlw 0xcc
retlw 0xc1

module
movlw 0x06
call table
nop
nop
END
после addwf программа перепрыгивает на выделенный жирным nop ,
а не возвращается в module.

В PCLATH - ноль (а в реале может быть любое число, поскольку нет инициализации регистра), вот он и подставляется в старший байт адреса.
Что ж тут непонятного?
Вставьте перед movlw

И попадёте куда нужно.
P.S.: Только конструкция всё-равно кривая.
И для записи листинга программы на форуме пользуйтесь тэгом code (см. кнопочки вверху окна сообщения).

спасибо! вопросы остаются, но свернём тему , чтоб по второму кругу не начинать.

Smenв смежной теме Вы предложили вернуться к PCLATH.
Кстати вопрос у меня остался такой
в Вашем коде
используются две команды, кроме того ещё задействован регистр W, который должен передавать в таблицу
вектор перехода, соответственно нужно предусматривать дополнительные манипуляции с W.
В коде
не нахожу ничего такого, чем бы он уступал Вашему .

Возвращаться я не предлагал, мне просто показалась несколько странной последовательность Ваших действий.

Команда movff занимает два МЦ и два слова памяти программ, ровно столько же, сколько и в/у две команды (читайте уже наконец даташит), так что с точки зрения времени выполнения/размера обе конструкции одинаковы.
А вот относительно логики.
В моей последовательности загружается адрес таблицы, а в Вашей, указатель стека. Разницу чувствуете?
Насчёт волнений по поводу аккумулятора, вообще не понятно. На то он и аккумулятор, что б его активно использовать.
У Вас следом пойдёт ещё одна movlw, так какая разница, что там в аккумуляторе будет находиться?

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




Извините, здесь, должен признаться, не чувствую разницы. Был бы признателен за разъяснения


и мне кажется в этом контексте уместней говорить не "загружается", а читается

Если Вы имеете ввиду про то, что в/у команда пишется в одну строчку, так какая разница, будет в программе 3000 строк, или 3001?
Вообще, говорить о краткости листинга, используя АСМ как-то стрёмно. Переходите уж тогда на СИ.

Про "команды, которые нужно внедрить для манипуляций с аккумулятором" я что-то вообще не понял.
Что Вы там ещё внедрять хотите? Кроме в/у двух команд ничего не требуется.

Кстати, Ваши двойные вызовы ПП вовсе не сокращают листинг, да вдобавок ещё и стэк забивают, а ведь он не резиновый.


Это очень плохо. Попробую ещё раз пояснить.
В PCLATH необходимо загрузить (именно "загрузить") адрес "таблицы переходов".
В моём примере он туда и загружается, а в Вашем в него загружается указатель вершины стэка, в котором оказывается нужное значение.
Сейчас это сработало, но когда-нибудь может в указателе оказаться совсем не то, что нужно, а вот адрес таблицы всегда останется адресом.
Я уже молчу о совместимости кода с другими семействами.
И если Вы возразите, что никуда его переносить не собираетесь, то я отвечу, что тогда Вам вообще нужно использовать команды табличного чтения.

спасибо Smen
приятно получить развернутый ответ с изложением тонких мест.

Чуть добавлю.
Смысл команды movff совсем не в краткости записи. Эта команда, не модифицирует контекст (аккумулятор и флаги состояния АЛУ). И именно в таком качестве ее следует применять. Если аккумулятор и флаги могут быть произвольно изменены, то нет никакого практического смысла в применении movff.