ЭТЮДЫ

[Destr]

Понадобилось знаковое 8*8=16. Взял для начала "классику"

Скрытый текст

MULS	; HL=H*E (+-)
	LD L,0			; 2b, 7t	\
	LD D,L			; 1b, 4t	 |
	LD A,H			; 1b, 4t	 |
	XOR E			; 1b, 4t	 |
	EXA			; 1b, 4t	 |
	LD A,H			; 1b, 4t	 |
	NEG			; 2b, 8t	  >  = 20b, 75t
	JP M,$+4		; 3b, 10t	 |
	LD H,A			; 1b, 4t	 |
	LD A,E			; 1b, 4t	 |
	NEG			; 2b, 8t	 |
	JP M,$+4		; 3b, 10t	 |
	LD E,A			; 1b, 4t	/
	DUP 8
		ADD HL,HL	; 1b, 11t	\
		JP NC,$+4	; 3b, 10t	  > = 40b, 256t
		ADD HL,DE	; 1b, 11t	/
	EDUP
	EXA			; 1b, 4t	\
	JP P,$+7		; 3b, 10t	 |
	EX DE,HL		; 1b, 4t	  > = 9b, 47t
	LD L,H			; 1b, 4t	 |
	SBC HL,DE		; 2b, 15t	 |
	RET			; 1b, 10t	/

[свернуть]

Итого: 67 байт, 378 тактов

Где-то на форуме я уже кидал клич как её ускорить, но ничего путного не вышло.
Казалось-бы раз знаковые биты предварительно обнуляются то достаточно семи DUP вместо восьми, но оказалось что это не так,
ибо -128 (#80) после NEG становится +128 (те-же #80), т.е. всё-таки НАДО ОБРАБАТЫВАТЬ ВСЕ 8 БИТ.
А ускорить всё-таки хотелось... И в результате-таки получилось

Скрытый текст

MULS	;[ HL=H*E (+-)
	LD A,H			; 1b, 4t	\
	XOR E			; 1b, 4t	 |
	EXA			; 1b, 4t	 |
	XOR A			; 1b, 4t	 |
	LD L,A			; 1b, 4t	 |
	LD D,A			; 1b, 4t	  > = 17b, 64t
	SUB H			; 1b, 4t	 |
	JP M,$+4		; 3b, 10t	 |
	LD H,A			; 1b, 4t	 |
	XOR A			; 1b, 4t	 |
	SUB E			; 1b, 4t	 |
	JP M,$+4		; 3b, 10t	 |
	LD E,A			; 1b, 4t	/
	DUP 8
		ADD HL,HL	; 1b, 11t 	\
		JP NC,$+4	; 3b, 10t  	| = 40b, 256t
		ADD HL,DE	; 1b, 11t 	/
	EDUP
	EXA			; 1b, 4t	\
	JP P,$+7		; 3b, 10t	 |
	EX DE,HL		; 1b, 4t	  > = 9b, 47t
	LD L,H			; 1b, 4t	 |
	SBC HL,DE		; 2b, 15t	 |
	RET			; 1b, 10t	/

[свернуть]

Итого: 66 байт, 367 тактов

Ускорение за счёт замены JP на JR, и JP P, на RET P возможно, но количество тактов перестанет быть константой, так что это опционально...
P.S. Обе процедуры дают правильный (одинаковый) результат на тестовой проверке которая перемножала весь диапазон H (0..255) на весь Е (0..255).
Всё сошлось.

[Advertiser]

[Shiny]

как насчет умножения с использованием таблицы квадратов?
https://map.grauw.nl/sources/external/z80bits.html

[Destr]

как насчет умножения с использованием таблицы квадратов?
https://map.grauw.nl/sources/external/z80bits.html

Ну таблицы - это другая история, тут речь именно об умножении "в столбик".
Ты про Square Table 8-bit * 8-bit Signed что-ли?
Вроде она и так заявлена как знаковая (хотя там что-то пишут про потерю точности)

[krt17]

Гоба на соседнем ресурсе поднял очень актуальную и нетривиальную проблему сравнения 2 знаковых 8 битных числа. Собственно надо сообразить максимально компактно следующее
if x>y then x=-x
сходу получилось

	org	0x8000
	ld	c, -0x70	;y
	ld	e, 0x11	;x
	call	comp
; x in A
	jr	$
comp
	ld	a, c
	add	a,0x80
	ld	c, a
	ld	a, e
	add	a,0x80
	cp	c
	ld	a, e
	ret	c
	ret	z
	cpl
	inc	a
	ret

Но есть не покидающее чувство что можно красиво заюзать мистический P/V или S флаги.

[ivagor]

Например так

SignedComp:
;Input:
;A=X
;C=Y
;Output:
;if X<=Y THEN A=X
;if X>Y THEN A=-X
		cp c
		ret z
		jp po,$+5
		ret p
		db 0FEh		;cp ..
		ret m
		neg
		ret

и не портит С (Y)

[krt17]

Красавчик, ivagor лучший!

[krt17]

недавно столкнулся с необходимостью лока, это когда процедура запрещает повторный вызов самой себя или работу с областью памяти. например в прерывании.
я не знаю как данная задача решается на современном железе но на z80 не придумал ничего лучше inc (rp)

			inc	(ix+stHead.lock)
			ld	b, (ix+stHead.lock)
			dec	b
			jr	z, .cont
.exit			
			dec	(ix+stHead.lock)
			ret
.cont

можно заменить на djnz по обстоятельствам
хотел понять есть ли варианты лока?

[Reobne]

А вдруг будет целый шторм запусков, и inc-ов будет выполнено постоянно больше dec-ов?
Может изначально в ячейке ложить единицу, и перед декрементом её проверять?

			ld	b, (ix+stHead.lock)
			dec	b
			ret nz
			dec	(ix+stHead.lock)
			jr	z, .cont
.exit			
			inc	(ix+stHead.lock)
			ret
.

Теперь вроде, даже в сильный шторм, проскакивать выполнение должно.

[krt17]

А вдруг будет целый шторм запусков, и inc-ов будет выполнено постоянно больше dec-ов?
Может изначально в ячейке ложить единицу, и перед декрементом её проверять?

			ld	b, (ix+stHead.lock)
			dec	b
			ret nz
			dec	(ix+stHead.lock)
			jr	z, .cont
.exit			
			inc	(ix+stHead.lock)
			ret
.

Теперь вроде, даже в сильный шторм, проскакивать выполнение должно.

а теперь посмотри что будет если прерывание придет между 1 и 2 командой. в моем случае сколько бы не было инков на континуе перейдет только первый

- - - Добавлено - - -

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

- - - Добавлено - - -

хотя еще прикинул, а потом еще, ну для устройств далеких от спектрума и со специфическим софтом наверное и надо доп проверку, у нас не подобрал условий для переполнения 255, даже больше 3 не могу придумать.

[Dart Alver]

недавно столкнулся с необходимостью лока, это когда процедура запрещает повторный вызов самой себя или работу с областью памяти.

Для однократного вызова процедуры можно глушить ретурном.

proc_  push af
       ld a,#C9   ; 'ret'
       ld (proc_),a    
       pop af          ; 7 байтов с push , 5 без них
       ...

      
proc_  ld hl,proc_   ; или если например hl не жалко
       ld (hl),#C9
       ...

или можно встроить семафор в тело программы

proc_  ld a,1
       or a
       ret z         ; jr z, exit
       xor a
       ld (proc_+1),a
       ...

- - - Добавлено - - -

Ещё пришло на ум . Если однократных вызовов надо много, то можно сделать процедуру залочивания.

       ; процедура лока
locker_   ex (sp),hl  ; после первого применения поставит заглушку 'ret'
          push hl     ; по вызывавшему адресу
          dec hl
          dec hl
          dec hl
          ld (hl),#C9
          pop hl
          ex (sp),hl
         ret
         
        ; применение
        
proc_   call locker_  ; 3 байта на вызов
        ...