Про HT-PIC

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 - нет, приходится адрес вручную указывать .

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

Reply to
Sergey Zabelin
Loading thread data ...

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

Reply to
Alexey V Bugrov

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

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

Reply to
Dmitry Orlov

Привет 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

Reply to
Alexander Torres

Привет, Alexey!

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

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

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

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

Reply to
Vladimir Chekin

приходится

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

Reply to
Vadim Botygin

Hello, Alexey V Bugrov !

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

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

Reply to
Dima Orlov

Привет 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

Reply to
Alexander Torres

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

Reply to
Alexey V Bugrov

Hello, Alexey V Bugrov !

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

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

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

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

Reply to
Dima Orlov

Hi, All!

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

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

Reply to
Sergey Zabelin

Hi!

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

то

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

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

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

Reply to
Sergey Zabelin

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 ");

Reply to
Vladimir Rasdolin

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

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

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

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

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

Reply to
Den Y. Borisov

Hello, Den Y. Borisov !

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

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

Reply to
Dima Orlov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.