Учусь программировать (need help)

[char]

навскидку, как-то так бы накарябал

	ld	hl,buff
	call	space1
;...

;
space1:
	ld	a,h		;a>#20 anyway, not space )))
	ld	d,h
	ld	e,l

lp_spc1:
	ld	c,a		;prev char
	ld	a,(hl)
	ld	(de),a
	inc	hl
	cp	#0a
	ret	z
;	jr	z,clearline

	cp	#20
	jr	nz,go_spc1	;current char not space

	cp	c
	jr	z,lp_spc1	;prev and current char = space, skip one

go_spc1:
	inc	de		;moved ok
	jr	lp_spc1

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

вместо ld a,h, наверное, лучше просто xor a, да и все )))

[char]

вот так, кстати, можно 1 переход (и байт) вырезать

space1:
	ld	b,h		;b>0 anyway )))
	ld	d,h
	ld	e,l

lp_spc1:
	ld	c,b		;prev char -#20
	ld	a,(hl)
	ld	(de),a
	inc	hl
	cp	#0a
	ret	z
;	jr	z,clearline

	sub	#20
	ld	b,a
	or	c
	jr	z,lp_spc1	;prev and current char = space, skip one

	inc	de		;moved ok
	jr	lp_spc1

[char]

и да, для второй адресной пары, обычно лучше брать de, а не bc.

( b используется в djnz, hl -> de используется в ldi/ldir и т.д. )

[Dr.Potapov]

Главное теперь не "подсесть" на помощь зала )) Очень приятно удивлен количеством откликнувшихся и качеством помощи. Спасибо други! )

[drbars]

Главное теперь не "подсесть" на помощь зала )) Очень приятно удивлен количеством откликнувшихся и качеством помощи. Спасибо други! )

Это отличный способ размять мозг

Подсчитал такты, сделал 3 замера. В среднем моя процедура на 300 тактов быстрее работает на коротких массивах. Особенно, если в массиве несколько слов разделены двойными пробелами. Выигрыш видимо получается за счёт LDIR'а.

[Dr.Potapov]

Подсчитал такты, сделал 3 замера. В среднем моя процедура на 300 тактов быстрее работает на коротких массивах. Особенно, если в массиве несколько слов разделены двойными пробелами. Выигрыш видимо получается за счёт LDIR'а.

LDIR штука замечательная ) но у меня нет указателя на конец массива (точнее он уже неверный, после "стрижки" пробелов в массиве "до" и "после" значащей строки), т.е. вот тут "LD BC,END-ARRAY" мне просто в BC впихнуть нечего, если только я не пробегусь отдельным циклом по массиву со счетчиком и не поймаю #0D в конце или в процессе отсечения пробелов "до" и "после" буду модифицировать указатель на длину массива, что сами понимаете лишняя совершенно морока.

Меня больше беспокоит объем кода, так как я не программист и по большей части времени пишу "трактором", особенно когда Мысль ))) При этом задача заключается в том, что бы уместить ядро программы в 8 килобайт (#6000-#7FFF). В ядре сейчас содержится функция возврата указателя на произвольный драйвер (вызов драйвера идет по имени типа "fd","scr32","kbdn","trd" и прочие), + сами драйверы (какие необходимо в текущей сборке ядра). Функцию возврата указателя дергают системные функции (fs, kbd, sc, syscall которые вкомпилены в ядро всегда) которые в свою очередь вызываются уже userapp (которое вообще не знает ни о каких hardware drivers или системных функциях и получает указатель через ту же функцию возврата указателей по имени). Если что, скажу сразу - возврат указателя происходит один раз и запоминается самой userapp (патчатся нули в "LABEL DB #C3,#00,#00") и в дальнейшем вызов происходит обычным "CALL LABEL". И вся эта канитель сейчас уже занимает 1526 байт (3574 с системным шрифтом) из доступных 8192 байт. Т.е. под дальнейшее творчество (переписать драйвер клавиатуры, дописать системные fs и mem, а так же драйвер trd) осталось 4618 байт.

И я полностью согласен с вами ))

Это отличный способ размять мозг

[makbar]

регулярных выражений. Это касается как ассемблера

как интересно, никогда не видел для ассемблера такой библиотеки.

[Barmaley_m]

как интересно, никогда не видел для ассемблера такой библиотеки.

Я тоже не видел. Хотя я этим не интересовался; может быть, такая библиотека и есть.

Но я вел речь не о библиотеке, а об общем методе обработки текста с помощью конечных автоматов. Каждому конечному автомату соответствует некоторый регулярный язык. И наоборот, каждому регулярному языку соответствует некоторый конечный автомат. Таким образом, если задачу обработки текста можно свести к распознаванию регулярного языка - то необходимо сначала формально записать этот язык, а потом найти соответствующий конечный автомат. Реализовав который на каком-нибудь языке программирования (в том числе ассемблере), получим требуемую программу.

Существует множество компиляторов регулярных выражений (т.е. программ, которые находят по заданному регулярному выражению соответствующий конечный автомат). Как правило, они выдают на выходе код на языке Си. Этот код можно скомпилировать в ассемблер Z80 автоматически (компилятором) или вручную. В обоих случаях получится заведомо работающая программа, учитывающая всевозможные "краевые случаи", что экономит программисту время на разработку и отладку.

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

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

[goodboy]

иногда важнее область применения.
возможно готовый ответ (алгоритм) применяется например в адвентюрах
(особенно в тех где распознаются фразы из трёх слов)

[Sergey]

Если нужны процедуры обработки текстовых строк, их есть у меня!
Пример работы на скриншоте: первая строчка - это синтаксис функции, следующая - результат ее выполнения.
Если интересно, постараюсь исходники восстановить.

как интересно, никогда не видел для ассемблера такой библиотеки.

кое-что:
http://zx-pk.ru/threads/21695-sdcc-b...%ba%d0%b8+sdcc