OSDev.org

Posted: **Sun Dec 05, 2010 8:23 pm**

My company ( by mine, I mean I own it, and am the only employee ) has developed a platform/os independant binary format.

I call it the Virtual C Machine Interpreter.

Basically, it compiles C into a byte code that is then interpreted at run time ( I am working on JIT )

I am wondering if any one would be interested in it.

Posted: **Sun Dec 05, 2010 8:32 pm**

What are the advantages of this particular bytecode (over something like LLVM, for example)? Do you have a working system for compiling to it and running it?

Posted: **Sun Dec 05, 2010 8:39 pm**

Currently I have:

C Preprocessor
C Compiler ( out puts asm )
Asembler ( outputs final binary )

I am working on a linker so programs can be compiled simlar to how one would with gcc/binutils.

The advantages are:
Near native exicution speeds.
I write a program on my os, it runs on yours, given that we both implement the needed interfaces, such as if the app is gui, we both have a gui, etc.

The interpreter currently runs under windows mac and linux.

Posted: **Sun Dec 05, 2010 8:48 pm**

lybredyne wrote:I write a program on my os, it runs on yours, given that we both implement the needed interfaces, such as if the app is gui, we both have a gui, etc.

So it imposes a particular API for things like graphics and other platform dependent stuff?

Posted: **Sun Dec 05, 2010 9:41 pm**

ultimately, thats the plan.

don't have the graphics interface finished yet.

It's strictly text mode.

basically, tho, one could implement any type of interface they wanted.

The graphics interface I am working on is based on gtk.

Posted: **Sun Dec 05, 2010 9:53 pm**

But does the VM itself provide the interface for graphics and system functions (like in Java), or is that functionality provided by linked-to libraries like usual? If it's the former, that sort of makes the VM an OS in itself.

Posted: **Sun Dec 05, 2010 10:05 pm**

The vm only provides a method for the host application to provide functionality to the vm.

All the vm is concerned with is processing the byte code.

all it aims to be is the cpu.
the host application must provide the back plain and add in cards.
( to use the pc paradyne )

Posted: **Mon Dec 06, 2010 6:56 am**

How does your interpreter abstract the native system API so the bytecode executes the same function anywhere? as in, yeild() on linux vs Sleep() on windows?

Will it have its own system API subset?

What about calling external dependencies? Will they ultimately be portable if recompiled with your tools?

You say near native performance speeds, have you measured this against performances of similar implementations? And are you physically emulating the bytecodes or is it virtualized JIT and run on CPU?

Posted: **Mon Dec 06, 2010 12:58 pm**

iLewis wrote:How does your interpreter abstract the native system API so the bytecode executes the same function anywhere? as in, yeild() on linux vs Sleep() on windows?

Will it have its own system API subset?

What about calling external dependencies? Will they ultimately be portable if recompiled with your tools?

You say near native performance speeds, have you measured this against performances of similar implementations? And are you physically emulating the bytecodes or is it virtualized JIT and run on CPU?

The VCMI has it's own API.
The host, be it an application or an OS task, provides the abstraction, for example:

In the application host, there is this function:

Code: Select all

int mySystemCall(VM *vm, int syscall, int opt)
{
  switch( opt ) {
    case 1234:
         Print("1 + 2 + 3 + 4 == 10\n");
         vm->sp[0] = (int)10;
         /**/
         break;
    case 31337:
         Print("You said %8.8X\n", vm->bp[-3]);
         /**/
         break;
    default:
         Print("mySystemCall has been triggerd\n---> SysCall = %u\n---> Option = %u\n", syscall, opt);
         break;
  }
}

Then, in the main function,

Code: Select all

    registerVCMISystemCall(31337, mySystemCall);

Then in the VCMI program ( in asembler )

Code: Select all

myPrintTen:
    .globl myPrintTen
    syscall 31337, 1234
    ret

after that, the C code running in VCMI can simply call

Code: Select all

myPrintTen();

As for external dependencies, I am working on something similar to dlopen() and such.
The system already has the ability lo load other VCMI binaries into its address space, I just need to make it happen automaticly and have it so the code segment of the loaded binaries can be shared but the data segment is unique to the address space of the loading VCMI program.
This will allow something akin to how real operating systems will load a dll once and use copy-on-write, etc to kive each process that is using it there "own" copy.

As I mentioned in a previous post, I don't have JIT yet, it is being researched.
As far as measuring performance, I wrote a complex and intensive program in C, the timed it's execution under TCC, GCC, and VCMI.
I dont have the results handy, as this was done several months ago.

I plan to re-run the benchmark again soon.

Since there has been interest in the VCMI, I will post the results for any one who wants them.

Posted: **Mon Dec 06, 2010 5:27 pm**

I have never used LLVM's byte code. so I can not give a comparison.
All I can say is that this VM is designed around the C language and is optimized for interprting that.

as far as byte code, here is one of the test files:

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc,char *argv[])
{
   int i;

  if(!argc) {
    printf("There seems to bee an error with my enviroment, I dont even have an arg[0]\n");
    return 0;
  }

  for(i=0; i<argc; i++) {
    printf("argv[%u] = '%s'\n", i, argv[i]);
  }

  return 0;
}

And the assembler output ( the .byte lies were one byte to a line, I condensed them for readability. ):

Code: Select all

/* begining of module */
.module

.text
 /* function definition main */
main:
 .globl main
 addsp @S0
/* local variable 'i' stack offset=4 */
 libp -12
 ld
 li 0
 cmpeq
 jeq @L1
.data
@S1:
 .byte 84 104 101 114 101 32 115 101 101 109 115 32 116 111 32 98 101
 .byte 101 32 97 110 32 101 114 114 111 114 32 119 105 116 104 32 109
 .byte 121 32 101 110 118 105 114 111 109 101 110 116 44 32 73 32 100
 .byte 111 110 116 32 101 118 101 110 32 104 97 118 101 32 97 110 32
 .byte 97 114 103 91 48 93 10 0
.text
 li @S1
 li printf
 call 4
 pop
 li 0
 ret
@L1:
 li 0
 libp 4
 st
 pop
@L3:
 libp 4
 ld
 libp -12
 ld
 cmplt
 jeq @L4
 libp -16
 ld
 libp 4
 ld
 li 4
 mul
 add
 ld
 libp 4
 ld
.data
@S2:
 .byte 97 114 103 118 91 37 117 93 32 61 32 39 37 115 39 10 0
.text
 li @S2
 li printf
 call 12
 pop
@L5:
 libp 4
 ld
 li 1
 add
 libp 4
 st
 li 1
 sub
 pop
 jmp @L3
@L4:
 li 0
 ret
 li 0
 ret
 .equ @S0,4
/* end of function */

The un-linked object:

Code: Select all

-rw-r--r--  1 crdobbs users 4.5K 2010-12-06 15:23 test3.cro

The final ( statically linked ) binary looks like this:

Code: Select all

-rw-r--r-- 1 crdobbs users 148K 2010-06-24 20:55 test3.crv

Both the object and the final binary have full symbol table and debug information in them.

I hope this answers your question about the byte code.
If you have a specific question about it, let me know.

Posted: **Tue Dec 07, 2010 1:44 am**

First off, the bytecode is portable, how ever, there is a bug in the assembler that fails to output the correct alignment when done on non-x86 processors.

and, yes, li pushes a value onto the stack.

the VCMI has access to the entirety of the host's memory space.
addresses are 32bit.

if the host allocates a memory block at 0xc0000, the the VCMI can access it at 0xc0000 @$$ well, for example.

Posted: **Tue Dec 07, 2010 10:01 am**

lybredyne wrote:Currently I have:

C Preprocessor
C Compiler ( out puts asm )
Asembler ( outputs final binary )

I am working on a linker so programs can be compiled simlar to how one would with gcc/binutils.

Yes, I have a compiler. It's not that great, but it works and is c99 compliant.

The C Preprocessor is currently not built into the compiler.

Posted: **Tue Dec 07, 2010 3:55 pm**

Except, your comparing two things that are designed to be differant tools.

LLVM, tho it has a byte code, is a compiler. It is designed to target a specific platform.

VCMI is a virtual machine, designed to run platform independent byte code on any platform.

The comparison does not work.

It seems your questions were targeted to prove that llvm was better than vcmi.
Maybe it is, as a compiler. But that's not what vcmi is.

you might as well have compared llvm and visual studio.

A better comparison would have been with java.

And to say flat out that there is no reason to use it because your favorite compiler is a better compiler is just silly.

VCMI is a work in progress, and I was offering it to anyone who would be interested because of what it is, as the title of the post says, a way to create Platform Independent Applications

Sorry to come across sharply, but your blatant dismissal was rude and arrogant.

Posted: **Tue Dec 07, 2010 4:39 pm**

But how "platform independent" is VCMI relative to LLVM? If I've heard you correctly, VCMI uses a set of standard libraries to make portable things that are usually platform dependent, kind of like Java but with C. Afaik, you could do this just as well in LLVM if you decided on a specific set of libraries to have as a standard, because the bytecode is at least architecture independent.

Posted: **Tue Dec 07, 2010 4:47 pm**

no, vcmi is a byte-code interpreter, like java.

It has it's own api, which is presented by it's host, either the operating system or an application.

vcmi is not compiled into machine dependent code.
I am working on jit for it, to improve the speed of the interpreter, but the binary that you run, is platform independent.

you can compile a program with vcmi on a windows box, stick it on a flash drive, take it over to you ppc mac and run it. ( given that the mac has the vcmi run-time installed. )

the big difference between vcmi and java, is size.

vcmi, compiled for x86_64 linux is only 68k.
compare that to the size of the current JRE

Granted, java has more features, a bigger rtl.

OSDev.org

Platform independant applications

Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications

Re: Platform independant applications