Код
0009 120A BCF 0xa, 0x4
000A 118A BCF 0xa, 0x3
000B 27F4 CALL 0x7f4
000C 120A BCF 0xa, 0x4
000D 118A BCF 0xa, 0x3
000A 118A BCF 0xa, 0x3
000B 27F4 CALL 0x7f4
000C 120A BCF 0xa, 0x4
000D 118A BCF 0xa, 0x3
Полная версия этой страницы: Hi-Tech PRO PIC10/12/16 V9.65PL1 & PCLATH
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Все остальные микроконтроллеры > PIC
Что сделать, чтобы компилятор не сбрасывал биты выбора страниц памяти в PCLATH там, где не надо (они и так всегда сброшены). Пример его работы:
А в чём проблема?
Цитата(Herz @ Dec 3 2009, 21:10) 
А в чём проблема?
Проблем нет, просто испытываю дискомфорт, изучая код, созданный компилятором. Показываю более полный пример - исходник и результат:
Код
Out = 0; Delay10K(30); // 0.3 s
Out = 1; Delay10K(50); // 0.5 s
Out = 0; Delay10K(30); // 0.3 s
Out = 1; Delay10K(50); // 0.5 s
Out = 0; Delay10K(30); // 0.3 s
Out = 1; Delay10K(50); // 0.5 s
Out = 1; Delay10K(50); // 0.5 s
Out = 0; Delay10K(30); // 0.3 s
Out = 1; Delay10K(50); // 0.5 s
Out = 0; Delay10K(30); // 0.3 s
Out = 1; Delay10K(50); // 0.5 s
Код
61: Out = 0; Delay10K(30); // 0.3 s
0027 1008 BCF 0x8, 0
0028 301E MOVLW 0x1e
0029 120A BCF 0xa, 0x4
002A 118A BCF 0xa, 0x3
002B 27F3 CALL 0x7f3
62: Out = 1; Delay10K(50); // 0.5 s
002C 1408 BSF 0x8, 0
002D 3032 MOVLW 0x32
002E 120A BCF 0xa, 0x4
002F 118A BCF 0xa, 0x3
0030 27F3 CALL 0x7f3
63: Out = 0; Delay10K(30); // 0.3 s
0031 1008 BCF 0x8, 0
0032 301E MOVLW 0x1e
0033 120A BCF 0xa, 0x4
0034 118A BCF 0xa, 0x3
0035 27F3 CALL 0x7f3
64: Out = 1; Delay10K(50); // 0.5 s
0036 1408 BSF 0x8, 0
0037 3032 MOVLW 0x32
0038 120A BCF 0xa, 0x4
0039 118A BCF 0xa, 0x3
003A 27F3 CALL 0x7f3
65: Out = 0; Delay10K(30); // 0.3 s
003B 1008 BCF 0x8, 0
003C 301E MOVLW 0x1e
003D 120A BCF 0xa, 0x4
003E 118A BCF 0xa, 0x3
003F 27F3 CALL 0x7f3
66: Out = 1; Delay10K(50); // 0.5 s
0040 1408 BSF 0x8, 0
0041 3032 MOVLW 0x32
0042 120A BCF 0xa, 0x4
0043 118A BCF 0xa, 0x3
0044 27F3 CALL 0x7f3
0027 1008 BCF 0x8, 0
0028 301E MOVLW 0x1e
0029 120A BCF 0xa, 0x4
002A 118A BCF 0xa, 0x3
002B 27F3 CALL 0x7f3
62: Out = 1; Delay10K(50); // 0.5 s
002C 1408 BSF 0x8, 0
002D 3032 MOVLW 0x32
002E 120A BCF 0xa, 0x4
002F 118A BCF 0xa, 0x3
0030 27F3 CALL 0x7f3
63: Out = 0; Delay10K(30); // 0.3 s
0031 1008 BCF 0x8, 0
0032 301E MOVLW 0x1e
0033 120A BCF 0xa, 0x4
0034 118A BCF 0xa, 0x3
0035 27F3 CALL 0x7f3
64: Out = 1; Delay10K(50); // 0.5 s
0036 1408 BSF 0x8, 0
0037 3032 MOVLW 0x32
0038 120A BCF 0xa, 0x4
0039 118A BCF 0xa, 0x3
003A 27F3 CALL 0x7f3
65: Out = 0; Delay10K(30); // 0.3 s
003B 1008 BCF 0x8, 0
003C 301E MOVLW 0x1e
003D 120A BCF 0xa, 0x4
003E 118A BCF 0xa, 0x3
003F 27F3 CALL 0x7f3
66: Out = 1; Delay10K(50); // 0.5 s
0040 1408 BSF 0x8, 0
0041 3032 MOVLW 0x32
0042 120A BCF 0xa, 0x4
0043 118A BCF 0xa, 0x3
0044 27F3 CALL 0x7f3
Когда я писал на ассемблере, я выбирал страницы по мере необходимости. А тут весь код в одной странице, зачем же "перетрахивать" ненужные биты? И памяти жалко, и времени...
Цитата(ViKo @ Dec 4 2009, 11:03)
Проблем нет, просто испытываю дискомфорт, изучая код, созданный компилятором. Показываю более полный пример - исходник и результат:
Когда я писал на ассемблере, я выбирал страницы по мере необходимости. А тут весь код в одной странице, зачем же "перетрахивать" ненужные биты? И памяти жалко, и времени...
Код
...
0044 27F3 CALL 0x7f3
0044 27F3 CALL 0x7f3
Когда я писал на ассемблере, я выбирал страницы по мере необходимости. А тут весь код в одной странице, зачем же "перетрахивать" ненужные биты? И памяти жалко, и времени...
Не стоит их жалеть, ведь, как Вы сами сказали, проблем нет и на производительности (как я понимаю) это не сказывается. Тем более, что программные задержки по типу ваших уж никак примером эффективности служить не могут - в них потеряете больше... Кроме того, Вы уверены что при вызове функции не происходит переход на другую страницу? Где находится 0x7f3 ?
Цитата(Herz @ Dec 4 2009, 11:18)
программные задержки по типу ваших уж никак примером эффективности служить не могут - в них потеряете больше...
Где находится 0x7f3 ?
Где находится 0x7f3 ?
Мне большего не требуется. Простая задача, простая программа. Речь не о ней. Так будет везде, в любой программе.
А 0x7f3 находится в конце нулевой страницы. В данном вопросе компилятор молодец, разместил подпрограмму в конце, чтобы не "путалась под ногами".
Цитата(ViKo @ Dec 4 2009, 11:33)
Мне большего не требуется. Простая задача, простая программа. Речь не о ней. Так будет везде, в любой программе.
А 0x7f3 находится в конце нулевой страницы. В данном вопросе компилятор молодец, разместил подпрограмму в конце, чтобы не "путалась под ногами".
А 0x7f3 находится в конце нулевой страницы. В данном вопросе компилятор молодец, разместил подпрограмму в конце, чтобы не "путалась под ногами".
Да, я тоже заметил, что компилятор молодец
и часто делает за нас нашу работу иногда лучше нас самих. Так что не спешите тревожится: будут проблемы - будут и решения... 
А то , что обратили внимание: по-моему, хорошо и пока достаточно.
Цитата(ViKo @ Dec 3 2009, 17:45)
Что сделать, чтобы компилятор не сбрасывал биты выбора страниц памяти в PCLATH
Предложите htsoft'у 100% алгоритм определения при компиляции
Цитата
там, где не надо
и они с удовольствием его реализуют.
Пока их компиляторы для пиков перед вызовом функций безусловно устанавливают PCLATH на требуемую страницу.
Зачем? Из-за ограничений архитектуры мелких пиков. Посмотрите, во что развернётся обращение к const или к (*)(), если объект обращения живёт на другой странице.
Вы таким не пользуетесь? А кому-то оно надо.
Цитата(xemul @ Dec 4 2009, 16:35)
Предложите htsoft'у 100% алгоритм определения при компиляции
и они с удовольствием его реализуют.
и они с удовольствием его реализуют.
А как я, программируя на ассемблере, всегда знал, на какой странице нахожусь?
Нужно пробежаться по коду еще раз и посмотреть, где находишься при вызове (переходе), в каком состоянии PCLATH и в каком он должен быть для вызова (перехода). А может быть, и не нужно "еще раз...", а сразу при генерации кода (как это делается - не в моей компетенции).
Точно нельзя какую-нибудь опцию подправить, чтоб было, как хочу?
Цитата(ViKo @ Dec 4 2009, 18:58)
А как я, программируя на ассемблере, всегда знал, на какой странице нахожусь?
Нужно пробежаться по коду еще раз и посмотреть, где находишься при вызове (переходе), в каком состоянии PCLATH и в каком он должен быть для вызова (перехода). А может быть, и не нужно "еще раз...", а сразу при генерации кода (как это делается - не в моей компетенции).
Нужно пробежаться по коду еще раз и посмотреть, где находишься при вызове (переходе), в каком состоянии PCLATH и в каком он должен быть для вызова (перехода). А может быть, и не нужно "еще раз...", а сразу при генерации кода (как это делается - не в моей компетенции).
"Не читал, но осуждаю."
Архитектура мелких пиков очень неудобна для оптимизирующих компиляторов организацией и памяти программ, и памяти данных, и способами адресации. "где находишься при вызове (переходе)" компилятору вообще должно быть неинтересно - это проблема линкера, но из-за особенностей архитектуры ему приходится думать о каком-то PCLATH.
Поэтому и компиляторов под них чуть да ничего. А вменяемых компиляторов ещё меньше.
Цитата
Точно нельзя какую-нибудь опцию подправить, чтоб было, как хочу?
Пока нет. Точно.
Может когда-нить htsoft и допилит Omniscient Code GenerationTM до состояния, когда качество его кода начнёт устраивать мастеров ассемблера, но, имхо, мелкие пики отомрут раньше.
Цитата(xemul @ Dec 4 2009, 20:32)
Может когда-нить htsoft и допилит Omniscient Code GenerationTM до состояния, когда качество его кода начнёт устраивать мастеров ассемблера, но, имхо, мелкие пики отомрут раньше.
Почему Вы их не любите? Я про мелкие пики. И как Вы их классифицируете? По числу ног или по разрядности?
Мое мнение - семейства PIC10/12/16 не блещут производительностью по сравнению с AVR, например. Выбирая сейчас, может быть я выбрал бы микроконтроллеры Atmel. Но, во-первых - привык к PIC, знаю их в совершенстве (и команд мало, легко запомнить, и средства программирования мне кажутся удобными и доступными). Во-вторых, не доверяю фирме Atmel с их глюками в железе и документации (личное субъективное мнение, отстаивать не буду). В мире есть много интересных микроконтроллеров, но там, где можно, я буду применять PIC10/12/16, возможно PIC18. А там где нельзя - STM32, например (опять же, субъективный выбор, не настаиваю на правильности).
В-общем, что любить или не любить - личное дело каждого.
В-общем, что любить или не любить - личное дело каждого.
Цитата(ViKo @ Dec 7 2009, 12:25)
В-общем, что любить или не любить - личное дело каждого.
Не втягивайтесь в бесполезный трёп, это к делу не относится...
А вот гляньте на следующий код! Та же программа, что демонстрировал вначале, была слегка модернизирована. Компилятор, правда, 9.70. Но, думаю, дело не в нем, а неком "стечении обстоятельств", позволяющих компилятору решить, что биты выбора страниц "ператрахивать" не надо.
В-общем, все не так просто. Найти бы эти "обстоятельства"...
Код
Out = 0; Delay10K(Time); // 0.05 .. 0.4 s
036 1105 BCF 0x5, 0x2
037 0825 MOVF 0x25, W
038 23F2 CALL 0x3f2
95: Out = 1; Delay10K(30); // 0.3 s
039 1505 BSF 0x5, 0x2
03A 301E MOVLW 0x1e
03B 23F2 CALL 0x3f2
96: // Out = 0; Delay10K(20); // 0.2 s
97: Out = 0; Delay10K(Time); // 0.05 .. 0.4 s
03C 1105 BCF 0x5, 0x2
03D 0825 MOVF 0x25, W
03E 23F2 CALL 0x3f2
98: Out = 1; Delay10K(30); // 0.3 s
03F 1505 BSF 0x5, 0x2
040 301E MOVLW 0x1e
041 23F2 CALL 0x3f2
99: // Out = 0; Delay10K(20); // 0.2 s
100: Out = 0; Delay10K(Time); // 0.05 .. 0.4 s
042 1105 BCF 0x5, 0x2
043 0825 MOVF 0x25, W
044 23F2 CALL 0x3f2
101: Out = 1; Delay10K(30); // 0.3 s
045 1505 BSF 0x5, 0x2
046 301E MOVLW 0x1e
047 23F2 CALL 0x3f2
036 1105 BCF 0x5, 0x2
037 0825 MOVF 0x25, W
038 23F2 CALL 0x3f2
95: Out = 1; Delay10K(30); // 0.3 s
039 1505 BSF 0x5, 0x2
03A 301E MOVLW 0x1e
03B 23F2 CALL 0x3f2
96: // Out = 0; Delay10K(20); // 0.2 s
97: Out = 0; Delay10K(Time); // 0.05 .. 0.4 s
03C 1105 BCF 0x5, 0x2
03D 0825 MOVF 0x25, W
03E 23F2 CALL 0x3f2
98: Out = 1; Delay10K(30); // 0.3 s
03F 1505 BSF 0x5, 0x2
040 301E MOVLW 0x1e
041 23F2 CALL 0x3f2
99: // Out = 0; Delay10K(20); // 0.2 s
100: Out = 0; Delay10K(Time); // 0.05 .. 0.4 s
042 1105 BCF 0x5, 0x2
043 0825 MOVF 0x25, W
044 23F2 CALL 0x3f2
101: Out = 1; Delay10K(30); // 0.3 s
045 1505 BSF 0x5, 0x2
046 301E MOVLW 0x1e
047 23F2 CALL 0x3f2
В-общем, все не так просто. Найти бы эти "обстоятельства"...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.