Интересная фишка, реализованная во многих ассемблерах для 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 скоро в ноль сотрётся ;)
Ага, есть такое дело. Но мне вот как-то сразу они зашли, и потребность прыгнуть выше головы не деморализует обычно ) Скорее, воспринимаю как намёк на то, что, возможно, надо бы для себя чуток по-другому реструктурировать данные или иначе разбить на процедуры.
В следующем выпуске!
Только у нас!
Всего неделя!
По одной в руки!
Кстати, еще одно правило: не пишите бгомерзкий код на 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 скоро в ноль сотрётся ;)