Hi-Tech PRO PIC10/12/16 V9.65PL1 & PCLATH Опции

[ViKo]

Что сделать, чтобы компилятор не сбрасывал биты выбора страниц памяти в PCLATH там, где не надо (они и так всегда сброшены). Пример его работы:

Код

  0009    120A     BCF 0xa, 0x4
  000A    118A     BCF 0xa, 0x3
  000B    27F4     CALL 0x7f4
  000C    120A     BCF 0xa, 0x4
  000D    118A     BCF 0xa, 0x3

[xemul]

Что сделать, чтобы компилятор не сбрасывал биты выбора страниц памяти в PCLATH

Предложите htsoft'у 100% алгоритм определения при компиляции

там, где не надо

и они с удовольствием его реализуют.
Пока их компиляторы для пиков перед вызовом функций безусловно устанавливают PCLATH на требуемую страницу.
Зачем? Из-за ограничений архитектуры мелких пиков. Посмотрите, во что развернётся обращение к const или к (*)(), если объект обращения живёт на другой странице.
Вы таким не пользуетесь? А кому-то оно надо.

[ViKo]

Предложите htsoft'у 100% алгоритм определения при компиляции
и они с удовольствием его реализуют.

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

[xemul]

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

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

Точно нельзя какую-нибудь опцию подправить, чтоб было, как хочу?

Пока нет. Точно.
Может когда-нить htsoft и допилит Omniscient Code Generation^TM до состояния, когда качество его кода начнёт устраивать мастеров ассемблера, но, имхо, мелкие пики отомрут раньше.

[Евгений Германов...]

Может когда-нить htsoft и допилит Omniscient Code Generation^TM до состояния, когда качество его кода начнёт устраивать мастеров ассемблера, но, имхо, мелкие пики отомрут раньше.

Почему Вы их не любите? Я про мелкие пики. И как Вы их классифицируете? По числу ног или по разрядности?

[ViKo]

Мое мнение - семейства PIC10/12/16 не блещут производительностью по сравнению с AVR, например. Выбирая сейчас, может быть я выбрал бы микроконтроллеры Atmel. Но, во-первых - привык к PIC, знаю их в совершенстве (и команд мало, легко запомнить, и средства программирования мне кажутся удобными и доступными). Во-вторых, не доверяю фирме Atmel с их глюками в железе и документации (личное субъективное мнение, отстаивать не буду). В мире есть много интересных микроконтроллеров, но там, где можно, я буду применять PIC10/12/16, возможно PIC18. А там где нельзя - STM32, например (опять же, субъективный выбор, не настаиваю на правильности).
В-общем, что любить или не любить - личное дело каждого.