PC-01 Lviv

Практически нереально.
Во-первых, современные процессоры за одну операцию обрабатывают 32/64 бита, Вам нужно писать дополнительную логику для "длинных операций".
Во-вторых, современные процессоры имеют огромное количество дополнительных команд, каждую из которых нужно реализировать дополнительной процедурой (например, умножение)
В-третьих, регистры сильно эволюционировали со времен 8080
В-четвертых, практически любая скомпилированная программа будет использовать функции операционной системы.
В-пятых, адрессация памяти абсолютно разная.
...
В-четыреста пятьдесят восьмых, короче невозможно.

у Дельфи плохой оптимизатор, поэтому "peephole" (щелевого просмотрщика) с шаблонами будет достаточно (для компилятора с Си такой подход уже не пройдёт). Однако в любом случае - писать ассемблер сразу - было бы быстрее и менее трудозатратно.

to Zelya: там речь шла не про эмулятор х86 на 580-м (который теоретически возможен, хотя бы по академическим соображениям, а практически в 48кб оперативки скорее всего не влезет).

Может я конечно неправильно выразился...
Попробую так:
Вы видели мой проект!? И поняли его смысл. Я надеюсь..
И вот чтобы не писать собственноручно компилятор с «нуля», мне в голову пришла вот такая идея: допустим вот часть кода программы использующая процедуру-команду КР580, такую как MviA(0); OUT_($0C2);

Program wrem;
BEGIN
For b:=1 to 244 do Begin
c:=c+2;
MviA(0);
OUT_($0C2);
qq(c,b);
end;

допустим это уже готовая программа для компиляции в коды КР-580.

Вот скомпилированные её код в Дельфи:


Хотелось бы написать программу(компилятор) использующую этот код как проекцию для создания кода КР-580 где вызовы подпрограмм такие как Call Mvi, Call Out_ будут земенены полностью идентичным командам CALL OUT, все остальные аналогичными командами КР-580. Адресация по памяти будет тоже «подточена» под КР-580. Разрядность регистров?... — для начала не будет типов данных кроме BYTE, WORD. Вызовы процедур типа Call @InitExe естественно будут удалены. Другие команды интлела, которые возможно появяться при компиляции, которых нет в КР-580 могут быть заменены на несколько аналогичных КР-580. Ну ведь если я вручную компилирую программу в КР-580 дак получится ведь такой же код как на скриншоте!? (ну почти такой же) только в командах КР-580?! Так ведь?...
Вообщем получится ли у меня использовать такую «проекцию»?

================================================
P/S Свой модуль я уже переделал на (под) эмулятор Marat_best.
Доволен как слон. Заработала игрушка “Пьяный лифтер»... баловался функциями ПЗУ и т.д., попробую еще хотя бы одну игрушку дизпаскалить для примера и скоро выложу. Если это хоть кому-то кроме меня интересно. Вот, пора уже и компилятор писать.. А четкого плана _КАК_ еще нет
================================================

sadfsdfsdaf Эмулятор x86 на 8080 - это отдельная и очень интересная тема. Но все-таки мне кажется, что автор желает перепарсить х86 байткод в 8080 байткод.

sas9568635
Совсем-совсем простые программки, если пополам 50% автоматически, 50% допиливать ручками, то, может, и получится. Смотрите, в Вашем коде:
Первое: компилятор все равно использует 32-битные рагистры, и переполнение и знак Вы никак не проверите, кроме моторошной работы с кучей if.
Второе: mov edx, [c+$4] - для 8080 это огромнаякуча операций, которая кроме того "поломает" значение регистра А, т.е. его надо сохранять и доставать.
И еще несколько "убойных" мест, только в простейшем цикле. Вы не упрощаете задачу, а серьезно затрудняете.

ОК! Уже согласен! Спасибо за внимание!
Я просто думал что так будет возможно проще... чем расшифровка исходника (хоть и проверенного предварительно Дельфи)... все его Begin end else if... а также переменных и прочее...

А будут ли у кого рекомендации про анализу исходника перед компилированием?...
Может литература подскажите какую (ТОЛКОВУЮ!!!) по этому вопросу... или еще чего нить... исходники писанные на Дельфи (Паскале) компиляторов Паскаля в КР580?....

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

01.12.2012 Изменения и нововведения:
Модуль очень сильно изменен благодаря исходникам MARAT_BEST`а.
Спасибо ему за выложеные исходники. Сейчас все что можно работает
и причем работает исправно Модуль вполне доведен до логического
завершения. Ознакомьтесь с файлами-примерами,я думаю все там будет понятно.

для компиляции зачемто еще нужен файлик qtintf.dll

Хм... ну держи раз нужен...
файл находился в C:\Windows\system32\

спасибо .... да нет мне не нужен ....
не понятно зачем он тебе ?

А нафига ее юзать-то? Вы ж под Линукс портировать не будите. Убейте все формочки с буквой Q впереди, почистите uses - и будет все очень здорово. А то доставлять никому не нужные (в том числе и Вам) dll-ки - это не наш метод .

????!!!??!?!?!?! - В каком смысле "зачем он мне" ?..
Я до этого момента не знал об этом файле вообще ничего...
Раз ТЫ написал, что "нужен файл" то я подумал может у тебя Дельфи его требует...

??? Граждене, я вообще не пойму о чём речь?... Вы мне внятно можете объяснить..
а то я не знаю плакать мне или смеятся...

подсказка вот тут почистите uses
у вас гдето (возможно при компиляции библиотеки, в uses попала ссылка на данный DLL)

    uses
  Classes, Forms, Windows, SysUtils, Graphics, IdGlobal,  QDialogs,
  UnitMain in 'UnitMain.pas',
  EkranLVUnit in 'EkranLVUnit.pas' {MainFormEmu},
  RegViewLVUnit in 'RegViewLVUnit.pas' {RegViewForm},
  I8080 in 'I8080.pas',
  I8080proc in 'I8080proc.pas',
  ExecuteLV in 'ExecuteLV.pas',
  Delays in 'Delays.pas',
  SAStypes in '..\..\Poject\UNITdelphi\SAStypes.PAS',
  SASFiles in '..\..\Poject\UNITdelphi\SASFiles.pas',
  SASstring in '..\..\Poject\UNITdelphi\SASstring.PAS',
  Memory_ in 'Memory_.pas',
  FormatLVT in 'FormatLVT.pas',
  FormatE3 in 'FormatE3.pas',
  FormatEMU in 'FormatEMU.pas',
  SASChar in '..\..\Poject\UNITdelphi\SASChar.PAS',
  FormatSAV in 'FormatSAV.pas';

В УПОР НЕВИЖУ !
Я так подозреваю может из-за примениея типа данных INT64.