ЭТЮДЫ

[Reobne]

Destr,
На обычном, нетурбированом: грубо 3 500 000/50 = 70 000 тактов/кадр.
Реально - плюс минус немного, в зависимости от клона.
Если прерывания включены, то программа обработки своё тоже отжирает.

Сколько тактов затрачивает процедура, делим на 70 000, получаем сколько кадров она будет работать.

А если нужно во время выполнения знать кадр, то:
1. Включить прерывания и считать.
2. Заранее посчитать сколько тратят процедуры времени, и при вызове суммировать.
3. Заранее примерно посчитать сколько тратят процедуры, суммировать. Когда возможно, включать прерывания, и синхронизировать (например считаем в тысячах тактов, пришло прерывание - в счётчике 72 - плюсуем один кадр, в счётчике 230 - плюсуем 3 кадра. Другой вариант - считаем в 273-шках тактов, при прерывании оругляем до второго байта счётчика, который и будет числом кадров. То есть, если младший байт >128, то старшему +1, и младший в любом случае обнуляем.)
4. Не знаю... Терпеть... Попробовать обойтись без счётчика кадров.

[Destr]

посмотри мультиколор в MQM4, там интересная процедурка определения тактов.

А это что? Игра, дема или ещё что?

а поделить число тактов на число, занимаемое процедурой никак?

Никак. Она может занимать и 10 000 и 100 000 тактов

[Reobne]

Чтобы не отключать прерывания, при использовании стека, можно регенерировать потерянные ячейки, как, например, в Amaurote.

Либо, если известно, что последний POP был POP DE;
если он там не испорчен, если не было EXX, то можно регенерировать из него.

II_Proc: LD (HL_Store+1),HL
  POP HL
  PUSH DE
  LD (RET_Store+1),HL
  LD (SP_Store+1),SP
  LD SP,II_SP
  PUSH AF
  ...
  POP AF
HL_Store:  LD HL,nn
SP_Store:  LD SP,nn
RET_Store: JP nn

Пишу из головы, для идеи, возможны ошибки.

[denpopov]

add a,1

а как повлияет adc a,0 ?

[Destr]

Сравнение двух 16-битных чисел со знаком.
Signed int comparison

; сравнение HL(sgn) и DE(sgn) на выходе флаг C установлен если HL<DE
CMP_HL_DE
        LD A,H            ;4
        XOR D             ;4
        JP P,CHD1         ;10
        LD A,H            ;4
        RLA               ;4
        JP CHD2           ;10
CHD1    SBC HL,DE         ;11
CHD2
; (алгоритм подсказал sam style)

[Sergey]

; сравнение HL(sgn) и DE(sgn) на выходе флаг C установлен если HL<DE...

Гениально. Я, кстати, предполагал, что алгоритм с ветвлениями может быть быстрее.
Получилось быстрее на 27 тактов, короче - на 6 байт

[Destr]

Гениально. Я, кстати, предполагал, что алгоритм с ветвлениями может быть быстрее.
Получилось быстрее на 27 тактов, короче - на 6 байт

Просто ты пошёл по ошибочному пути сравнивая 17 битные числа.
Я на те-же грабли наступил, но по счастью мимо пробегал самстайл и вместе накропали сравнение знаков, ну потом я долизал до теперешнего вида.
Кстати можно ещё сократить/ускорить, но это уже с потерей универсальности (т.е. вызывающая прога должна будет контролить не только С но ещё и P)

Ещё в тему - нахождение средней точки между HL и DE (тоже со знаками)
LD A,H
XOR D
ADD HL,DE
JP P,$+4
CCF
RR H
RR L

[denpopov]

Наберите программку на Си, сгенерьте сырок, а там сравните

[Destr]

Наберите программку на Си, сгенерьте сырок, а там сравните

Так сгенерь да покаж.
(я например не умею)

[Sergey]

Так сгенерь да покаж.
(я например не умею)

Опосля избавления от индексной адресации операндов и повышения наглядности получилось это:

_sgncmp:

;sgncmp.c:3: if (A>B) return 0;
	ld	a,l ; A_low
	sub	a,e ; B_low
	ld	a,h ; A_high
	sbc	a,d ; B_high
	jp	PO, 00109$
	xor	a, #0x80
00109$:
	jp	P,A_меньше_B
	ld	hl,#0x0000  ; A>B
	ret
A_меньше_B: ; A<B
	ld	hl,#0x0001
	ret

В обсчем, SDCC меня тоже уделал!
P.S. Убожество своё потёр нафиг.
P.P.S. Твою процедурку можно убыстрить на целых 2(!) такта, заменив JR на JP.