Как се обяснява огромната разлика при различните режими на оптимизация между "PRO Edition", "Standard Edition" и "Free Edition".



MPLAB XC Compiler PRO Edition:
Provides powerful code optimization at better than 50% when compared to the free edition, giving the most efficient memory usage .

MPLAB XC Compiler Standard Edition:
Provides a lower cost compiler option with a 20-25% code optimization when compared to the free edition.

MPLAB XC Free Edition:
Unrestricted use—ideal for a low-cost academic or commercial solution.
Allows for all the code optimization and commands of the PRO Edition for 60 days.

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Ето самото описание кое как и евентуално защо

http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/
Optimization of microchip pic xc8 compiler in free and pro mode POSTED ON FRIDAY JANUARY 3RD, 2014 BY RAMIRO

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

За тези които не им се чете ето обяснението накратко: във "Free mode" вмъкват умишлено допълнителни ненужни инструкции и/или бавни цикли. Кода е бавен, яде FLASH памет, понякога и RAM памет.
Предполагам това е обичайна практика при производителите на компилатори.

Това значи ли, че можеш да си ползваш Free версията и като си готов, пускаш във виртуална машина ПРО версията и вадиш релиз.

В типичния случай - да.
В частен случай с който се сблъсках - не.

Зависи колко е умен компилатора + оптимизатора. Пробваш и разбираш.
Нещото което даде проблем при мен беше двоен указател. С включена оптимизация смилаше така кода, че губеше идея какво го карам да прави.
Иначе PIC18F със 128к FLASH спести 20% надолу което е много добър резултат. Понеже опрях в края на паметта и реших да се "възползвам", но не ми се получи, а така или иначе щях да минавам на повече памет и не задълбах особено да преправям кода с двойните указатели. Май имаше още тук там някакви проблемчета, но с дебъгване се откриваха.

Все си мисля, че щом си опрял до 128к с 18-ка - това не е твоят процесор. Не знам какво точно се опитваш да правиш ама по добре сложи поне 24-ка ако трябва да е пик. А защо не и някакъв друг контролер от АРМ семейството.

18-ка и двойни указатели...

Не съм пробвал... той с тия три FSR-а за никъде не е. И друго ми е интересно - в селектора на микрочип не се виждат 18-ки с повече от 128к.

Тъй де. Просто не е за тая работа. Компилатора може и да съчини "нещо", ама като размер код за единица работа ще е абсурдно, сравнено с PIC24 или PIC32. Производителността - пак така.

Оптимизиращите компилатори на микрочип са минали покрай оптимизациите - колкото пъти погледна кво са насътворили и се хващам за главата ... за пример - събиране на 2 32 битови биг ендиан числа през указател - в 8 битовите им процесори е все тая биг или литъл ендиан, да ама не - кода е яко в киреча ... имам в предвид нещо:

uint32_t a;
char *p;
a += (p[0]<<24) + (p[1]<<16) + (p[2]<<8) + p[3];

това очаквам да се компилира без да се генерират шифтвания ... да ама не - дали не отиваха 40-50 инструкции за това та на ...

То и barrel shifter нямат, и какво ли още не.

За подобни неща обикновено си правя макроси, ако не ми харесва какво твори компилатора.

Така де, минал съм на PIC24F, после или PIC32MX или ARM. Само където компилаторите XC18 и XC32 са много бавни. Нещо са ги предобрили.
Това което се търкаля на малкия процесор си работи железно. Ама не се поддава на оптимизиране нещо. Допълнителните екстри са за по-големите процесори.


Ако компилатора+оптимизатора са читави - проблеми никакви.
Например компилатора на CCS включен на максимална оптимизация, а той май си стои така по-подразбиране, двойните указатели ги няма за нищо.
Даже не подозирах, че някой компилатор би имал проблеми с това, но ето, че Microchip имат при определени обстоятелства. Не съм си играл да видя какво го провокира да греши. Възможно е да има нужда от повече RAM или кой знае какво. Обаче в по-тежкия случай без оптимизиране не ги греши.

Мисълта ми беше че дори компилатора да се справя (както безспорно си е и редно), самата архитектура на MCU-то е калава за такива неща и кода ще е крайно неефективен и голям.

По принцип Пиковете са много особенни като архитектура. Говоря за чисто пиковските ядра, не за мипса. Най-вече поради факта, че код и данни на процесора са на тотално различни шини и едното е вързано само на флеша, а другото само на рама. Отделно, че рама се аксесва като вътрешен регистър на процесора. Имат някакви заобиколни методи с които можеш да извличаш данни от флеша, а да търкаляш код в рам, май въобще не може (или поне до преди 2 години не можеше). Като се намеси и външна шина става тотална боза... както и да е.

Така напрактика при пиковете, указател към данни в зависимост дали е във флеш или в рам е тотално различно нещо. И в общия случай не може да се прехвърля от едното към другото свободно/безпроблемно. Указател към указател става двойна оплетвация. Израза (void*) е приключение при пиковете. Индексното адресиране също работи коренно различно в двата случая (флеш/рам). Стека и той е една магия... майко мила. Реално то няма истински стек при малките, а при по-големите е нещо подобно на стек (не говорим за хардуерния, той е съвсем друга бира). Ако сложиш и банкирането на рама при дребните представители, кошмара става пълен.

Масовите компилатори обаче са мислени за нормални процесори с нормален стек и нормално адресно пространство. Компилатора за пика е някакво живо приключение, честно незнам как е направен, това си е изкуство. От там и оптимизациите му са... особенни. При нормалните компилатори ако внимаваш как си пишеш кода, не би трябвало да имаш проблеми и на максимална оптимизация. При пиковете обаче... стават особенни неща Реално за да пише на C човек за пик, би трябвало да владее асемблера му до съвършенство. Като цяло в менюала на компилатора отзад има една глава - изключения от ANSI C. Не е зле да я прегледате.

Предполагам, че всичко това е избягнато при мипса, там би трябвало нещата да са ОК. Незнам gcc-то как се справя с Мипс, но на Куртекс, при включена на максимум оптимизация, кода се сгъва точно между 30 и 50%.



Ми не аз не съм виждал подобни простотии в друг комерсиален компилатор. Или те ограничават по дата, или по големина на кода или ти спират оптимизациите. Ама да ти увеличават нарочно кода... ми се струва меко казано нахално. Аз лично XC8 никога не съм ползвал, карам си на един античен MPLABC18. Там такива свинщини не съм забелязвал.

При MIPS-а (PIC32 демек) имаш няколко виртуални адресни пространства, сочещи към едно и също, но по различен начин - еданото се кешира, другото не, третото - нам кво си и т.н. Но с всяко едно от тях се работи свободно и еднакво. Можеш да пускаш програма от флаша или от RAM-а, флаша се чете точно както и RAM-а - просто имаш указател и толкоз - в зависимост от това кое адресно пространство сочи указателя, хардуера си прави нужното за да ти даде това, дето се намира на съответния адрес. Стека е софтуерен. Има 2 набора регистри, едните запазени за ISR-та с висок приоритет, тоест там не запазва нищо в стека освен указател за връщане. Има доста неща. Общо взето поне на мен ми харесва като архитектура. Работи се общо взето лесно и логично. Дразни ме че няма с повече от 512к флаш и 128к RAM. Дразни ме и че някои периферии, налични например в PIC24 ги няма при PIC32MX - например така и не направиха ADC-то да е с няколко Sample-and-hold модула. Асемблера ми е ужас (то и на другите PIC-ове пак така) - явно асемблера на x86 и 8051 ме е повредил безвъзвратно. Но пък се справям достатъчно добре оптимизирайки кода, гледайки какви ги твори компилатора в асемблерския листинг. С това се свиква лесно и малко по малко трупаш база данни как да си пишеш C програмата, така че да става читаво от гледна точка на компилатора.

Върху PIC24 нямам задълбочени наблюдения как е организирано адресирането, паметите и т.н. Само с един DSPIC30 съм си имал работа до сега. Но пък доста неща ми харесаха.