Почему компилятор выкидывает цикл?

[Tuborg]

CompileTarget: DOS
Compiler: BC 3
 Есть некая функция реализующая временную задержку в проге, в одном варианте (Вар. I) оно отрабатывает заданные 100 секунд, а в другом (Вар. II) оно вылетает сразу. В чём здесь может быть проблема? Все оптимизации отключены. Может есть какая нибудь спасительная деректива прекомпиляции?
-------------
Вар. I
Timer::TimeDelay(DWord mcs){
  DWord beginTime=0, delta=0;
  beginTime=getTimeValue();
  while(delta<mcs){
    delta=getTimeValue()-beginTime;
    printf("\n");
  }
}

Вар. II
Timer::TimeDelay(DWord mcs){
  DWord beginTime=0, delta=0;
  beginTime=getTimeValue();
  while(delta<mcs){
    delta=getTimeValue()-beginTime;
  }
}

[ixania]

Вопервых поисание getTimeValue() нигде не могу найти, может это чтото твое.
Во вторых в первом варианте printf("\n"); тож обавляет задержку, т.к. вывод на экран требует времени.

[Tuborg]

1. getTimeValue() - моя функция читающая значение счётчика таймера в микросекундах.
2. Вариант с printf("\n") не может выполнятся в 100 раз медленее (100 секунд)

[ixania]

И как ты читаешь с  getTimeValue() в микросекундах, как реализована? т.к time (0) выдает в секундах как я помню.

[Serega]

обьявляй переменные как volatile
getTimeValue это макрос, просто адрес памяти куда дос записывает количество тиков (адрес могу впомнить)
компилятор видит что в куске кода происходит чтение из памяти, но нет записи по этому адресу, поэтому цикл с многократным чтением и оптимизируется, ты глянь что он на асме выдает
volatile указывает компилятору что значение переменной может меняться вне программы (потока)

[ixania]

А чем sleep плох?

[Гром]

volatile - это говорит только то, что значение будет браться из памяти - у Рихтера прочел. А пустой цикл оптимизируется - вовсе не причем там тип макроса ИМХО конечно.
Просто в цикле сделать надо что-то типа простейшей операции. i=i<<1;
и все будет работать.

[ixania]

Timer::TimeDelay(DWord mcs){
     sleep (mcs);  
}

   зачем заново велосипед изобретать?

[Alf]

volatile - это говорит только то, что значение будет браться из памяти - у Рихтера прочел. А пустой цикл оптимизируется - вовсе не причем там тип макроса ИМХО конечно.
Просто в цикле сделать надо что-то типа простейшей операции. i=i<<1;
и все будет работать.

Думаю, что насчет оптимизации ты абсолютно прав. А вот насчет простейшей операции - не уверен.
Был такой случай в практике. В конце 80-х попала в мои руки мини-ЭВМ VAX-11/725 (если кто застал те времена, помнят, что это была надежда Пентагона, очень удачная серия супермини-ЭВМ). Захотелось самому определить ее быстродействие. Для этого написал что-то вроде:

Код:

long k = 0;
for )long i = 0; i < 10000000; i++:
  k = k + 1;

(на самом деле писано это было на FORTRAN77 или на Pascal, но суть не в этом). Запустил, засек время - выполняется около секунды. Ладно, думаю, в принципе возможно. Увеличил предел цикла в 10 раз - то же самое. Еще в 10 раз - то же самое :!:
Я точно знал, что миллиард коротких сложений в секунду агрегат делать не может. Стал разбираться с кодом. Оказалось, что умный компилятор понял, что значение k не используется дальше, и не стал его считать вовсе  
Ладно, решил немного схитрить. Поставил в конце программы печать значения k, чтобы заставить комп его вычислить. Запускаю - то же самое. Лезу в код. Оказалось, что оптимизатор сообразил, что незачем 10000000 раз складывать по единице, и заменил все это на

Код:

k = 10000000

а затем напечатал значение. Аналогичные простейшие уловки тоже не смогли сбить его с толку. Пришлось выдумать выражение посложнее, чтобы он не мог заранее его посчитать на этапе компиляции.
А теперь прикиньте, что с тех пор минуло лет 15, наверное... Думаю, что творцы компиляторов с тех пор вряд ли разучились оптимизировать, тем более такие элементарные вещи. Если значение delta нигде дальше не используется, скорее всего, цикл просто будет выброшен из программы.

[Serega]

Гром, меня не переспоришь
Вот кусок из Страуструпа:
A volatile specifier is a hint to a compiler that an object may change its value in ways not specified by the language so that aggressive optimizations must be avoided. For example, a real time clock might be declared:

extern const volatile clock;

Two successive reads of clock might give different results.