Привет Alex!
08 Jun 06 01:00, Alex Kocharin писал Alex Mogilnikov:AM>> Определить, зависит ли результат от изменения AM>> направления счета, компилятор вполне способен.
AK> Hе всегда. :-)
Хорошо, уточню мысль: ничто не мешает компилятору выявить независимость результата от направления.
AK> int k=0; AK> for (int i=0; i<10; i++) g+=i;
AK> Я думаю, компилятор не оптимизирует это. Хотя надо бы...
gcc4 оптимизировал:
======== test.c ============= int foo(void) { int k = 0; for(int i = 0; i < 10; i++) k += i;
return k; } =============================
======== test.s ============= .file "test.c" .arch avr2 __SREG__ = 0x3f __SP_H__ = 0x3e __SP_L__ = 0x3d __tmp_reg__ = 0 __zero_reg__ = 1 .global __do_copy_data .global __do_clear_bss .text .global foo .type foo, @function foo: /* prologue: frame size=0 */ /* prologue end (size=0) */ ldi r24,lo8(45) ldi r25,hi8(45) /* epilogue: frame size=0 */ ret /* epilogue end (size=1) */ /* function foo size 3 (2) */ .size foo, .-foo /* File "test.c": code 3 = 0x0003 ( 2), prologues 0, epilogues 1 */ =============================
Hичто не совершенно, и совершенству нет предела. :)
Ты обратил внимание, что в прошлом моем примере (с while) оптимизатор не догадался переместить декремент в конец тела, из-за чего появилась "лишняя" инструкция сравнения? Hо уж такие вещи как реверс цикла, раскрутка, strength-reduction (как это по-русски?) современные компиляторы вполне научились применять, поэтому рекомендации из старых книжек, говорящие что один оператор цикла эффективнее другого, потеряли актуальность.
Всего наилучшего, [Team PCAD 2000] Алексей М. ... Посетители должны общаться по сети.