Closed Volutar closed 5 years ago
Да - слишком мало места под метку. Осмысленно её не назовёшь.
Всё идёт к тому, что надо переделывать дизасм чуть более чем полностью. Таблицей он не вывозит.
Всё идёт к тому, что надо переделывать дизасм чуть более чем полностью. Таблицей он не вывозит.
Зачем переделывать - вон на скрине кладовский. Можно же объединить ячейки в строке и в них метку запиндюрить
Метки отдельной строкой, правую колонку с кодом расширить (она даже близко до края не доходит, при том что скроллера нет). На 4 цифры адреса места под 8 цифры (для 32 разрядных адресов?). Справа дамп, а в нём 50% пустот вокруг чисел и строк - можно красиво уплотнить их и отцентровать строчки (сейчас они справа-сверху), и вместится гораздо больше полезного.
А в чём проблема метку сделать отдельной строкой? Нельзя в таблице объединять несколько данных в строку, типа colspan? В ряде дебагеров, кстати, автоматически просто пустые строки вставляются после ret и jr/jp, как индикаторы конца блока.
открыл, что setSpan всё-таки есть. пока как-то так, ещё без equ А широкое поле адреса сделано для показа сегментов:
открыл, что setSpan всё-таки есть. пока как-то так, ещё без equ
Охренительно же! EQU это другая уже история. И, кстати, нельзя ли локальные метки типа BLABLABLA.blabla как-то парсить в плане того чтобы откусывать переднюю часть (BLABLABLA), и выводить локальную часть? Ведь эти метки в таблице всегда последовательны, и в принципе могут быть схлопнуты.
Откусывать начало до точки можно, это не сложно
Откусывать начало до точки можно, это не сложно
Но там есть нюансы. Если это отсылка через блок без точек - нужно указывать и первую часть. Пример:
Label1
and a
ld b,12
jr z,.l1
ld b,6
.l1 ;Label1.l1
inc a
djnz .l1 ;inside
ret
Label2
and a
ld b,a
jr nz,.l1
inc b
.l1 ;Label2.l1
call Label1.l1 ;outside - если сделать call .l1 то будет бяда.
ret
То есть слева показывать сокращённые, а справа, в самих операторах нельзя сокращать если они отсылаются за пределы нелокальных меточных блоков.
По данному Issue обнаружилась пара побочных эффектов:
по п.2 - скорее, попадает на эту же строку, но не в левый столбец. А т.к все столбцы перекрыты левым, курсор пропадает...
Он попадает именно на N строк выше, в зависимости от того, сколько строк с метками было вставлено на экране ВЫШЕ искомой позиции.
http://volutar.myds.me/xcep-labug.mp4
Это всё из-за десинхронизации счётчика строк визуальных и "логических" из-за вставки этих строк с метками. Инфа 146%.
Кстати при скрулянии вниз он иногда перепрыгивает через меточные строки. Закономерность пока не понял. На видео-иллюстрации это тоже видно.
с первым пунктом разобрался а со вторым придётся переписывать алгоритм поиска адреса на X строк назад, учитывая все дополнительные строки с метками и equ
В дебагере метки вписываются вместо адреса, места там патологически мало. Локальные метки, которые склеиваются с основными, просто не вмещаются:
Можно действовать как в том же дебагере из emuzwin, который выводит метки на отдельных строках, и не затирает ими адреса (что тоже хорошо): В нём, кстати, метки совмещаются с фактическим адресом, и места для ассемблерной инструкции там даётся с лихвой. В XSpeccy много пустот справа от колонки с кодом и от самой инструкции пикселей 50 просто пустоты. Очень много пустот и в окне дампа, но это другая история.
Плюс, решение этого issue сделает более возможным использование меток со сдвигом через EQU $+n. А если бы при ховере мышки над словом/меткой/адресом - можно было перепрыгнуть по этому адресу (в окне дебага, или в окне дампа), по выбору из контекстного меню, или зажав Ctrl превращать адрес в прыгабельную ссылку (с возможностью возвращения) - это было бы вообще прекрасно.