Интересная фишка, реализованная во многих ассемблерах для 6502 — безымянные метки. То есть просто :, а переходить к ним можно по :- или :+. Если надо через одну-две-три — можно менять количество минусов и плюсов. Это очень удобная альтернатива нашим привычным $+N для коротких прыжков типа обхода одной-двух команд, позволяет легко вставлять команды и не думать об их размере. Почему-то в ассемблерах для Z80 я подобную возможность не встречал.
Писал в строку, пишу и буду писать, и в лицо всех знавал своею пылкостью молодецкой, кто мне будет говорить, что так не надо! И вообще, дядь вов, банальные вещи тулишь!
Суров! Там кстати INC HL тоже не был нужен; INC L вполне прокатил бы.
Но меня заинтересовало другое. Умножение. У тебя что, тоже есть такая дрянь раскрянченая? Или ты вообще?
И, в любом случае, было бы здорово, если бы ты поделился, даже не самими процедурами своими, но примерно порядком — сколько, как ты считаешь, должно занимать знаковое умножение 8*8->8 и 8*8->16?
Ах учись читать .?. Значит когда мы изучаем скорость исполнения умножателе-делителей, то позволять себе тестировать не оптимизированный код типа вот такого:
это нормально? Это я так понимаю всё ради компилятора не способного дать возможность построить таблицу чисел не подряд байтик за байтиком, а +256. И самое главное проводятся тесты, да ещё и плакать начинаем, что лишние 512 байт памяти в дырки ноликов превратились. А тестировать надо только оптимизированный код, вот такой:
Вот это читаемо LD H,HIGH(MULTAB), а так тестируют только мудаки LD H,MULTAB/512, тратящие место и главное такты на ограниченность компилятора. Слово мудаки я использовал только по отношению к тому кто его написал.
У меня было смешнее даже. Я впервые увидел их в исходниках биперных движков Shiru, и долго психовал, зачем он это наворотил там. А потом, в процессе работы над Rain, мне пришлось в какой-то момент разложить внутренний цикл биперного движка и там было такое кол-во самомодифицирующего кода, что мне вначале думалось что я повешусь. Именно в этот момент до меня дошло зачем нужны метки с точечками, просто реально спасло там. Поэтому, не очень даже любя их, знаю что вещь иногда совершенно незаменимая.
Неистово плюсую. Дядя Вова, вот очень бы хотелось код взаимодействия с зифой в отдельный модуль, например!
Глядишь, поборол бы наконец лень и написал себе синхрилку папки с PC, а то слот SD скоро в ноль сотрётся ;)
Ага, есть такое дело. Но мне вот как-то сразу они зашли, и потребность прыгнуть выше головы не деморализует обычно ) Скорее, воспринимаю как намёк на то, что, возможно, надо бы для себя чуток по-другому реструктурировать данные или иначе разбить на процедуры.
Я иногда использую локальные метки и они, кстати, периодически незаменимы (в макросах).
Но у меня как-то мышление неправильно под них выстраивается, и я начинаю психовать, когда пытаюсь писать с ними систематически. Особенно, видимо, мешает как раз их локальность, т.к. номерки скачут через другие метки, а локальные — не могут и меня это как-то очень деморализует.
Это ты про 3.1 «приемлемо только по началу — одноразовое исполнение, но что делать потом?
с кучей ссылок на ссылки и данными оттуда, которые ссылаются на данные»? Ну да, ссылок больше. Но есть одно достоинство — ты не путаешь метки с данными. Пример из моего кода:
Видишь? Мне не нравится писать ld (trb_play+1),hl, потому что я начал рефактор, добавил команду и получил чудесные глюки.
Да, это больше меток и труда. Но это реально лучше код.
do_some_stuff
ld a, b
or a: jr z, .leave
.loop
add hl, hl
djnz .loop
.leave
dec hl
ret
do_other_stuff
ld b, a
.loop
sbc hl, de
djnz .loop
ret
Код, само собой, от балды и смысла не несёт, оптимизировать не надо )
Штука в том, что метки с точкой «видны» только внутри блока, до следующей «обыкновенной» метки. Внутри второй процедуры я спокойно могу использовать имя .loop повторно, и ничего мне за это не будет )
Однако к такой метке можно при желании доступиться и извне, указав полный путь типа jp do_some_stuff.leave.
Т. е. такая себе более удобная / приятная для понимания альтернатива вот этим вот всем 1b / 2f.
Кстати, еще одно правило: не пишите бгомерзкий код на Alasm.
«Let's Start Publishing Usable Assembly Language Code»
— MGIMO fininshed?
= ask!
Но меня заинтересовало другое. Умножение. У тебя что, тоже есть такая дрянь раскрянченая? Или ты вообще?
И, в любом случае, было бы здорово, если бы ты поделился, даже не самими процедурами своими, но примерно порядком — сколько, как ты считаешь, должно занимать знаковое умножение 8*8->8 и 8*8->16?
это нормально? Это я так понимаю всё ради компилятора не способного дать возможность построить таблицу чисел не подряд байтик за байтиком, а +256. И самое главное проводятся тесты, да ещё и плакать начинаем, что лишние 512 байт памяти в дырки ноликов превратились. А тестировать надо только оптимизированный код, вот такой:
Вот это читаемо LD H,HIGH(MULTAB), а так тестируют только мудаки LD H,MULTAB/512, тратящие место и главное такты на ограниченность компилятора. Слово мудаки я использовал только по отношению к тому кто его написал.
Глядишь, поборол бы наконец лень и написал себе синхрилку папки с PC, а то слот SD скоро в ноль сотрётся ;)
Но у меня как-то мышление неправильно под них выстраивается, и я начинаю психовать, когда пытаюсь писать с ними систематически. Особенно, видимо, мешает как раз их локальность, т.к. номерки скачут через другие метки, а локальные — не могут и меня это как-то очень деморализует.
Люди. Складывайте библиотеки в модули. Это реально упрощает жизнь.
с кучей ссылок на ссылки и данными оттуда, которые ссылаются на данные»? Ну да, ссылок больше. Но есть одно достоинство — ты не путаешь метки с данными. Пример из моего кода:
Видишь? Мне не нравится писать ld (trb_play+1),hl, потому что я начал рефактор, добавил команду и получил чудесные глюки.
Да, это больше меток и труда. Но это реально лучше код.
Код, само собой, от балды и смысла не несёт, оптимизировать не надо )
Штука в том, что метки с точкой «видны» только внутри блока, до следующей «обыкновенной» метки. Внутри второй процедуры я спокойно могу использовать имя .loop повторно, и ничего мне за это не будет )
Однако к такой метке можно при желании доступиться и извне, указав полный путь типа jp do_some_stuff.leave.
Т. е. такая себе более удобная / приятная для понимания альтернатива вот этим вот всем 1b / 2f.