Недосимулятр 8080 со встроенными asm/disasm/debugger

[Shaos]

а как же смотреть регистры и дампить память?...

P.S. gdb наверное всё-таки не для восьмибиток, тем более виртуальных

[Lavr]

Shaos сказал же - легче написать всё сначала, чем разбираться в чужом коде.

Ну я сказал не совсем так

Но сути-то я не испортил!

[bar]

а как же смотреть регистры и дампить память?...

Как это выглядит в протоколе remote-target я не скажу, потому что мне никогда в голову не приходило попробовать приконнектится telnet'ом к удалённому gdb. Но в command-line можно использовать команду info registers или что-нибудь вида "print $rax". А когда мне надо посмотреть дамп памяти, я обычно делаю это командой print с приведениями типов, примерно так: "p/x (*(unsigned*)$rsp)@256". p -- это сокращение команды print, /x говорит о том, что я хочу видеть числа в hex'е, в скобочках стоит чисто C'шное выражение, преобразующее число из $rsp к типу unsigned*, и затем разадресовывающее получившийся адрес, а @256 говорит о том, сколько элементов надо вывести.
Ко всему этому в gdb есть команды stepi и nexti позволяющие трейсить программу по одной инструкции. И, наконец, gdb'шная команда break принимает в качестве аргумента адрес. Чуть не забыл, есть ещё команда disassemble, которая может кусок памяти перевести в ассемблерные мнемоники. То есть в gdb есть всё, чтобы отлаживать голый бинарь без какой-либо отладочной информации.
Не скрою, что gdb весьма неудобен для отладки при отсутствии отладочной информации, если при source-level отладке gdb вполне можно использовать через командную строку, то при "бинарной" отладке уже всё становится существенно хуже.
Но это же нам не очень важно: планов приделывать отладчик с command-line интерфейсом никто не строит. Нужен фронтенд, и есть у меня подозрение, что написать фронтенд к gdb не сильно-то и сложнее, чем непосредственно к симулятору. Но в случае с сорц-левел отладкой, этот фронтенд будет иметь массу вкусностей, типа вывода думпа памяти не в хексах, а примерно в таком виде:

Code: Select all

(struct my_string*){
    {.len = 10, str = "hello"},
    {.len = -1, str = "world"},
    {.len = 1234, str = NULL},
}

И для этого фронтенду вовсе не обязательно понимать, что такое C'шная структура, и каковы особенности вывода на экран значения типа char*, потому что этим всем может заниматься gdb, а фронтенду останется лишь получать готовый результат в текстовом виде.

P.S. gdb наверное всё-таки не для восьмибиток, тем более виртуальных

C восьмибитным AVR он справляется. С виртуальным. С simulavr.

[Shaos]

С авром атмел хорошо поработал для популяризации - тут тебе и gcc, и gdb, но мне пики больше по душе

P.S. Всё-таки симулятор с нуля писать несколько проще будет

[Lavr]

Ввиду того, что я не большой любитель винды, а также в связи с тем, что я устал от постоянных гонок разных производителей юзерских интерфейсов для линуха, предлагаю весь юзер-интерфейс делать самостоятельно - на уровне пикселей.

Ну это как-то уж слишком... слишком колхозно ещё и интерфейсы рисовать...

Так что чтобы иметь поддержанными и линух, и дос, и твою винду номер 98, придётся всё городить самостоятельно...

Ну тогда - чур я поддерживаю ДОС-версию...



Только в чём тогда смысл совместимости? У меня этот Вендоподобный интерфейс
"на уровне пикслей" вообще под QBasic был написан...

[bar]

Есть вроде достаточно стабильный порт GTK+ под винду (см. GIMP, который им пользуется и который кстати и подарил миру GTK+), однако:

You will need the GLib, cairo, Pango, ATK, gdk-pixbuf and GTK+ developer packages to build software against GTK+. To run GTK+ programs you will also need the gettext-runtime, fontconfig, freetype, expat, libpng and zlib packages.
....
The current GTK+ stack uses APIs that are available only on Windows 2000 or later. Long obsolete versions of GTK+ did run on Win9x and NT 4, too.

Так что чтобы иметь поддержанными и линух, и дос, и твою винду номер 98, придётся всё городить самостоятельно...

Только сейчас обратил внимание. По-ходу дела gtk забросил поддержку win9x в версии 2.6. Почему-то думал что они сделали это с переходом на 3.x, и искренне верил, что можно собрать всё на gtk+-2.24, который вероятно повторит историю gtk+-1.2, то есть будет поддерживаться майнтейнерами дистрибутивов долгие годы.
Экая факамаза...