[Эмуляция процессора] Несколько вопросов

Я в своей жизни не написал ни одного эмулятора процессоров и ни одной виртуальной машины, но даже я вижу в твоих рассуждениях явные нестыковки.

Если кратко, то... Тебе нужно на Си (Си++) написать эмулятор процессора нужной архитектуры и откомпилировать полученную программу под архитектуру базовой системы. Тогда все взлетит. А так, как хочешь сделать ты, у тебя дальше идей ничего не сдвинется.

3. К примеру, нужно запустить бинарник от другой архитектуры. Локальная копия системы с другой архитектуры есть.
Можно ли сделать чтоб некий конвертатор прошелся по бинарнику, сконвертировал его и библиотеки, которые он хочет так, чтобы он мог спокойно запуститься на этой архитектуре, причем почти без потерь в скорости работы (при соблюдении условия 1)?

Ты когда-нибудь встречал что-нибудь похожее? Думаю, нет. Не догадываешься, почему?

Ты когда-нибудь встречал что-нибудь похожее?

ЕМНИП, при смене проца в какой-то iШтучки (iPhone вроде), был такой то-ли эмулятор то-ли перекодировщик. Но производительность падала на 60%.

Не догадываешься, почему?

Сложно реализовать? Не нужно?

Тебе нужно на Си (Си++) написать эмулятор процессора нужной архитектуры и откомпилировать полученную программу под архитектуру базовой системы. Тогда все взлетит.

К примеру, имеется некоторая прога, умножает 2 числа, результаты не вводятся и не выводятся (для простоты), компилируем ее под arm (к примеру.)
Прогоняем ее через конвертировщик из пункта 3, на выходе получаем proga_convert и набор библиотек (lib_some1_convert, ...), взятые от arm системы, но переконвертированые. По идее, бинарник без проблем может запустится.

ЕМНИП, при смене проца в какой-то iШтучки (iPhone вроде), был такой то-ли эмулятор то-ли перекодировщик. Но производительность падала на 60%.

Для винмобайл такое уже написано:

http://forum.pdaprime.ru/index.php?/topic/49391-heroes-of-might-and-magic-1-wm/

:)

1.,2. Обычно все регистры просто хранят в памяти, а не в реальных регистрах. Так как есть еще и регистры слова состояния и прочие служебные регистры.

3. Выполняемая программа может генерировать код на лету, и никаким транслятором этого не учесть.

4. Доки по Qemu описывают все хорошо. Исходники там тоже не плохи, особенно если в качестве эмулируемой платформы выбирвать RISC, типа ARM.

5. В простом случае да, в более сложных (Qemu) используется динамическая трансляция и выбирать ничего не нужно, просто генерируется код, который исполняется до ближайшей инструкции перехода, где управление опять получает эмулятор.

Обычно все регистры просто хранят в памяти

Но ведь скорость падает.

Доки по Qemu описывают все хорошо.

Спасибо, возьму на заметку.

5.

Но Qemu ведь эмулирует целую ОС, то-есть есть там будет крутиться много-чего лишнего: ядро, свои драйвера. Или я ошибаюсь?

Для винмобайл такое уже написано:

Там даже исходники открыты. Посмотрим.

Qemu эмулирует именно железо, а не ОС!

По поводу winmobile и героев:

Рекомпилятор - закрытый проект. Состоит из нескольких утилит, основная из них - по оригинальному win32 EXE файлу производится генерация С++ кода, реализующего соответствующий функционал. Данный код затем компилируется, линкуется с обслуживающими библиотеками, и на выходе получаем модуль для заданной платформы. Не обязательно Windows Mobile, это может быть и iPhone и любая другая 32-битная платформа с компилятором С++. На данный момент работа оттестирована на двух платформах - настольной Windows и Windows Mobile.

Вы в это верите? Это же бред чистой воды. Я бы лично не рискнул даже пытаться запустить таких «героев» на своем телефоне.

http://forum.pdaprime.ru/index.php?/topic/49407-heroes12-и-другие-программы-н...

Они открыли код. Сам код тут: https://rs558dt.rapidshare.com/#!download|558l3|323793425|mamaich_convert_tools_and_heroes1-2_src.rar|11498|R~7545F0070583297727B8997728197086|0|0

Но ведь скорость падает.

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

ЕМНИП, при смене проца в какой-то iШтучки (iPhone вроде), был такой то-ли эмулятор то-ли перекодировщик

Вообще это было в десктопных маках и дважды. Первый - при переходе с m68k на PPC Второй - при переходе на x86 (Rosetta)

встречал, транслятор времен macosx 10 :) позволял на интеле пускать ppc бинарники

А вы уверены, что это был не эмулятор? Если оттранслированный файл перенести на другой мак, то он там запустится без этого транслятора? Задача, в общем виде, представляется мне не разрешимой.

Код еще не смотрел, но что-то меня смущают папки libemu и mxx-emu...

Этаким образом «оттранслированные» игрушки еще с денди, я часто встречал в сети и даже играл в некоторые. Только о конвертации кода там речи не шло. Просто эмулятор соединяли с образом игры.

Посмотри сам в QEMU, в чем проблема...

typedef struct CPUARMState {
    /* Regs for current mode.  */
    uint32_t regs[16];
    /* Frequently accessed CPSR bits are stored separately for efficiently.
       This contains all the other bits.  Use cpsr_{read,write} to access
       the whole CPSR.  */
    uint32_t uncached_cpsr;
    uint32_t spsr;

    /* Banked registers.  */
    uint32_t banked_spsr[6];
    uint32_t banked_r13[6];
    uint32_t banked_r14[6];

    /* These hold r8-r12.  */
    uint32_t usr_regs[5];
    uint32_t fiq_regs[5];

    /* cpsr flag cache for faster execution */
    uint32_t CF; /* 0 or 1 */
    uint32_t VF; /* V is the bit 31. All other bits are undefined */
    uint32_t NF; /* N is bit 31. All other bits are undefined.  */
    uint32_t ZF; /* Z set if zero.  */
    uint32_t QF; /* 0 or 1 */
    uint32_t GE; /* cpsr[19:16] */
    uint32_t thumb; /* cpsr[5]. 0 = arm mode, 1 = thumb mode. */
    uint32_t condexec_bits; /* IT bits.  cpsr[15:10,26:25].  */

    /* System control coprocessor (cp15) */
    struct {
        uint32_t c0_cpuid;
        uint32_t c0_cachetype;
        uint32_t c0_ccsid[16]; /* Cache size.  */
        uint32_t c0_clid; /* Cache level.  */
        uint32_t c0_cssel; /* Cache size selection.  */
        uint32_t c0_c1[8]; /* Feature registers.  */
        uint32_t c0_c2[8]; /* Instruction set registers.  */
        uint32_t c1_sys; /* System control register.  */
        uint32_t c1_coproc; /* Coprocessor access register.  */
        uint32_t c1_xscaleauxcr; /* XScale auxiliary control register.  */
        uint32_t c2_base0; /* MMU translation table base 0.  */
        uint32_t c2_base1; /* MMU translation table base 1.  */
        uint32_t c2_control; /* MMU translation table base control.  */
        uint32_t c2_mask; /* MMU translation table base selection mask.  */
        uint32_t c2_base_mask; /* MMU translation table base 0 mask. */
        uint32_t c2_data; /* MPU data cachable bits.  */
        uint32_t c2_insn; /* MPU instruction cachable bits.  */
        uint32_t c3; /* MMU domain access control register
                        MPU write buffer control.  */
        uint32_t c5_insn; /* Fault status registers.  */
        uint32_t c5_data;
        uint32_t c6_region[8]; /* MPU base/size registers.  */
        uint32_t c6_insn; /* Fault address registers.  */
        uint32_t c6_data;
        uint32_t c7_par;  /* Translation result. */
        uint32_t c9_insn; /* Cache lockdown registers.  */
        uint32_t c9_data;
        uint32_t c9_pmcr; /* performance monitor control register */
        uint32_t c9_pmcnten; /* perf monitor counter enables */
        uint32_t c9_pmovsr; /* perf monitor overflow status */
        uint32_t c9_pmxevtyper; /* perf monitor event type */
        uint32_t c9_pmuserenr; /* perf monitor user enable */
        uint32_t c9_pminten; /* perf monitor interrupt enables */
        uint32_t c13_fcse; /* FCSE PID.  */
        uint32_t c13_context; /* Context ID.  */
        uint32_t c13_tls1; /* User RW Thread register.  */
        uint32_t c13_tls2; /* User RO Thread register.  */
        uint32_t c13_tls3; /* Privileged Thread register.  */
        uint32_t c15_cpar; /* XScale Coprocessor Access Register */
        uint32_t c15_ticonfig; /* TI925T configuration byte.  */
        uint32_t c15_i_max; /* Maximum D-cache dirty line index.  */
        uint32_t c15_i_min; /* Minimum D-cache dirty line index.  */
        uint32_t c15_threadid; /* TI debugger thread-ID.  */
    } cp15;

    struct {
        uint32_t other_sp;
        uint32_t vecbase;
        uint32_t basepri;
        uint32_t control;
        int current_sp;
        int exception;
        int pending_exception;
    } v7m;

    /* Thumb-2 EE state.  */
    uint32_t teecr;
    uint32_t teehbr;

    /* Internal CPU feature flags.  */
    uint32_t features;

    /* VFP coprocessor state.  */
    struct {
        float64 regs[32];

        uint32_t xregs[16];
        /* We store these fpcsr fields separately for convenience.  */
        int vec_len;
        int vec_stride;

        /* scratch space when Tn are not sufficient.  */
        uint32_t scratch[8];

        /* fp_status is the "normal" fp status. standard_fp_status retains
         * values corresponding to the ARM "Standard FPSCR Value", ie
         * default-NaN, flush-to-zero, round-to-nearest and is used by
         * any operations (generally Neon) which the architecture defines
         * as controlled by the standard FPSCR value rather than the FPSCR.
         *
         * To avoid having to transfer exception bits around, we simply
         * say that the FPSCR cumulative exception flags are the logical
         * OR of the flags in the two fp statuses. This relies on the
         * only thing which needs to read the exception flags being
         * an explicit FPSCR read.
         */
        float_status fp_status;
        float_status standard_fp_status;
    } vfp;
    uint32_t exclusive_addr;
    uint32_t exclusive_val;
    uint32_t exclusive_high;
#if defined(CONFIG_USER_ONLY)
    uint32_t exclusive_test;
    uint32_t exclusive_info;
#endif

    /* iwMMXt coprocessor state.  */
    struct {
        uint64_t regs[16];
        uint64_t val;

        uint32_t cregs[16];
    } iwmmxt;

#if defined(CONFIG_USER_ONLY)
    /* For usermode syscall translation.  */
    int eabi;
#endif

    CPU_COMMON

    /* These fields after the common ones so they are preserved on reset.  */

    /* Coprocessor IO used by peripherals */
    struct {
        ARMReadCPFunc *cp_read;
        ARMWriteCPFunc *cp_write;
        void *opaque;
    } cp[15];
    void *nvic;
    const struct arm_boot_info *boot_info;
} CPUARMState;

1. Регистры хранятся в памяти, за исключением, может быть, аккумулятора.
2. То же самое.
3. В общем случае — нельзя.
4. Доки эмуляторов, может быть.
5. Может простым case-ом, может шитый код с вычисляемым goto использовать.
6. Смотря какого проца. У x86 — в памяти, конечно. Но есть и стековые машины с вшитым в проц стеком.

qemu user emulation + jit

Посмотрел код по диагонали. Довольно любопытно. Не реализвано всего несколько инструкций. Остальные либо транслируются напрямую в ассемблерный код, либо в сишный код. mmx эмулируется через специальную библиотеку. Стек эмулируется полностью, как я понял. Как там устроены регистры, не увидел. Может, не там смотрел.

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

В HPUX при переходе с m68k на PA-RISC тоже можно было на серверах запускать старые программы.

Видел в работе FastISS лет 8 назад. Идея именно такая: взять бинарник программы (без самомодификации - ОС увы) от x86/arm/mips, породить C-код для каждой инструкции и доверить компилятору его прооптимизировать. Как не странно - работал.

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

Ай-ай-ай, стыдно не знать! А еще ЛУНИКСОИД!

P.S. даю подсказку: чем занимался господин Л.Б. Торвальдс в конце 90-х и начале 2000-х ?

Твоя идея аппаратно реализована 10 лет назад в процессорах от Transmeta :-)

1. нет. забудь о регистрах реального процессора. вместо них используй переменные языка, который используешь. 2. см. ответ 1. 3. это что-то из хайнлайна кажется? или азимов? 4. наверняка есть. 5. да. наиболее часто встречающиеся инструкции ставь первыми. по принципу кода морзе. 6. в озу. хотя может быть есть архитектуры, где стек в «проце» (что за слово такое у-щ-ое?)

Ну и где те трансметы? А вот нонче loongson 3b вполне даже смотрится издалека. Как бы только стать (не?)счастливым владельцем оного?

Ну с академической точки зрения решение от трансметы просто бомба. А вот с комерческой они зафейлились на процах по полной. Зато очень много текущих технологий энергосбережения основаны или лицензированы на технологиях трансметы.

Ну с академической точки зрения решение от трансметы просто бомба. А вот с комерческой они зафейлились на процах по полной.

Не знаю почему — не специалист по алгоритмам, но у трансляторов Трансметы очень падала производительность на обработке больших объёмов данных. Например, изображений в Фотошопе. Википедия пишет, что у вышеупомянутой Розетты были схожие проблемы.

Ты когда-нибудь встречал что-нибудь похожее?

Qemu так работает. Эмулятор второго плейстейшона тоже.