такая вот либа появилась

source file: timer.fts
\ 10.11.2010 ~mOleg
\ Copyright [C] 2010 mOleg mOlegg@ya.ru
\ измерение временных промежутков

  branch/ for-next.fts
  math/   asmadd.fts
  memory/ double.fts
  vocs/   unit.fts

Unit: TIMER

\ поместить на вершину стека данных значение сетчика команд процессора RDTC
F: READ ( --> ud )
        [ 0x89 B, 0x45 B, 0xFC B, 0x0F B, 0x31 B, 0x89 B,
          0x55 B, 0xF8 B, 0x8D B, 0x6D B, 0xF8 B, 0x87 B,
          0x45 B, 0x00 B, ] ;F

\ измерить длительность исполнения слова, представленного своим xt
: (measure) ( xt --> dt ) TIMER READ D>R EXECUTE TIMER READ DR> D- ;

\ определить количество тиков, необходимое для выполнения xt
\ исполняется два раза минимум! Результат усредняется.
: msr ( xt # --> n )
      NOW DUP >L (measure)
       SINCE L@ (measure) D+ D2/
      TILL LDROP ;

  0`0 DVALUE nooptime  \ время выполнения пустой операции
  0`0 DVALUE 1ms_time  \ приблизительное количество тиков в одной милисекунде

\ определить количество тиков в одной милисекунде (приблизительно)
F: calibrate ( --> )
            <: ;> 100000 msr TO nooptime
            <: 256 PAUSE ;> 3 msr nooptime D-
            D2/ D2/ D2/ D2/ D2/ D2/ D2/ D2/ TO 1ms_time
            ;F

  0`0 DVALUE distant

\ сохранить текущий момент времени в переменную distant
F: initial ( --> ) TIMER READ TO distant ;F

\ определить, сколько милисекунд прошло с момента вызова initial
F: interval ( --> ms ) TIMER READ distant D- 1ms_time D>S DS/ D>S ;F

EndUnit

RDTSC??? О боже! А если частота проца меняется динамически, как там будет со временем?

Есть такое дело.
Только вы можете предложить механизм, позволяющий ловить короткие таймауты (длительностьюя в несколько сотен-тысяч тактов процессора?)
RDTC хорош тем, что для получения информации не надо обращаться к АПИ, которое довольно медлительно. Пока что предлагается периодически калибровать счетчик.

А часто бывает что время и не нужно, а нужно знать сколько тиков например при сравнении производительности разных алгоритмов.

Не могу, с АПИ действительно дела плохи.
Неужели нужно выдерживать очень малый интервал при общении с железом?

Железо разное бывает. Дискету надо ждать единицы секунд, винчестер десятки миллисекунд, а бывают случаи, когда обращения должны быть рассчитаны с точностью до микросекунд (программирование flash-ПЗУ, например),

Эти вопросы решаются кардинально, разработкой соответствующего интерфейса датчика (или самого датчика). К чему насиловать компьютер, который при всем желании не прыгнет выше головы? PC - не реалтаймовая платформа.

Извините, что вмешиваюсь.
В свое время использовал прерывание int 70 часов реального времени.
Настроено по умолчанию на 1024 прерываний в секунду,
но есть делители.
Включается и програмируется елементарно.
была одна тонкость, не указанная тогда в докуметации,
в конце обработки прерывания, надо обязательно
прочитать регистр статуса в smos,
иначе следущее прерывание не произойдет.

Харошие тогда были времена!
А сейчас юниксёвый nanosleep имеет дискрет времени 1/1000 сек.
Хотя есть и реалтаймовые расширения. Но не везде.

В смос есть регистр, в котором находится делитель частоты,
ее можно разогнать до очень больших значений, гораздо больших 1000.

Является ли этот таймер официальным пользовательским ресурсом, который обязан поддерживаться операционными системами?

До XP поддерживался в DOS сессии корректно. С XP начал "кто в лес кто по дрова" . Чаще всего в сторону увеличения скорости того, что клацает. После некоторого бодания с ним в одном проекте под программатор выделили отдельную машину с совсем честным DOS-ом.

Вот-вот. В итоге устройство начинает работать с конкретно выделенным для него компьютером, хотя можно было сопоставимые усилия потратить на усовершенствование датчика. На сегодняшний день МК, опрашивающий датчик с соблюдением всех временных интервалов, ведущий журнал, и при необходимости выдающий результаты по запросу PC через переходник USB-UART, является одним из простейших вариантов.

Да, но это нужно еще сделать железо и написать две программы. Я лучше вместо этой работы напишу что-то более полезное...

ЗЫ. Это был программатор KeeLoq-микросхем который должен вести счетчик (не повторять сериальник) и при этом что-то туда еще добавлять. Программа была написана и работает с 1998 и до сих пор. Программирование ведут полные юзеры .

вероятнее всего да, не знаю. int 70 так же используется будильником реального
времени, и возможно так же вызывается в случае разрядки батареи смос.
В регистре статуса как раз указан источник прерывания.
В дос работает, в linux вероятно можно. Если есть низкоуровневые
функции api для установке векторов прерываний, тк в защищенном
режиме это проблематично.
Наверняка можно написать драйвер устройства.