Konstantdeklarerad eller inte brukar inte generera någon skillnad på koden, så länge som kompilatorn vet att värdet är konstant.Nerre skrev:4kTRB skrev:
Just en sån grej som Icecaps optimering av multiplicering med 10 tror jag faktiskt att gcc fixar, MEN koden måste då vara skriven så att 10 är definierad som en konstant.
Kollar man på vad som kommer ut ur GCC eller ARMs kompilator för ARM så löser den alla sådana och mer komplicerade saker.
På ARM7, en booth multiplier, tar en extra cykel för varje byte av 0 eller 0xff i sourcen du skall multiplicera med. Detta jämförs med att lösa det med add, sub, rsb och skiftningar. Sedan väljs det bästa.
På 68k tar varje multiplikation (Om minnet inte sviker mig) 38 cykler + 2 cykler om varje grupp av 01 eller 10 i sourcen. Vilket du som assemebler programmerare måste kunna om du vill slå kompilatorn, dvs, du vill ha talet med flest grupper om 00 eller 11 i sourcen för att spara cykler.
Skrev detta förut, men det verkar relavant här också så:
Detta är min assembler, men en kompilator ger samma resultat:
(multiplikationskonstant och kod efter)
2 add r1, r0, r0
3 add r1, r0, r0 lsl #1
4 mov r1, r0 lsl #2
5 add r1, r0, r0 lsl #2
7 rsb r1, r0, r0 lsl #3
8 mov r1, r0 lsl #3
9 add r1, r0, r0 lsl #3
if (a){
b *= 5;
} else {
b *= 7;
}
movs r0, r0
addne r1,r1,r1 lsl #2
rsbeq r1,r1,r1 lsl #3
rsb står för reverse subtract.
I praktiken, om man inte van och slipad i rätt assemblerdialekt gör kompilatorn ett bättre jobb en "standard" assemblerprogrammerare...
Det vanligaste problemet med C är att man skriver kod som inte tillåter kompilatorn att göra full optimering. Men det är ju ett annat problem, antagligen det största...
