ДизАссемблер под 89

Konstantin, ты ещё здесь сидишь?

Четверг Июнь 22 2006 17:25, Konstantin Granitsa wrote to George Shepelev:

KG>>> B) Hекоторые отладчики после такой фразы откажутся работать GS>> Hе пользуйся кривыми отладчиками! KG> Посоветуй прямой...

И посоветовал бы, если бы пользовался. Hо я обхожусь. В моих программах основные "заморочки" со специфичной аппаратурой, а её отладчики не умеют эмулировать...

KG>>> С) она более тормазнутая по времени, GS>> Обоснуй. KG> Элементарно Ватсон!!! KG> Из тобой сказанного: GS>> в _каждом_ таком месте экономится код на загрузку GS>> регистров. А увеличивается код всего в одном месте - подпрограмме GS>> обработки шитого кода. KG> следует: Что экономим на одной операции MOV DPTR, #msgA00

Использование шитого кода не ограничивается простейшим примером с asciiz строкой, таким образом можно инициализировать несколько регистров или даже выполнять программу (как это делается форт-машиной).

KG> а добавляем минимум 3 : (Ты не забыл что там числа 16 битные)

"Там", это где? 51-е семейство - восьмибитное.

KG> 1) Первоначальная загрузка в DPTR (заменяет сэкономленную) KG> 2) Инкремент KG> 3) Выгрузка обратно... KG> Вывод она больше - жрёт больше памяти и дольше выполняется :)

Ещё раз напоминаю, одна-единственная подпрограмма может обработать вызовы из множества мест. Если таких мест достаточно много, можно получить выигрыш памяти. Для наглядности покажу, как мог бы обрабатываться упомянутый пример (надеюсь, вход "в середину" подпрограммы тебя не смутит), вариант обработки набрал с ходу, может найдётся более оптимальное решение:

printA: CALL print_A print_asciiz: POP TmpH ; сохраняем адрес возврата POP TmpL POP DPH ; значение указателя на очередной байт POP DPL ; шитого кода из стека CLR A MOV A,@A+DPTR ; значение по указателю INC DPTR ; коррекция указателя PUSH DPL ; возвращаем скорректированный указатель на стек PUSH DPH PUSH TmpL ; возвращаем адрес возврата на стек PUSH TmpH JNZ printA RET

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

GS>> Ерунда. В программе могут быть десятки выводов сообщений с GS>> использованием "шитого кода", KG> Во во... и каждая выводится дольше...

Hо только тогда, когда это надо!

KG> а если их много...

То экономится память! А быстродействие остаётся вполне приемлимым, так что проблем не возникает...

GS>> Тот, кто программировать не умеет, тот будет ковыряться со GS>> своими багофичами, а профессионалы знают массу приёмов увеличения GS>> эффективности программ и при необходимости умеет ими GS>> пользоваться. KG> Есть второй вариант - не делать багофичи без особой надобности и потом KG> оптимизировать ничего не придётся :)

О, да! Зачем вообще исправлять ошибки в программах, если их можно сразу написать без ошибок! ;-)))

Георгий

Konstantin, ты ещё здесь сидишь?

Вторник Июнь 27 2006 11:17, George Shepelev wrote to Konstantin Granitsa:

GS> Ещё раз напоминаю, одна-единственная подпрограмма может обработать GS> вызовы из множества мест. Если таких мест достаточно много, можно GS> получить выигрыш памяти. Для наглядности покажу, как мог бы GS> обрабатываться упомянутый пример (надеюсь, вход "в середину" GS> подпрограммы тебя не смутит), вариант обработки набрал с ходу, GS> может найдётся более оптимальное решение:

"И на старуху бывает проруха" (c)

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

printA: CALL print_A print_asciiz: POP DPH ; значение указателя на очередной байт POP DPL ; шитого кода из стека CLR A MOV A,@A+DPTR ; значение по указателю INC DPTR ; коррекция указателя PUSH DPL ; возвращаем скорректированный указатель на стек PUSH DPH JNZ printA RET

А теперь оптимизируем код:

print_asciiz: POP DPH ; значение указателя на очередной байт POP DPL ; шитого кода из стека SJMP get_A

printA: CALL print_A ; в этой подпрограмме не должен модифицироваться ; указатель DPTR get_A: CLR A MOV A,@A+DPTR ; значение по указателю INC DPTR ; коррекция указателя JNZ printA JMP @A+DPTR

Георгий

Приветствую, *George !*

Было это 27 июн 06 11:17, случилось, что _George Shepelev_ писал Konstantin Granitsa

KG>> а добавляем минимум 3 : (Ты не забыл что там числа 16 битные) GS> "Там", это где? 51-е семейство - восьмибитное.

А DPTR в который ты помещаешь номер обрабатываемой ячейки ? :) Или ты забыл что в проге писал?

KG>> 1) Первоначальная загрузка в DPTR (заменяет сэкономленную) KG>> 2) Инкремент KG>> 3) Выгрузка обратно... KG>> Вывод она больше - жрёт больше памяти и дольше выполняется :) GS> Ещё раз напоминаю, одна-единственная подпрограмма может обработать GS> вызовы из множества мест. Если таких мест достаточно много, можно GS> получить выигрыш памяти.

Мда... посмотри письма ранее... *call prints* prints это тоже подпрограмма которая печатает то что было помещено в DPTR заранее... И выигрыша тут нет *!*

Удачи ! Bye, *Konstantin .*

... Кто pано встает, тот pано помpет.

Приветствую, *George !*

Было это 28 июн 06 11:49,

GS> Хотел сделать отдельную подпрограммку, извлекающую очередной байт GS> из шитого кода, потом передумал, чтобы не усложнять логику работы, GS> а операции со стеком убрать забыл. Исправленный вариант:

Большой он у тебя... Мой *первый* вариант меньше... (он был кривой и я его немножко - раза в 2 - усложнил в сторону добавления фич, перевод каретки и т.д...)

PrintS: ; print string @DPTR push acc pr1: clr a movc a,@a+DPTR cjne a,#254,pr2 jmp pr3 pr2: call write inc DPTR jmp pr1 pr3: pop acc ret

write: ; print Char mov sbuf, a jnb ti,$ clr ti ret Удачи ! Bye, *Konstantin .*

... Плачет девочка в банкомате

Konstantin, ты ещё здесь сидишь?

Среда Июнь 28 2006 11:49, George Shepelev wrote to Konstantin Granitsa:

GS> А теперь оптимизируем код: GS> print_asciiz: GS> POP DPH ; значение указателя на очередной байт GS> POP DPL ; шитого кода из стека GS> SJMP get_A GS> printA: GS> CALL print_A ; в этой подпрограмме не должен GS> модифицироваться GS> ; указатель DPTR GS> get_A: GS> CLR A GS> MOV A,@A+DPTR ; значение по указателю GS> INC DPTR ; коррекция указателя GS> JNZ printA GS> JMP @A+DPTR

Теперь сравниваем. Тот вариант, что предложил ты, позволяет укоротить вызываемую подпрограмму всего на 6 байт, требуя 3 лишних байта на каждом вызове. Уже при 3 вызовах вариант с использованием "шитого кода" экономит память, а реально их могут быть десятки...

Георгий

Konstantin,

You wrote to George Shepelev:

GS>> извлекающую очередной байт из шитого кода,

Что такое "шитый код"?

Andrey

Hello Konstantin.

Thu Jun 29 2006 21:23, Konstantin Granitsa wrote to George Shepelev:

KG> PrintS: ; print string @DPTR KG> push acc KG> pr1: KG> clr a KG> movc a,@a+DPTR KG> cjne a,#254,pr2 KG> jmp pr3

Этот jmp лишний, сюда как раз и можно поместить код, следующий за меткой pr3. И метку эту убрать.

KG> pr2: KG> call write KG> inc DPTR KG> jmp pr1 KG> pr3: KG> pop acc KG> ret

Dimmy.

Konstantin, ты ещё здесь сидишь?

Четверг Июнь 29 2006 22:09, Konstantin Granitsa wrote to George Shepelev:

GS>> Ещё раз напоминаю, одна-единственная подпрограмма может GS>> обработать вызовы из множества мест. Если таких мест достаточно GS>> много, можно получить выигрыш памяти. KG> Мда... посмотри письма ранее... *call prints* KG> prints это тоже подпрограмма которая печатает то что было помещено KG> в DPTR заранее... И выигрыша тут нет *!*

Сравнение было в моём письме от 1 июля. Выигрыш вполне заметный.

Георгий