Вече дъвкахме тая тема, но спред мен не стигнахме до нищо конкретно. Става въпрос за АРМ. Може да кълве байтови данни, но иска да са подравнени. Та дотук е ясно следното:

При структури, подравняването е важно. Особенно където има намесени протоколи.

Но да видим какво става при работа с данни.

1. Например статични променливи в рама. Да сравним следното:

for(a=0;a<5;a++) при 8 и 32 битов размер на "а". За по сигурно предполагаме че е глобална променлива (да не може компилатора да я нахака в регистър). Ще има ли разлика във бързодействието/големината на кода.

Или пък в нещо от сорта на:

var1 = var[a], където а е 8 или 32 бита. Ще има ли разлика ако индексираме с 8 битова променлива, сравнено с "нормална" 32 битова?

2. А когато говорим за автоматични променливи (такива във стека)?

3. Какво става с битовите променливи? Това което знам аз е - с битови полета е бавно и отнема доста място като код. Най-бързо май е директно ползване на цял байт (а дали не трябва да е направо 32 бита променлива - егати разхищението). Освен това битовите полета винаги са ми изглеждали крайно нечетливи във формата си на структура - където по просто и прегледно е: boolean bFlag = 1;

Въобще ,като има човек на разположение 1 мегабайт, не му пука особенно за такива неща. Ама като се вземе някое недоносче със само 16К и се почне да се работи според препоръките на компилатора (да се ползва 32 бита винаги когато е възможно) и изведнъж се оказва, че това дето пика го прави във 2К, АРМ му трябват 8К.
И после програмирането ми започва да следва Windows идеологията - защо трябва да се мъчим да пишем оптимизиран софтуер, като можем да ъпгрейднем машината?

Ами ARM CPU работи само с регистър-регистър операции . Така че в един момент всяка променлива няма как да не се появи в някой 32 битов регистър. Типът на данните ще ти позволи да си спестиш място, няма смисъл да слагаш нещо което ще се събере в 16 бита в 32 битова променлива.

ARM е като повечето RISC процесори - данните трябва да са подравнени до техния размер. Байт може да е на всеки адрес, 16-бит - само на четен адрес, 32-бит на кратен на 4. Някои инструкции позволяват изключение от това правило, примерно ако на LDR се даде неподравнен поинтер, данните се въртят на дясно...



Ако сам си пишеш асемблера - няма причина да има разлика... На теория операциите за четене/запис от паметта адресират 32 бита и това че вземаш само 8 или 16 от тях - не влияе на бързодействието и големината на кода. Аритметичните операции, обаче винаги са 32-бит и поради това някои "глупави" компилатори добавят код за кастинг до 8, 16 бит. Всъщност това е проблем който се поражда от калинг-конвенцията (която е станртизирана от АРМ). Ако първия параметър на една функция е с размер байт, то той се предава по младшите 8 бита на R0, като не е казано какво съдържат осталите 24 бита. Така че за да няма инфекции, компилаторите първо изчистват старшите 24 бита (въпреки че те може да са си били чистички...)
В крайна сметка проблемът е само при параметри на функции и тагава за да няма овърхед понякога е желателно да се ползва int.
Иначе за променливи в паметта - "размерът няма значение" (почти)



Размерът също няма значение за бързодействието и кода, но байт променлива ще хаби 4 байта от стека, освен ако компилаторът не се светне да пакетира няколко байт променливи в един word.


Това си зависи само от компилатора. Правилото е същото като за други променливи - в паметта може да се записва на адрес подравнен според размера на променливата. Това че някои компилатори за по-лесно закръглят всичко до 32 си е техен проблем, а не на процесора. Да се закръгля има полза само ако трябва да се заредят няколко променливи от паметта с една инструкция, но аз поне досега не съв видял компилатор който използва подобни оптимизации...


хм... това не е задължително... Пак ще повторя, ARM e RISC и инструкциите които работят с паметта не правят нищо друго, а инструкциите които правят някакви операции не могат да работят с паметта. И тъй като инструкциите за работа с паметта има 8/16 и 32 бит варианти (без multiple инстр.) => размера няма значение. Малко нарастване заради подравняването може да има, ама от 2к -> 8к говорим за съвсем различен проблем...
Да се работи с 32 бита е желателно, когато става дума за параметри на функции (те така или иначи се предават като 32-бит) или за регистрови променливи (които също така или иначе са 32-бит). За променливи в памета е препоръчително да ползваш толкова бита, колкото ти трябват.

Да разбирам ли че всичко де що е в стека е подравнено на 32 бита?

И че няма смисъл да правя 8/16 битови променливи, освен ако не са глобални или статични?

Не не са подравнени към 32 бита.
Ако декларираш 8 битова локална променлива тя може да бъде на всеки адрес.
Ето един пример:


Компилирано с GCC 3.3.1 горното дава следния код(само същественната част):

Съвсем се обърках.

Излиза че няма никакво значение, как са ми дефинирани променливите. Защо тогава в IAR пише че е пожелателно използването на 32 битови променливи, а за цикли било задължително.

И аз го четох това но пробвах че става цикъл и с char. И аз не разбрах какво имат пред вид.

В известна степен е желателно да ползваш 32-бит, просто за да си сигурен че компилатора няма да се олее и да сложи излишен код. Проблемът е че всякаква аритметика се прави на базата на 32-битови регистри, т.е. няма инкремент/декремент на байт, събиране изваждане и т.н. Така ако имаш "i++" и i е int -> знаеш че това се компилира до 1 инструкция (ако е регистрова променлива). Но ако i е байт, тогава след 32-битово добавяне на 1, трябва да маскираш резултата за да си остане в младшите 8 бита на регистъра, а старшите 24 да са нула. Така вместо една стават 2 инструкции (някои даже го правят с 3).
Ако това е променлива в паметта - изчистването на старшите битове не е необходимо. Освен ако след инкремента същата променлива не се сравнява или пък примерно се ползва като индекс на масив. Тъй като индекси могат да бъдат само 32-битови регистри, се налага да им изчистиш старшите 24 бита ако регистъра е съдържал байт променлива.
Когато пиша на асемблер, аз тия неща ги съобразявам и много рядко наистина се налага да слагам допълнителни инструкции - просто щото знам кога какво имам. Но компилаторите не винаги преценяват кога кастинга се налага и кога не... и за да си вържат гащите почти винаги добавят код, който за нас може да изглежда излишен.
Разбира се, ако един компилатор е добър, той ще види когато имаш фиксиран цикъл примерно от 1 до 10 и ще си го направи добре, независимо дали си обявил int или char...

Е, да не забравяме и бързодействието, което при деклариране на 32 битова променлива (зависи от професора), е в пъти по-голямо.

Ами рецептата се очертава по следния начин:

1. За масиви се ползва типа на данните какъвто си е.

2. Параметри на функции - ако не са много (а те стандартно не са) - 32 битови.

3. За цикли, индексиране и пр. - 32 битови променливи.

Излиза че вместо това:



e по добре да се запише нещо от сорта:



И още нещо. Вярна ли е мойта подредба на типа на декларираните променливи според бързодействието им (големината на генерирания код)?

1. Тип register
2. Тип static (global)
3. Тип auto

В общия случай подредбата ми изглежда вярна. Но бързодействието зависи и от типа на променливата (char, int, int32....) и на какъв проц върви, както и от оптимизацията на компилатора. Ако на един компилатор за арм му кажеш 4е искаш char и искаш да ти го оптимизира за памет, то вероятно той ще се опита да събере колкото може char-ове в 32бита (зависи от режима на арма - ARM или THUMB), което довежда до допълнителни инструкции за маскиране на битовете, което пък намалява бързодействието.
За да си сигурен, че няма да се пробва да оптимизира нещо, декларираш променливата колкото ти е регистъра.