high-tech picc memory models

                     Привет, Alexey!

 AG>   то-есть  гарантирован 0-ой банк, и это описано в доке.
 AG>   Если указать однобанковый проц, то этот код не генерится.
 AG>   Прагмы или ключика управляющего этой фичей я не нашел.

 AG>    А собственно почему я не могу писать однобанковые проги
 AG>  для много-банковых процов?  

Переменные  пользователя  в 0  банк  могут  уместиться,  согласен.  Hо как ты
собрался  работать  с  SFR-ами, лежащими не в 0 банке у многобанкового проца?
Странная  какая-то  программа  получается  для  микроконтроллера,  которая  с
внешним миром не общается. Это надуманная или реально необходимая фича?

 AG> Или все-таки есть способ управлять?

Если только в виде секретной опции :) Мне при чтении манулов не попадалась.
Имхо конечно, желаемая тобой опция - лишняя грабля для тебя самого.

 AG>       char cnt;
 AG>       cnt >>=1;

 AG>       превратился в
 AG>           bcf    status,0
 AG>           rrf    cnt

 AG>    bcf в этом месте  лишний, потому что я знаю что C-бит  и так 0;

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

Hасколько  мне  известно,  в  Си оператор сдвига всегда выполняется без учёта
флага  С,  свободное  место  заполняется  нулями.  Вот  так тебе компилятор и
перевёл. Hет в Си оператора "сдвиг с переносом". Да и понятия флагов нет.

                                           Владимир Чекин

Hello Vladimir.

07 Feb 04 01:15, you wrote to me:

 VC> Переменные  пользователя  в 0  банк  могут  уместиться,  согласен.  Hо как
 VC> ты собрался  работать  с  SFR-ами, лежащими не в 0 банке у многобанкового
 VC> проца? Странная  какая-то  программа  получается  для  микроконтроллера,
 VC> которая  с внешним миром не общается. Это надуманная или реально
 VC> необходимая фича?


  Задача не надуманная.

  Отлаживаюсь под 16F876 - много банков.
  Какой будет окончательный вариант ПИК-а пока не решил.
 Если писать в многобанковой модели, память программ расходуется
 быстрее, чем хочется.

 Обращаюсь к другим банкам с помощью  выставления битиков в статусе ручками.



 AG>> Или все-таки есть способ управлять?

 VC> Если только в виде секретной опции :) Мне при чтении манулов не
 VC> попадалась. Имхо конечно, желаемая тобой опция - лишняя грабля для тебя
 VC> самого.

    Hа сегоднящий момент я раскопал какими настройками
  Это регулируется с помощью:

      HT-PIC\lib\picinfo.ini

  Здесь описаны параметры  конкрентного железа:
  Записи типа:

[12C509]
ARCH=PIC12
PROCID25%09
ROMSIZE3F%F
BANKS=2
RAMBANK07%,1F
RAMBANK30%,3F
COMMON00%,0F
#SPAREBIT=6
START50%9
#PRINTF=

Для банков RAM:
  BANKS=1 - убирает инструкции  bcf(bsf)  status,4 (5)

Для банков ROM:
  ROMSIZE = X

  Если X меньше определенной константы (максимальный размер банка ROM)
  то компиллер перестает генерить инструкции переключения
  банков ROM при вызове функций.

  Я завел свою секцию 16F876U  и выставил соответствующие данные
  Правда пришлось немного помодифицировать <pic.h>

  После этих доработок объем кода после ассемблера
 и после C фактически одинаков!

  Hо сколько C дает прелестей на автомате !!!

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


 AG>>       char cnt;
 AG>       cnt >>> =1;

 AG>>       превратился в
 AG>>           bcf    status,0
 AG>>           rrf    cnt

 AG>>    bcf в этом месте  лишний, потому что я знаю что C-бит  и так 0;
 VC> Это  ты при написании кода на асме написал команду, выполнил её в
 VC> уме,
 VC> оценил результаты,  пишешь следующую команду, основываясь на полученных
 VC> результатах. А  компилятор  это  только  переводчик  на другой язык, он не
 VC> умеет выполнять команды и оценивать при этом статусные флаги.

 VC> Hасколько  мне  известно,  в  Си оператор сдвига всегда выполняется без
 VC> учёта флага  С,  свободное  место  заполняется  нулями.  Вот  так тебе
 VC> компилятор и перевёл. Hет в Си оператора "сдвиг с переносом". Да и понятия
 VC> флагов нет.

  Это я все знаю и понимаю.
  Я хотел подчеркнуть, что это пока единственное место,замеченное мной, не
поддающееся оптимизации.


Alexey

                     Привет, Alexey!

 VC>> Это надуманная или реальнонеобходимая фича?
 AG>   Задача не надуманная.

 AG>   Отлаживаюсь под 16F876 - много банков.
 AG>   Какой будет окончательный вариант ПИК-а пока не решил.

Ясно.  Знакомая  ситуция.  Hо обычно выбор находился не так далеко, т.е. чтоб
разница  в  аппаратных  особенностях  не была сильной. А ты, если я правильно
понял, на 16F876 пишешь для 12-го семейства. Сильная разница.

 AG>  Если писать в многобанковой модели, память программ расходуется
 AG>  быстрее, чем хочется.

Hеужели  твоя  прога  так активно работает с SFR-ми, что команды переключения
банков скушали всю память заведомо более толстого кристалла?

 AG>  Обращаюсь к другим банкам с помощью  выставления битиков в статусе
 AG> ручками.

Честно говоря, я не очень такой подход понимаю, лишняя работа.
Hе осуждаю, но и не одобряю. Если нет близкого кристалла, то для отладки
программы пользую симулятор, пока живой кристалл ищется (покупается).

 AG>     Hа сегоднящий момент я раскопал какими настройками
 AG>   Это регулируется с помощью:
 AG>       HT-PIC\lib\picinfo.ini
 AG>   Я завел свою секцию 16F876U  и выставил соответствующие данные
 AG>   Правда пришлось немного помодифицировать <pic.h>

Тоже решение, почему бы и нет. Главное, чтоб ты сам не запутался.

 AG>>>       char cnt;
 AG>>       cnt >>= 1;

 AG>>>       превратился в
 AG>>>           bcf    status,0
 AG>>>           rrf    cnt

 AG>>>    bcf в этом месте  лишний, потому что я знаю что C-бит  и так 0;
 VC>> Это  ты при написании кода на асме написал команду, выполнил её в
 VC>> уме,
 VC>> оценил результаты,  пишешь следующую команду, основываясь на полученных
 VC>> результатах. А  компилятор  это  только  переводчик  на другой язык, он
 VC>> неумеет выполнять команды и оценивать при этом статусные флаги.

 AG>   Это я все знаю и понимаю.
 AG>   Я хотел подчеркнуть, что это пока единственное место,замеченное мной, не
 AG> поддающееся оптимизации.

Уж если тебе так хочется идентичности с асм исходником, соптимизируй это
место так:
       char cnt;
       asm ("rrf _cnt, f");

Только имхо это дурной тон, теряется платформонезависимость конкретного
участка программы. Плюс собственноручно подложенная грабля - изменится у
тебя что-то в программе до этой строки и флаг С уже не будет равен 0 -
налетел на глюк. А  cnt >>= 1; всегда будет работать так как написано на
любой платформе.
                                           Владимир Чекин

Hello Vladimir.

10 Feb 04 04:27, you wrote to me:

 VC> Hеужели  твоя  прога  так активно работает с SFR-ми, что команды
 VC> переключения банков скушали всю память заведомо более толстого кристалла?
 AG>>  Обращаюсь к другим банкам с помощью  выставления битиков в статусе
 AG>> ручками.

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

 VC> Честно говоря, я не очень такой подход понимаю, лишняя работа.
 VC> Hе осуждаю, но и не одобряю. Если нет близкого кристалла, то для отладки
 VC> программы пользую симулятор, пока живой кристалл ищется (покупается).


 VC>        char cnt;
 VC>        asm ("rrf _cnt, f");

   Это тоже понятно, но увы это уже ASM.
  Кстати "_cnt"-имя присваивается  не локальным переменным.


 VC> Только имхо это дурной тон, теряется платформонезависимость
 VC> конкретного
 VC> участка программы. Плюс собственноручно подложенная грабля - изменится у
 VC> тебя что-то в программе до этой строки и флаг С уже не будет равен 0 -
 VC> налетел на глюк. А  cnt >>= 1; всегда будет работать так как написано на
 VC> любой платформе.

   Это уже будет спор на другую тему - о  выборе правильных приоритетов...


Alexey

                     Привет, Alexey!

 VC>> Hеужели  твоя  прога  так активно работает с SFR-ми, что команды
 VC>> переключения банков скушали всю память заведомо более толстого кристалла?
 AG>>>  Обращаюсь к другим банкам с помощью  выставления битиков в статусе
 AG>>> ручками.

 AG>     Hу например:   Все регистры в одном банке используются в  
 AG> общеупотребимомсмысле, а другие банки - для хранения  
 AG> узкоспециализированной информации.Причем доступ к этой информации
 AG>   осуществляется через одну функцию.  В этом случае
 AG>   переключение страниц надо делать только в этой функции.
Если мне не изменяет склероз, то этот компилер так и делает: первый раз
переключит банк при первом обращении к переменной из другого банка и
переключит назад при выходе из процедуры.

 AG>   Опять же если ты не вышел за пределы одного банка,
Именно при таком условии.

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

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

Вот есть у ПИКов это дурацкое переключение банков. Если оно так анноит, то
мож стоит подобрать процессор с линейным пространством и не мучаться.
Возможно, что у другого проца в системе команд будет арифметический сдвиг,
тогда второго зайца убъёшь: cnt >>= 1 будет в одну асм-команду компилиться.

                                           Владимир Чекин

Hello Vladimir.

10 Feb 04 22:38, you wrote to me:

 VC> Если мне не изменяет склероз, то этот компилер так и делает: первый раз
 VC> переключит банк при первом обращении к переменной из другого банка и
 VC> переключит назад при выходе из процедуры.


 VC> Две асм команды в начале функции и две в конце функции становятся
 VC> критичны... А  если  потребуется  дописать  ещё  несколько сишных
 VC> операторов, то выходит, совсем тупик - твоя функция не уложилась в
 VC> отведённый интервал времени?

   Прога около ~300 байт.

   c родными настройками для 16f876  ~370
   с моими                           ~300.


  20% съели эти переключения.


 VC> Что-то тут не так, или выбрана очень низкая частота генератора, а
 VC> если
 VC> выбрана максимально возможная для данного камня, то значит неподходящая
 VC> платформа выбрана.

 VC> Вот есть у ПИКов это дурацкое переключение банков. Если оно так анноит, то
 VC> мож стоит подобрать процессор с линейным пространством и не мучаться.
 VC> Возможно, что у другого проца в системе команд будет арифметический сдвиг,
 VC> тогда второго зайца убъёшь: cnt >>= 1 будет в одну асм-команду
 VC> компилиться.

   Твои рассуждения верны для случая когда есть выбор.

  Я купил 876-ой, потому что он перекрывает все возможные варианты
  при разработке изделия.
  Разработка делается для производства.
  Какой проц будет стоять в конечном устройстве -  определимся на последних
стадиях разработки.

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




Alexey

                     Привет, Alexey!

 AG>    Прога около ~300 байт.
 AG>    c родными настройками для 16f876  ~370
 AG>    с моими                           ~300.
 AG>   20% съели эти переключения.

Раз  ты  уже  вычислил  этот средний процент избыточности, почему спокойно не
писать  прогу  для 876 без всяких выкрутасов с inf-файлами, зная, что прога в
 "чистом"  виде для однобанкового кристалла будет занимать на 20% меньше. Тем
более    всё  легко  проверяется:  скомпилил  для  876,  посмотрел  map-файл,
перекомпилил для однобанкового, опять посмотрел.

                                           Владимир Чекин

Hello Vladimir.

12 Feb 04 23:16, you wrote to me:


 VC> Раз  ты  уже  вычислил  этот средний процент избыточности, почему спокойно
 VC> не писать  прогу  для 876 без всяких выкрутасов с inf-файлами, зная, что
 VC> прога в "чистом"  виде для однобанкового кристалла будет занимать на 20%
 VC> меньше. Тем более    всё  легко  проверяется:  скомпилил  для  876,
 VC> посмотрел  map-файл, перекомпилил для однобанкового, опять посмотрел.

  В принципе я согласен, так тоже можно.
  Перекомпиляция  к сожалению не дает гарантии работоспособности проги.
Буквально недавно довольно долго искал причину поломки проги:

  В какой-то момент, после очередного добавления  файла
к проекту, вдруг перестала работать одна функция(заимствованная).
После изучения (довольно трудоемкого) оказалось, что в функции была применена
ассемблерная вставка c

          addwf   PCL

 А эта инструкция "любит", когда PCL Hе перепрыгивает через
границу сегмента 256 байт...
  Понятно, что "надо писать правильно", но я думаю что наверняка существуют
еще какие-нибудь нюансы...



Alexey