Про HT-PIC

Sep 04, 2003 14 Replies

Hi, All!



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



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



static bit Flag; char Counter; if(Flag) Counter++;



компилируется в следующее: btfss (_Flag/8),(_Flag)&7 goto u471 goto u470 u471 goto l93 u470 incf (((_Counter))) l93



Это вместо: btfsc (_Flag/8),(_Flag)&7 incf (((_Counter)))



5 слов вместо 2 возможных! 6 тактов вместо тех же 2! И не Бог весть какой сложный анализ для этого провести надо. То, что компилятор не догадывается, что если блок оператора if компилируется в одну команду, то goto не нужен, я еще где-то могу понять (хотя мог бы и догадаться, весьма распространенная ситуация). Но зачем ставить goto на еще один goto ?!

Происходит это все на высшем уровне оптимизации (9), впрочем выше 5-6 уровня код уже практически не меняется, я разницы не заметил. Кроме того, не применяется повторное использование кода, не в пример тому же IAR C, который, увидев буквально 2-3 одинаковые команды в разных местах, оформляет их как подпрограмму. Понятно, что PIC не самый удобный процессор для С, и стек маленький, но ведь он все равно же дерево вызовов анализирует, и, там, где глубина стека позволяет (а таких мест хватает), мог бы ведь использовать...



В итоге, программа, которая на асме занимала чуть больше 3Кслов, теперь не лезет (или с трудом лезет) в 8К.



Да, версия - 8.01, может она неудачная какая в этом плане, какой версией народ пользуется? И попутно еще вопрос, я его тут уже задавал, но все проигнорировали -



- где бы доку на компилятор взять, соглашения о передаче параметров в функции, распределение памяти, и т.п? Какие слова знает инлайновый асемблер, и где они определены? Например, он слово status (в качестве имени регистра) проглатывает, а ccpr1l - нет, приходится адрес вручную указывать .



Примите уверения в совершеннейшем к Вам почтении


Hi Sergey, hope you are having a nice day!

04 Сен 03, Sergey Zabelin wrote to All:

SZ> Понадобилось мне тут реинжиниринг своего старого устройства SZ> на PIC16C74 провести - несколько расширить функциональность. SZ> А писано оно на асме было. Решил, что быстрее его на С перепишу, SZ> чем с асемблером ковыряться, опять же - третье тысячелетие на SZ> дворе, человека пишущего на асме уже осмеивают. SZ> Взял HT-PIC, начитавшись в этой эхе славословий, какой это SZ> замечательный компилятор, и как здорово он код оптимизирует...

Хм. Hу я, например, неоднократно здесь повторял, что C _не для 16-х пиков_. Применять его можно только если не интересует результат и требуется сделать что-то очень быстро.

WBR, AVB

ICQ# 43835774 mailto: avb<at>dialup.etr.ru

Hello, Sergey Zabelin !

Это руки... Вставил специально в свою программу твой код:

817 ;ratx_819.c: 514: if (msec) porta++; 818 06DE 18A0 btfsc _msec/(0+8),_msec& (0+7) 819 06DF 0AA9 incf _porta

У тебя или оптимизация не включена, или отладочная информация включена или и то и другое. У меня V8.01PL3, командная строка:

PICC.EXE -O -G -Zg -INTEL -D24 -PSECTMAP -ASMLIST -16F819 C:\PIC\ratx_819.c

Это же дольше...

Конечно если у тебя if так компилируется. Попробуй взять последний компилятор и правильные опции его запуска. Оверхед конечно есть, но _такой_ разницы быть не должно.

Hу возьми тут, если не нашел оригинал

formatting link

С уважением, Дима Орлов.

Привет Vladimir!

Thursday September 04 2003 21:43, Vladimir Chekin wrote to Sergey Zabelin:

VC> Hу не знаю, не знаю... Сам долго сидел на асме, поэтому по инерции VC> постоянно гляжу в окно дизассемблера и могу сказать, что компилер VC> довольно оптимально генерит код, прям как бы я сам так и писал :)

Hо в тех местах где важна скорость - посмотреть очень не мешает что он там нагенерил, например конструкции типа A/=16 могут быть сильно сокращены если написать не "16" а "16U" (разумеется - где это можно), вместо 16 - могут быть такие-же "круглые" числа, типа 128, 256 и т.п. и тоже самое и умножения, конечно касается. Компилятор может подпрограмму вызвать, а может сдвигами или свапами нибблов.

И, например, на 6-м уровне оптимизации с пост-процессингом (на последнем уровне не пробовал, я всю отладку на "середке" делаю", а потом уже...) - он мне на такой код:

while (1) PORTB6 ^=1;

нагенерил:

L???: movlw 0b01000000 xorwf PORTB,1 goto L???

пришлось ручками исправить:

asm ("movlw 0b01000000") L1: asm ("xorwf PORTB,1") goto L1

Почему - понятно.

SZ>> параметров в функции, распределение памяти, и т.п? Какие слова SZ>> знает инлайновый асемблер, и где они определены? Hапример, он слово SZ>> status (в качестве имени регистра) проглатывает, а ccpr1l - нет, SZ>> приходитсяадрес вручную указывать . VC>

VC> #include <pic .h> сделал? А при вызове компилера тип процика указал VC> или в исходнике, например #define _16C73. Как правильно задавать типы VC> процессоров в этом самом pic.h и смотреть.

ТЕм не менее. некоторых имен регистров или битов - в инклудах нет :( Приходится описывать ручками. Еще - достает что некоторые биты периодически переименовываются, что-то такое было недавно с ADGO.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

formatting link
,
formatting link
,ftp://altor.sytes.net

Привет, Alexey!

SZ>> Взял HT-PIC, начитавшись в этой эхе славословий, какой это SZ>> замечательный компилятор, и как здорово он код оптимизирует...

AB> Хм. Hу я, например, неоднократно здесь повторял, что C _не для 16-х AB> пиков_. Применять его можно только если не AB> интересует результат и требуется сделать что-то очень быстро.

Алексей, Вы же грамотный человек, зачем разводит новый флейм почём зря по аналогии с тредом "begin". У автора вопроса что-то явно не так. См. мой ответ ему.

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

приходится

дык это не в доке, это в папке "инклуд" всё лежит, начни с <pic.h>, дальше увидишь всё сам, можешь и подправить там чего-нибудь (например, макросы обращения к EEPROM)

Hello, Alexey V Bugrov !

Это не так. Применять его можно если есть ~30-50% запаса по коду/скорости. С применением ассемблерных вставок и того меньше.

С уважением, Дима Орлов.

Привет Alexey!

Friday September 05 2003 00:35, Alexey V Bugrov wrote to Alexander Torres:

SZ>>>> на PIC16C74 провести - несколько расширить функциональность. AB>>> Хм. Hу я, например, неоднократно здесь повторял, что C _не для AB>>> 16-х пиков_. Применять его можно только если не интересует AB>>> результат и требуется сделать что-то очень быстро. AB>

AT>> Чепуху ты говорил, я не вижу оверхеда больше 10-15%, все остальное AT>> - или руки или глюкавые ломанные версии. Кстати авторы Хайтеча

AB> До 30% в отдельных случаях.

Hу это "очень отдельные случаи".

AB> Зависит от специфики задачи,

Конечно, например если оснвная часть это метематические расчеты, то и 30% может быть легко.

AB> т.е. от исходника. Большинство же типовых задач класса PIC16 на AB> ассемблере пишется ничуть не медленее, чем на С.

Hа порядок медленее. Особенно когда программа зависит от железа, и в ходе экспериментов пирходится все менять (и то и другое), чеем я к примеру вчера целый день занимался.

AB> Так зачем переплачивать? (с) AB>

AT>> неоднократно повторяли, что взломанные версии могут вообще AT>> неправильный код генерить. (это не значит, конечно, что абсолютно все AT>> ломанные работают неправильно :) AB>

AT>> Так что "мораль сей басни такова" - не Си виноват, а конкретные AT>> версии. AB>

AB> Я ни C, ни хайтек ни в чем не обвиняю. Более того, можно сказать им AB> большой спасибо за то что смогли реализовать хоть какой-то компилятор на AB> эту платформу, причем действительно хороший компилятор. Hо он никогда не AB> станет сопоставимым по оверхеду с более правильными платформами.

Я не понимаю что такое "правильная платформа" или "неправильная платформа". Если мне нужен контроллер с внешней шиной - я беру один тип, если мне нужно что-то другое - я беру другой тип.

Один, из 51-х - 87LPC769, к примеру имеет все что нужно на борту - и АЦП, и ЦАП, и УАРТ, поэтому и стоит там где без него не обойтись, но к сожалению в нем мало памяти и он дорого стоит. Другой - PIC16F819, имеет 10бит ADC и 10 бит PWM (вместо ЦАП), но увы - не имеет УАРТа, поэтому стоит там где УАРТ не нужен (хотя сегодня мы кое-что придумали).

Третий - ST7Lite - вообще ничего толком не имеет, АЦП есть и ШИМ, и на том спасибо, зато стоит копейки.

К сожалению, для моих нынешних конкретных задач идеального контролера нет вообще, поэтому приходится выбирать для каждого проекта свой, (хотя наиболее полно удовлетворяет 73-й пик, но не всем), поэтому не надо говорить о "правильных" или "неправильных" платформах.

AB>

AB> WBR, AB> AVB AB>

AB> ICQ# 43835774 AB> mailto: avb<at>dialup.etr.ru AB> -+- AVB AB> + Origin: Punks not DEAD! (2:5029/32)

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

formatting link
,
formatting link
,ftp://altor.sytes.net

Hi Vladimir, hope you are having a nice day!

04 Сен 03, Vladimir Chekin wrote to Alexey V Bugrov:

SZ>>> Взял HT-PIC, начитавшись в этой эхе славословий, какой это SZ>>> замечательный компилятор, и как здорово он код оптимизирует... AB>> Хм. Hу я, например, неоднократно здесь повторял, что C _не для AB>> 16-х пиков_. Применять его можно только если не интересует AB>> результат и требуется сделать что-то очень быстро.

VC> Алексей, Вы же грамотный человек, зачем разводит новый флейм почём VC> зря по аналогии с тредом "begin". У автора вопроса что-то явно не так. VC> См. мой ответ ему.

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

WBR, AVB

ICQ# 43835774 mailto: avb<at>dialup.etr.ru

Hello, Alexey V Bugrov !

По сравнению с чем? С использованием ассемблера - однозначно лучшая для очень широкого класса задач. Мои, к примеру, таковы, что влазят в подходящий по периферии кристалл, будучи написанными на С, причем часто еще и место остается.

Так что мне за дело до оптимальности и полнофункциональности? Или без развитой адресации, полноценного стека etc на ассемблере писать легче, чем имея все это? Также сложнее, как и на С.

А какой ты имел в виду?

С уважением, Дима Орлов.

Hi, All!

Я смотрю, тут из моего частного вопроса о качестве работы одного из компиляторов, к тому же уже решенного, флейм разгорается asm vs C. Так я за C. Единственно - за "правильный" С. За правильно работающий и правильно документированный. Я много писал на асме, на многих платформах. Последней каплей было 120К (это не объем исходника, это объем скомпилированной программы! :-) для С166. И с тех пор завязал - только С. Программы для uC становятся все сложнее и объемнее, а никто из нас не становится моложе, и, с возрастом как-то все больше напрягает держать в памяти (своей, а не uC :-) все эти переменные, банки, назначения регистров, параметры функций... Хочется поручить это кому-нибудь другому, пусть даже это будет компилятор. Опять же, третье тысячелетие на дворе, и, по соотношению цена MIPSа или килобайта микроконтроллера - цена рабочего времени разработчика, Си выигрывает все больше и больше.

Примите уверения в совершеннейшем к Вам почтении

Hi!

"Dmitry Orlov" сообщил в новостях следующее:

то

Точно! Заработало! Проблема оказалась в ключике -O, коий у меня отсутствовал. В MPLAB он почему-то назван "assembler optimisation", я и не включал, к чему, думаю, она мне, ежели ассемблера в тексте и нет почти... А описание ключей самого HT-PIC я как-то пропустил :-) Спасибо за совет. Размер кода разом уменьшился более чем в полтора раза, уже вполне можно жить. И действительно, насколько я могу судить, теперь код стал вполне приличный.

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

Примите уверения в совершеннейшем к Вам почтении

Fri Sep 05 2003 02:03, Sergey Zabelin wrote to Vladimir Chekin:

SZ> asm("clrf status"); SZ> прокатывает, а SZ> asm("clrf ccpr1l"); SZ> или SZ> asm("clrf STATUS"); SZ> -нет. Почему?

попробуй asm(" clrf _CCPR1L ");

Здраствуйте Dima,

*05.09.03* *0:29:00* Вы писали в *RU.EMBEDDED* сообщение к *Alexey V Bugrov* о *"Про HT-PIC"*.

DO> За бесплатный в ваших условиях компилятор?

А разве demo-версия не бесплатна в любых условиях? Для коммерческих разработок они ее вроде использовать разрешают, только если эти разработки не связаны с жизнеобеспечением людей. Или я ошибаюсь?

С уважением, Den

Hello, Den Y. Borisov !

Понятия не имею. Я считаю, что надо в любом случае пользоваться полной. Если есть возможность - купив, если нет - пиратской, благо она доступна.

С уважением, Дима Орлов.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required