ViKo 1 3 декабря, 2009 Опубликовано 3 декабря, 2009 · Жалоба Что сделать, чтобы компилятор не сбрасывал биты выбора страниц памяти в 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 5 3 декабря, 2009 Опубликовано 3 декабря, 2009 · Жалоба А в чём проблема? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба А в чём проблема? Проблем нет, просто испытываю дискомфорт, изучая код, созданный компилятором. Показываю более полный пример - исходник и результат: 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 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 Когда я писал на ассемблере, я выбирал страницы по мере необходимости. А тут весь код в одной странице, зачем же "перетрахивать" ненужные биты? И памяти жалко, и времени... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 5 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба Проблем нет, просто испытываю дискомфорт, изучая код, созданный компилятором. Показываю более полный пример - исходник и результат: ... 0044 27F3 CALL 0x7f3 Когда я писал на ассемблере, я выбирал страницы по мере необходимости. А тут весь код в одной странице, зачем же "перетрахивать" ненужные биты? И памяти жалко, и времени... Не стоит их жалеть, ведь, как Вы сами сказали, проблем нет и на производительности (как я понимаю) это не сказывается. Тем более, что программные задержки по типу ваших уж никак примером эффективности служить не могут - в них потеряете больше... Кроме того, Вы уверены что при вызове функции не происходит переход на другую страницу? Где находится 0x7f3 ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба программные задержки по типу ваших уж никак примером эффективности служить не могут - в них потеряете больше... Где находится 0x7f3 ? Мне большего не требуется. Простая задача, простая программа. Речь не о ней. Так будет везде, в любой программе. А 0x7f3 находится в конце нулевой страницы. В данном вопросе компилятор молодец, разместил подпрограмму в конце, чтобы не "путалась под ногами". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 5 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба Мне большего не требуется. Простая задача, простая программа. Речь не о ней. Так будет везде, в любой программе. А 0x7f3 находится в конце нулевой страницы. В данном вопросе компилятор молодец, разместил подпрограмму в конце, чтобы не "путалась под ногами". Да, я тоже заметил, что компилятор молодец и часто делает за нас нашу работу иногда лучше нас самих. Так что не спешите тревожится: будут проблемы - будут и решения... :laughing: А то , что обратили внимание: по-моему, хорошо и пока достаточно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xemul 0 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба Что сделать, чтобы компилятор не сбрасывал биты выбора страниц памяти в PCLATH Предложите htsoft'у 100% алгоритм определения при компиляции там, где не надо и они с удовольствием его реализуют. Пока их компиляторы для пиков перед вызовом функций безусловно устанавливают PCLATH на требуемую страницу. Зачем? Из-за ограничений архитектуры мелких пиков. Посмотрите, во что развернётся обращение к const или к (*)(), если объект обращения живёт на другой странице. Вы таким не пользуетесь? А кому-то оно надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба Предложите htsoft'у 100% алгоритм определения при компиляции и они с удовольствием его реализуют. А как я, программируя на ассемблере, всегда знал, на какой странице нахожусь? Нужно пробежаться по коду еще раз и посмотреть, где находишься при вызове (переходе), в каком состоянии PCLATH и в каком он должен быть для вызова (перехода). А может быть, и не нужно "еще раз...", а сразу при генерации кода (как это делается - не в моей компетенции). Точно нельзя какую-нибудь опцию подправить, чтоб было, как хочу? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xemul 0 4 декабря, 2009 Опубликовано 4 декабря, 2009 · Жалоба А как я, программируя на ассемблере, всегда знал, на какой странице нахожусь? Нужно пробежаться по коду еще раз и посмотреть, где находишься при вызове (переходе), в каком состоянии PCLATH и в каком он должен быть для вызова (перехода). А может быть, и не нужно "еще раз...", а сразу при генерации кода (как это делается - не в моей компетенции). "Не читал, но осуждаю." Архитектура мелких пиков очень неудобна для оптимизирующих компиляторов организацией и памяти программ, и памяти данных, и способами адресации. "где находишься при вызове (переходе)" компилятору вообще должно быть неинтересно - это проблема линкера, но из-за особенностей архитектуры ему приходится думать о каком-то PCLATH. Поэтому и компиляторов под них чуть да ничего. А вменяемых компиляторов ещё меньше. Точно нельзя какую-нибудь опцию подправить, чтоб было, как хочу? :) Пока нет. Точно. Может когда-нить htsoft и допилит Omniscient Code GenerationTM до состояния, когда качество его кода начнёт устраивать мастеров ассемблера, но, имхо, мелкие пики отомрут раньше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
E1962 0 6 декабря, 2009 Опубликовано 6 декабря, 2009 · Жалоба Может когда-нить htsoft и допилит Omniscient Code GenerationTM до состояния, когда качество его кода начнёт устраивать мастеров ассемблера, но, имхо, мелкие пики отомрут раньше. Почему Вы их не любите? Я про мелкие пики. И как Вы их классифицируете? По числу ног или по разрядности? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 7 декабря, 2009 Опубликовано 7 декабря, 2009 · Жалоба Мое мнение - семейства PIC10/12/16 не блещут производительностью по сравнению с AVR, например. Выбирая сейчас, может быть я выбрал бы микроконтроллеры Atmel. Но, во-первых - привык к PIC, знаю их в совершенстве (и команд мало, легко запомнить, и средства программирования мне кажутся удобными и доступными). Во-вторых, не доверяю фирме Atmel с их глюками в железе и документации (личное субъективное мнение, отстаивать не буду). В мире есть много интересных микроконтроллеров, но там, где можно, я буду применять PIC10/12/16, возможно PIC18. А там где нельзя - STM32, например (опять же, субъективный выбор, не настаиваю на правильности). В-общем, что любить или не любить - личное дело каждого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 5 7 декабря, 2009 Опубликовано 7 декабря, 2009 · Жалоба В-общем, что любить или не любить - личное дело каждого. Не втягивайтесь в бесполезный трёп, это к делу не относится... :wassat: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 19 марта, 2010 Опубликовано 19 марта, 2010 · Жалоба А вот гляньте на следующий код! Та же программа, что демонстрировал вначале, была слегка модернизирована. Компилятор, правда, 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 В-общем, все не так просто. Найти бы эти "обстоятельства"... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
