OSDev.org

I'm looking into making a cross platform virtual machine with the following features as well as keeping it close enough to other platforms that I can recompile with it as the target.

• Support for all most architectures
  • ARM
  • MIPS
  • PowerPC
  • X86 / X86-64
• Support for most platforms
  • The Amigas (Amiga OS / AROS / Morph OS)
  • The *BSDs (FreeBSD / NetBSD / OpenBSD / DragonFlyBSD / Darwin / Mac OS X)
  • Linux
  • Ice OS
  • Haiku
  • FreeDOS
  • MINIX3
  • RISC OS
• Support for mobile platform?
  • Android
  • iOS
• Support for SMP
• Support for C/C++ (designed to be like a real machine)
• Large collection of C/C++ frameworks with bindings made using swig
• Custom CPU architecture (I'm not trying to emulate an existing one but make a new one)
• Message passing inside the machine
• HostFS to read the host's file system as if it was our own
• Register based like Devik VM or Parrot

What executable format should I use?

• A custom executable format BFF
• ELF ported to my architecture

What method would be best to created and run my virtual CPU?

• Emulated
• Virtualization
• Dynamic binary translation
• Paravirtualization

How many registers should I have in my architecture?

• 8 like the X86
• 16 like most common CPUs
• Infinity with register window like Parrot VM

What type of instruction set would be better

• RISC
• CISC

How many Operands should be supported?
Most have three though the X86 has only two? what's the most effective number?
What type is better to use?

• Register-Register
• Register-Memory
• Register-Register/ Register-Memory

What type of Instruction encoding is better?

• Variable
• Fixed

and Finally what Endianness is best to use?

• Big
• Little
• Bi

I know I need emulated drivers to be able to interface with the host.
I plan to implement only my own virtual CPU on top of these systems and architectures.
I'm trying to make a complete platform like a normal computer platform with C/C++ as the main development languages
simply put I'm making a cross platform virtual environment that is intended to be like a normal computer not like Qemu

zeitue wrote:My goal is to make a complete platform like JVM but more like a normal computer platform and for C/C++ instead of Java.

It is not exactly a goal. Why would your VM be better than JVM, or Dis, or any other VM for that matter? Why would I switch from QEMU for example?

dozniak wrote:

zeitue wrote:My goal is to make a complete platform like JVM but more like a normal computer platform and for C/C++ instead of Java.

It is not exactly a goal. Why would your VM be better than JVM, or Dis, or any other VM for that matter? Why would I switch from QEMU for example?

I did not say anywhere like QEMU.
I just edited and removed the JVM reference because it's not really much like it I just meant in the cross platform way
I intend this to be a cross platform register based computer platform

Ok, in that case you can use any of the options you asked about. They are all different, but without knowing what is the actual intended usage it's impossible to predict what will be better for you. Just do anything you like.

dozniak wrote:Ok, in that case you can use any of the options you asked about. They are all different, but without knowing what is the actual intended usage it's impossible to predict what will be better for you. Just do anything you like.

Well I intend it to be used for general purpose like a standard Arm or X86 hardware would as a virtual layer on top of those.

zeitue wrote:Well I intend it to be used for general purpose like a standard Arm or X86 hardware would as a virtual layer on top of those.

It could then be exactly like standard ARM or x86 hardware. Even better, you could use standard ARM or x86 hardware, hence not needing your layer on top of those.

dozniak wrote:

zeitue wrote:Well I intend it to be used for general purpose like a standard Arm or X86 hardware would as a virtual layer on top of those.

It could then be exactly like standard ARM or x86 hardware. Even better, you could use standard ARM or x86 hardware, hence not needing your layer on top of those.

Thanks for the idea though I've been reading and looking into using the X86 or ARM as the platform, however the architectures are quite different and don't run well emulated on each other.
I think that if I used ARM of X86 it would have to be the ARM because the X86 is way more complex.
additionally I think that if I choose an existing CPU architecture it gives that architecture and unfair advantage.
I would prefer to design my own

zeitue wrote:I think that if I used ARM of X86 it would have to be the ARM because the X86 is way more complex.

Here comes up one of the points in your list: fixed width instructions are somewhat easier to emulate, even if they slightly suffer in the code density.

dozniak wrote:

zeitue wrote:I think that if I used ARM of X86 it would have to be the ARM because the X86 is way more complex.

Here comes up one of the points in your list: fixed width instructions are somewhat easier to emulate, even if they slightly suffer in the code density.

• How would the performance for fixed width vs variable width instructions differ; which would be faster?
• Would the executable size be greater for a fixed width instruction set?
• Is my definition of code density correct?

  Code density refers loosely to how many microprocessor instructions it takes to perform a requested action, and how much space each instruction takes up. Generally speaking, the less space an instruction takes and the more work per instruction that a microprocessor can do, the more dense its code is.

  As in it would run more code in less time using a fixed width instruction set?

It doesn't seem clear whether you are trying to design something that resembles actual hardware (you mention being able to target C to it, which requires a uniform address space; the JVM, for example, can only deal with addressing relative to objects) or trying to make an application virtual machine like the JVM or CLR (.NET). The design goals for those two categories are radically different.

Beyond that, you want to decide on things like whether the VM has garbage collection baked in (like the JVM, CLR, Python bytecode, Lua bytecode, etc.), whether it is designed to be interpreted easily or to be just-in-time compiled easily (or even ahead-of-time compiled, like LLVM), etc. These types of trade-offs should be guided by the purpose of the VM, and don't have a single "correct choice".

NickJohnson wrote:It doesn't seem clear whether you are trying to design something that resembles actual hardware (you mention being able to target C to it, which requires a uniform address space; the JVM, for example, can only deal with addressing relative to objects) or trying to make an application virtual machine like the JVM or CLR (.NET). The design goals for those two categories are radically different.

Beyond that, you want to decide on things like whether the VM has garbage collection baked in (like the JVM, CLR, Python bytecode, Lua bytecode, etc.), whether it is designed to be interpreted easily or to be just-in-time compiled easily (or even ahead-of-time compiled, like LLVM), etc. These types of trade-offs should be guided by the purpose of the VM, and don't have a single "correct choice".

I'm trying to make a complete platform hat will run on almost all computers.
It will be a computer platform reassembling real hardware, then on top of this will be a small kernel that runs as part of the virtual machine and then on top of that will be libraries and daemons.
I'm thinking that if I start from a virtual CPU and go up, I'll have pretty good compatibility inside the machine.

Funny this is my 64 bit post

If your only purpose is to run same object code on different targets and architectures, try studying existing systems that do the same (e.g. Inferno Dis, LLVM IR, JVM, CLR, Parrot).

They went through quite a bit of optimizations and you can find some arguments about what went good and what went bad in those designs.

I'm currently debating

• instruction length 32 bit maybe
• CISC or RISC like
• Fixed or Variable length instructions

I need to make sure that this will run fast on most major architectures
I'm thinking a CISC machine might run RISC slower because it might have to do more operations that it's not used to?
but a RISC machine my also be slow running CISC because of the conversion to more instructions?
I hope all my reading 16 hours a day will pay off on this

dozniak wrote:If your only purpose is to run same object code on different targets and architectures, try studying existing systems that do the same (e.g. Inferno Dis, LLVM IR, JVM, CLR, Parrot).

They went through quite a bit of optimizations and you can find some arguments about what went good and what went bad in those designs.

Thank you I'll look into them.
currently I have looked at Inferno Dis, LLVM IR, JVM, Parrot. The JVM is stack based so quite different from my main register based idea.

If I was starting my first VM I'd decide it's not going to be production final design and go with RISC fixed-width instructions first just for simplicity of it, then I'd evaluate how it performs and adjust the design according to my measurements.