Вообще, это мой интерес.
Вопрос — как писать, сверху-вниз или слева-направо напрямую относится к психологии восприятия человеком, к работе ума. Тут не все так просто, не только вопрос удобства.

Логическая аргументация такова:
Ход вычислений — сверху вниз. И когда мы располагаем их слева-направо, это осложняет нам восприятие хода вычислений, так как приходится постоянно «переключаться» от сверху-вниз к слева-направо. Это может быть аргументированно там где требуется и общепринято, например при вычислении выражений, но если особой ДОСТАТОЧНОЙ на то необходимости не имеется, лучше этого избегать.

Это «удобно» до той поры, когда ты «в теме», пока тебе заранее известно что происходит в данном фрагменте текста программы. Но как только ты утеряешь это представление, и тебе надлежит РАЗБИРАТЬСЯ (вот в чем разница), подобная запись немного, но осложняет восприятие. Является маленьким препятствием, местом преткновения.
Вплоть до того что я иногда на автомате enter'ом возвращаю сложные строки обратно к представлению в столбец.

Ну и последняя аргументация. Если бежать и создавать к каждой строке комментарии отдельным столбцом, то подобные строки слишком широки и не дают нормально написать комментарии. К тому же, если будет столбец сплошных строк-комментариев, он «маскирует» такую длинную строку.

Так что… любой «выверт» имеет свою цену… :)

согласен, но способ запуска cp/m еще тот. Меня интересовал путный ассемблер и отладчик.

Ты неправ, интересного там очень много, но слишком всё самобытно сделано…

9 авторов всего

shinilb0g Вы Мастер Загадок!

ты моего кода не видел(:

;-----------------output sprite
outspr:
 ld (backsp+1),sp
 ld sp,hl

n=0
 dup 4

 dup 8
 ld de,(sq+n),bc,(sq+2+n)

 dup 2
 dup 8
 push bc,de
edup

 ld hl,0-16*6
 add hl,sp
 ld sp,hl

edup

n=n+4
edup
;-------------------8 линий дубль 2
 ld hl,$7E0
 add hl,sp
 ld sp,hl

edup


backsp:ld sp,0
 ret

добавлю ещё такую фишку, подсмотренную в коде у Грачёва — переменные компилятора:

x=#e0
	dup 16
		_poke sinpage_start+2,x
x=x+1
	edup

kowalski, Следите за нашим журналом!
В следующем выпуске!
Только у нас!
Всего неделя!
По одной в руки!

кстати-кстати. сложные места лучше описать в каменте — что именно делается.

это популярно скорее всего на комодоре. Видел я подобный код распаковки LZ4. пришлось просить помощи разработчика, код просто собирался неправильно.

Кстати, еще одно правило: не пишите бгомерзкий код на Alasm.

Интересная фишка, реализованная во многих ассемблерах для 6502 — безымянные метки. То есть просто :, а переходить к ним можно по :- или :+. Если надо через одну-две-три — можно менять количество минусов и плюсов. Это очень удобная альтернатива нашим привычным $+N для коротких прыжков типа обхода одной-двух команд, позволяет легко вставлять команды и не думать об их размере. Почему-то в ассемблерах для Z80 я подобную возможность не встречал.

интрига-интрига: дядя Леша против дядьки Леши: кто кого?

Кстати о птичках:
«Let's Start Publishing Usable Assembly Language Code»

-for whom how
— MGIMO fininshed?
= ask!

high или [ есть не во всех ассемблерах.

в курсе. мало интересного там.

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

Суров! Там кстати INC HL тоже не был нужен; INC L вполне прокатил бы.

Но меня заинтересовало другое. Умножение. У тебя что, тоже есть такая дрянь раскрянченая? Или ты вообще?

И, в любом случае, было бы здорово, если бы ты поделился, даже не самими процедурами своими, но примерно порядком — сколько, как ты считаешь, должно занимать знаковое умножение 8*8->8 и 8*8->16?

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

MULTI   LD   H,MULTAB/512
        ADD  HL,HL
        LD   C,(HL)
        INC  HL
        LD   B,(HL)

это нормально? Это я так понимаю всё ради компилятора не способного дать возможность построить таблицу чисел не подряд байтик за байтиком, а +256. И самое главное проводятся тесты, да ещё и плакать начинаем, что лишние 512 байт памяти в дырки ноликов превратились. А тестировать надо только оптимизированный код, вот такой:

MULTI   LD   H,HIGH(MULTAB)
        LD   C,(HL)
        INC  H
        LD   B,(HL)
...
        ALIGN 256
MULTAB
DEFW_XX MUL0
DEFW__X MUL10
DEFW__X MUL11
DEFW___ MUL120
DEFW___ MUL121
DEFW___ MUL122
DEFW___ MUL123
DEFW___ MUL124
DEFW___ MUL125
DEFW___ MUL126
DEFW___ MUL127
DEFW___ NEG128
DEFW___ NEG127
DEFW___ NEG126
DEFW___ NEG125
DEFW___ NEG124
DEFW___ NEG123
DEFW___ NEG122
DEFW___ NEG121
DEFW___ NEG120
DEFW_SX NEG11
DEFW_SX NEG10
DEFW_SX NEG09
DEFW_SX NEG08
DEFW_SX NEG07
DEFW_SX NEG06
DEFW_SX NEG05
DEFW_SX NEG04
DEFW_SX NEG03
DEFW_SX NEG02
DEFW_SX NEG01
DEFW___ NEG009
DEFW___ NEG008
DEFW___ NEG007
DEFW___ NEG006
DEFW___ NEG005
DEFW___ NEG004
DEFW___ NEG003
DEFW___ NEG002
DEFW___ NEG001

Вот это читаемо LD H,HIGH(MULTAB), а так тестируют только мудаки LD H,MULTAB/512, тратящие место и главное такты на ограниченность компилятора. Слово мудаки я использовал только по отношению к тому кто его написал.