Батенька, вы слово "оптимизация" слышали? Это я про скорость работы пустых циклов.... В приличных домах пустые циклы вообще из кода выбрасывают просто на этапе компиляции Я бы рекомендовал поглядеть, какой код таки был сгенерён в итоге, я как-то раз наступил на эти грабли, тщетно пытась найти ничего не делающие пустые циклы в асм-листинге...

Хех... про пустые циклы. Мне как-то позвонили из одной фирмы с требованиями увеличить объем памяти на чипе в три раза. Думаю, что даже ежу понятно, что это означает выпуск нового процессора нехилого размера (ибо память - довольно немелкий объем на матрице занимает).
Я поехал к ним, смотреть их софт. Выяснилось, что они не используют оптимизатор в принципе. На вопрос "почему?", они ответили, что включение оптимизации полностью убивает весь функционал. Стали разбираться... Так вот, у них все тайминги (хз как это по-русски будет) были основаны на циклах ожидания! Пустых, есс-но. Оптимизатор их выкидывал к чертям (и правильно делал, нефиг автомобильный софт писать таким макаром).
Я им предложил два варианта - либо они переписывают весь свой софт с использованием RTI (Real-Time Interrupt - прерывание от системы реального времени), либо я могу заставить оптимизатор не выкидывать пустые циклы с помощью волшебного слова volatile. Они решили, что второй вариант им больше подходит и я три дня с ними проходил по всей программе, пока она не заработала. Тайминги, конечно, ушли, но они их потом подгоняли эмпирическим путем...
После чего, я поставил у себя в башке жирный крест на всех машинах, в которые пойдет этот софт (не спрашивайте каких, я не могу сказать).

Кстати а действительно что делать еси на чипе "часового" интерапта совсем нет да и "внешних" всего 4 и все используются ?

На обоих системах при тестировании цикл остался и работал. Ватком по умолчанию не выкидывает циклы, С#, видимо, тоже (посмотреть ассемблерный код не могу, могу максимум взглянуть на CLR, т.к. С# - интерпретируемый язык). На современных компьютерах пустые циклы не применяют, т.к. есть возможность, как подметил WxVorlks, решить проблему, обратившись к системе (к слову, timing переводится на русский как задержка). На некоторых более старых компах без пустого цикла было не обойтись, т.к. в них не было таймера. В моем же случае пустой цикл тестировал, насколько быстро будет работать часто повторяющийся код, содержащий, по сути, всего три распространенных команды (инкремент, проверку и условный переход). Как и следовало ожидать, чуда не произошло и интерпретируемый код работает медленнее, хотя и шустро. Примерно с такой же скоростью выполнялся этот цикл в ассемблерной реализации на P2 и первых целеронах. Можно было бы усложнить тест, введя в цикл работу, например, с матрицами, но это дольше и делать лень. Кстати, вспомнил еще один перл от господина из Майкрософт Пресс: оказывается, CLR работает быстрее, т.к. в нем не используются регистры! Все данные, для которых исторически использовалась регистровая память, CLR запихивает в стэк. Кто-нибудь помнит хотя бы один х86 процессор, на котором обращение к регистрам занимало больше времени (тактов), чем обращения к стэку? В свое время Ватком как раз славился тем, что использовал регистры где только возможно, даже при вызове ф-ций и передаче в них параметров. Думаю, еще немного, и Майкрософт пресс выпустит книжку, в которой нам на полном серьезе расскажут, что ассемблера вообще никогда не существовало.

То есть, операционки на чипе нет... Цикл и state machine. Или, для извращенцев - если очень надо замерить какой-то отрезок времени, то берется какой-нибудь коммуникационный интерфейс, типа I2C, гонится в Loopback. Время передачи известно И поллинг бита состояния, есс-но. Или DMA гонять с заданным количеством данных. Что, естественно, приведет к повышенному потреблению энергии.
Или, что самое простое - цикл с переменной, определенной, как volatile - оптимизатор ее не тронет, ибо посчитает, что она меняется где-то в недоступных его пониманию местах.



PinkPa

Это когда операционка есть, тогда легко А когда ее нет, то сам себе RTI организовываешь. Иногда приходится прилично извращаться, см выше.

Я неправильно выразился, под системой подразумевался компьютер в целом, и можно без софта. Ведь сейчас практически в каждой системе есть что-то, похожее на таймер. И если нет операционки, повесить свой собственный обработчик не представляет большого труда. Хуже, когда на уровне железяки нет ни таймера, ни часов, и вообще нет ничего, кроме тактового генератора и данных о скорости исполнения тех или иных команд чипом. Решить проблему, в том числе и проблему реализации софтверных "виртуальных часов" возможна, но эта реализация, как мне кажется, будет громоздкой и не особо надежной. А просто отсчитать нужное время, зная скорость ТГ, ИМХО, можно чем угодно, хоть тем же пустым циклом.

Тут ты прав В таком случае основная заморочка возникает, когда чип может исполнять несколько команд одновременно, как, например, ADI SHARC 2106x или, что еще хуже, параллельное исполнение + SIMD, как в ADI Hammerhead. Я уже молчу о случае распараллеливания + pipeline, как в TI C67xx (вот где задница полная).
Для таких случаев, приходится писать программный таймер на ассемблере и не давать возможности оптимизатору применить распараллеливание инструкций.

Воркс, я валялся примерно полчаса на диване от смеху --- насчёт пустых циклов. Ну блин... во народ... Я всегда к авто относился с недоверием, а теперь и подавно... Уж лучше пешком.

Но, надо отдать должное, что тот же Джордейн, рассказывая о том, как программировать на низком уровне контроллер НГМД, писал что-то вроде

Тебе смешно, а у меня волосы дыбом встали. Я бы понял, если б это был какой-то не mission critical софт, но в машинах...
Кстати, в некоторых типах софта просто запрещено использовать оптимизацию. Где-то в DOD-MIL-178B такое прописано для авионики.

запрещено использовать оптимизацию в компиляторе. Оптимизацию программы программистом использовать надо всегда. Но для этого нужен толковый программист. "а где-ж его взять" ©

Логично. А что, распараллеливание не может быть запрещено какой-то одной командой (т.е. останавливаем все параллельные процессы, отсчитываем N тактов, снова продолжаем)? Второй момент: если чип работает в параллельном режиме, можно, по идее, явно выделить второе ядро на таймер. Или скорость исполнения будет плавать в зависимости от загрузки первого ядра? И еще один вопрос: оптимизатор, о котором ты говоришь - железный, в чипе, или это компонент транслятора, который занимается перекомпоновкой кода для увеличения производительности?