gedankenspiel: Virtuelles system, wie binaries generieren?

rapso

Ich wuerde gerne zum spass ein kleines virtuelles system emulieren, einfach nur eine CPU und vielleicht ca 1MB ram oder so.

doch wie code dafuer generieren? ich hab zwar einige ideen z.b.

ein arm-elf mit gcc compilieren und dann emuliere ich direkt arm -> wie weis geb ich gcc mit wie das memory layout ist? linkerscripts? rechte problem wenn ich deren instructionset nutze?
ein eigener assembler der dann ein binary generiert -> nice zum testen aber damit macht wohl kaum jemand was nuetzliches, zu hardcore
gcc toolchain neu bauen mit eigenem md file fuer meine architektur -> sehr aufwendig, fehleranfaellig und machine descriptions sind nicht gerade mein spezialgebiet.
irgend ein bytecode missbrauchen um code fuer das system zu generieren -> sehr limitiert auf diesen bytecode und ein undokumentiertes system.
eigener compiler -> sehr limitiert in features, sehr zeitaufwendig, die meisten projekte sterben schon beim parsen wenn sie einen compiler machen und das ist garnicht mein target.

habt ihr irgendwelche anderen vorschlaege oder ideen?

gcc für arms gibts natürlich: http://www.gnuarm.com/
ich benutze ihn zwar nicht, aber ganz sicher kann man dem linker sagen, wo er was hinpacken soll (es gibt hunderte, wenn nicht gar tausende arm-basierte systeme, die alle unterschiedlich sind),

*rant*

Ich habe einen Emulator und einen Assembler parallel entwickelt, doch habe ich auch meine komplett eigene Architektur (64-bit CPU & 16 MB RAM plus einen 3-teiligen Chipsatz dafür; der Chip, welcher später die Devices kontrollieren soll, ist noch immer ein Dummy ) implementiert, weshalb gcc sowieso weniger in Frage kam. Einen funktionstüchtigen Assembler hat man relativ schnell und es kann dich niemand daran hindern, zu Testzwecken einige mächtigere Instruktionen und Funktionen einzubauen, solange du den Emulator kontrollierst.

Bisher gibt es exakt 76 wohl definierte Instruktionen für die Architektur (plus eine Instruktion cheat , welche ich zum Testen und Entwickeln brauche. z.B. dumpt mir momentan cheat 61952#d , assembliert zu 00 94 0b 65 61 74 f2 00 , einen bestimmten Speicherbereich ins Host-System fürs Debugging) und das deckt so ziemlich alles ab. Dazu aber habe ich die Sprache dann um eine stetig wachsende Anzahl von Schlüsselwörtern erweitert, welche Struktur in den Quelltext bringen. Inzwischen hat der Assembler also auch Konzepte wie Funktionen und Kontrollstrukturen intus, was die Entwicklung bereits enorm vereinfacht und die Sprache deutlich aufwertet. Eine echte Hochsprache mache ich daraus aber nicht, dazu schätze ich in diesem Stadium den Nutzen als zu gering ein, um die Entwicklungskosten eines komplexen Compilers zu rechtfertigen. Darum habe ich diesen Hybridansatz aus den Optionen 2) und 5) gewählt.

rapso

danke fuer diesen detailierten einblick, eine cheat instruction klingt wirklich durchaus nuetzlich

mit 2) meinte ich auch eigentlich die software "assembler" die dann den sourcecode in assembler-dialekt zu opcodes wandelt. das waere mir auch ausreichend, aber ich wuerde auf lange zeit hin wollen dass andere diesen simulator/emulator nutzen um eigenen code drauf laufen zu lassen, das auch sprachen unabhaengig, ich denke ein vorbeikommen am gcc ist da nicht

die option von fricky scheint mir zZ die am wenigsten zeitaufwendig, aber rechtlich bin ich mir unsicher.

ob es sowas wie nen 'transcoder' gibt von einem assembler in einen anderen? (am besten selbst definiert)? ich hab bisher nur disassembler+assembler fuer ein und die selbe architektur gesehen mit der man code injecten konnte, aber nichts wirklich 'uebersetzendes' (wenn man mal JIT ausklammert).

rapso schrieb:

aber rechtlich bin ich mir unsicher.

meinste die verklagen dich? das glaub ich nicht, es gibt ja schon einige freie arm-emulatoren. sogar nachgemachte arm-cores findeste im netz.