Does any CVM [ C virtual Machine] exist?

[Minti]

<snip>

...............

Close your eyes and press escape three times.

Nothing happened do I need to try harder, could you specify some
specific platform or even as to if the system has to be switched on,
assuming you are taling about keyboards.

Or as a matter of fact nothing is supposed to happen. ;-)

 

[Joona I Palaste]

Minti <[email protected]> scribbled the following

Nothing happened do I need to try harder, could you specify some
specific platform or even as to if the system has to be switched on,
assuming you are taling about keyboards.

Or as a matter of fact nothing is supposed to happen. ;-)

On GNU Emacs, Esc Esc Esc is the universal keyboard signal for "No, I
don't want to do that after all".

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"To err is human. To really louse things up takes a computer."
- Anon

 

[Marmagya]

Would you belive me that you can write a C compiler using C language,

or do you think that assembly language was written in binary, if we
follow the language hierarchy. ;-).

Consider the following case. You are creating a new language, say 'D'.
You have not compiler for D, though you have specifications of the (as
of now, hypothetical) language D. So you know the control statements etc
and other details of the language. Now you set out to write a compiler
for this language. I believe you do need to write a minimalist compiler
written in something like an assembly language which will provide
compilation for an essential subset of D. Now, using this essential
subset, you can write an enhanced version of the first compiler that
will support the rest of the language. But I think at least for the
initial subset, you do need to use the assembly language.

I think that using the language to write its own compiler is analogous
to recursion. Ultimately you do need a termination condition.

Thanks a lot for bringing up this topic and please forgive me for being
argumentative, but I find it worth all the trouble to understand the issue.

Regards
Marmagya

 

[Calum]

Hi there everybody, I was just wondering that too many people choose
to use

language like Java because of its architecture independence, this AI
is

achieved because Java is as such a platform indeed, the code is
converted to

a byte code and this byte code can be run on any machine which has
Java

Virtual Machine or the Java Platform is installed, now my question is
that can't there be a C

Virtual machine, which would run the C byte code, wherein C byte code
is the

sort of a "compiled" and "intermediate" code before it can be run on
any

particular machine. Are there any shorcomings in this approach? I
guess

practicaly we can have a Virtual machine for every language.
Has anybody done this? Should anybody do this?

OT for c.l.c but I was just curious. Thanks

Isn't Microsoft .net a virtual machine running bytecode? Can't Visual
C++.net target the Common Language Runtime, instead of machine code?

Of course, this is hardly write once, run anywhere, but wait until Mono
(an open-source .net clone) gets finished... (http://www.go-mono.com/)
and eventually gcc might target the Mono/Commmon Language Runtime.

Which begs the question: how durable is Microsoft's .NET architecture?
I heard that they were gambling the company on it, so they obviously
think it's a really good idea that will last. Will it?

Calum

 

[Minti]

Minti <[email protected]> scribbled the following




On GNU Emacs, Esc Esc Esc is the universal keyboard signal for "No, I
don't want to do that after all".

Thanks for the enlightenment.

 

[Minti]

Consider the following case. You are creating a new language, say 'D'.
You have not compiler for D, though you have specifications of the (as
of now, hypothetical) language D. So you know the control statements etc
and other details of the language. Now you set out to write a compiler
for this language. I believe you do need to write a minimalist compiler
written in something like an assembly language which will provide
compilation for an essential subset of D.

Now, using this essential
subset, you can write an enhanced version of the first compiler that
will support the rest of the language. But I think at least for the
initial subset, you do need to use the assembly language.

Well we DO indeed for quite a lot of purposes, but if we were to write
every part of this "initial subset" only in assembly, don't you think
it would be unfair on C. I mean you can do the stuff by using C [
Hell C was made to be as a sort of abstraction layer above assembly ]
there is little point in doing that through Assembly, except if you
are *confident* you can write better assembly by yourself.

I think that using the language to write its own compiler is analogous
to recursion. Ultimately you do need a termination condition.

Well the process is called boot strapping and the termination
condition does indeed exist, and it is happens when the creator of the
language has reason to believe that there is no need to add any
feature to the already existent part of the language, consider the
recent improvements through the C standard, most of these I guess can
be implemented through C, now 5 years down the line the C standard
commitee says that Ok enough of C lets just finsh adding any more
feature because the current feature are enough for any possible
application of C, that my dear friend is a termination condition. This
is a poor lazy attempt ot highlight the point, but I hope it clears
up.

BASIC I belive has reached the termination condition.

Thanks a lot for bringing up this topic and please forgive me for being
argumentative, but I find it worth all the trouble to understand the issue.

Hey never mind. Being argumentative is good in many cases and this is
one of them. Just don't be argumentative with politicans and religious
leaders.

HTH

 

[Robert Vazan]

But I think at least for the
initial subset, you do need to use the assembly language.

Ever heard of cross-compiling?

 

[Marmagya]

Ever heard of cross-compiling?

Okay, so let me say that you are implementing the compiler for language
D by cross compiling and you are using language Z (on a different
platform) for this. Now how did you get the compiler/cross compiler for
Z in the first place? Even if you keep on cross compiling things, in the
end you will have to come to a lower level language like assembly to
create a minimalist compiler/cross compiler, and then you can continue
with cross compiling or creating compiler for a language using the
language itself.

Ultimately all the instructions have to be in machine language for a
processor to execute them. So all the high level programs have to be
ultimately converted into machine instructions. You cannot avoid this.
And that cannot avoid this means that utlimately you do need something
like an assembly language to create those machine instructions down the
line. Things like cross compiling etc can only make this conversion
indirect, but cannot eliminate this.

My point is that you cannot keep on using non-low level language to
implement things like VMs and compilers endlessly. You will come to a
low level language like assembly in the end to provide the 'last mile'.

Please forgive me for not agreeing with you outright, I am like this
unless I feel that my attitude will offend others.

Regards
Marmagya

 

[Programmer Dude]

I believe you do need to write a minimalist compiler written in
something like an assembly language which will provide compilation
for an essential subset of D.

Actually, you can write a compiler--minimal or otherwise--in any
language that lends itself to writing a compiler.

If you are imagining yourself stranded on a desert island with
only some hardware and no compiler at all, then, yes, you would
have to create a barebones one "from scratch".

 

[Programmer Dude]

Isn't Microsoft .net a virtual machine running bytecode?

(I just started learning C# and .net, so caveat reader....) It's
not exactly bytecode, AIUI, but "IL"--Intermediate Language, and
all their .net languages compile down to the same IL. One benefit
they tout is that you can define a class in VB.net and use it in
C# (or vice versa).

The author of the book I'm reading (Programming C#, 3rd Ed.) has
shown several IL dumps, so I'm guessing you can actually examine
this IL code.

Can't Visual C++.net target the Common Language Runtime, instead
of machine code?

I think that's ALL it does??? Or MAINLY what it does??? MS says
that the CLR can run over any OS, so it looks like they're trying
to sneak into the unices world. Apparently, any .net IL program
can run on any platform with the CLR.

Which begs the question: how durable is Microsoft's .NET
architecture?

[grin] Time will tell. MS-DOS was suprisingly durable (for some
definition of durable) despite being a pretty "kiddie" OS.

I heard that they were gambling the company on it, so they
obviously think it's a really good idea that will last.

IIRC, the author mentions they're spending 80% of their R&D on .net!

We're strictly an MS shop here, so .net is clearly in my future
(hence the book! .

 

[Corey Murtagh]

Marmagya wrote:

My point is that you cannot keep on using non-low level language to
implement things like VMs and compilers endlessly. You will come to a
low level language like assembly in the end to provide the 'last mile'.

You've got it backwards. The whole thing /started/ where you're ending.
Assemblers were created many years ago because people didn't want to
work in machine code anymore. Compilers were built, initially on top of
those assemblers, later by earlier models of themselves or by compilers
for other languages.

If you really wanted to you could trace the ancestry of any particular
language through the root languages used to produce it. There's no real
point to doing so however, since it has no real bearing on /modern/
compiler implementation. Take a language [A] that you're familiar with,
write a compiler for language - or a functional subset - in [A]. If
your compiler is capable enough, you might like to use it to write a
compiler.

Hell, if you like you can progress backwards down the tree. Implement
an assembler in C.

 

[Calum]

Calum wrote:




(I just started learning C# and .net, so caveat reader....) It's
not exactly bytecode, AIUI, but "IL"--Intermediate Language, and
all their .net languages compile down to the same IL. One benefit
they tout is that you can define a class in VB.net and use it in
C# (or vice versa).

I'm not sure what the exact difference is between a bytecode and an
intermediate language... Perhaps Sun uses bytecode (TM) so Microsoft has
to call it something else?

But, seeing how machine code is just a language, surely you could write
an emulator for that machine code to run anywhere. Which would probably
be just as quick as a bytecode/CLR to execute. But that would be
exposed as a pretty dumb way of doing things, so why are virtual
machines so widely accepted? Can't you just get decent binary
compatibility (it works with C++, but early implementations were
incompatible with each other), and make your OS provide a sandbox?

Does this mean a processor will eventually be able to execute CLR
instructions, if the whole world has to go .net?

The author of the book I'm reading (Programming C#, 3rd Ed.) has
shown several IL dumps, so I'm guessing you can actually examine
this IL code.




I think that's ALL it does??? Or MAINLY what it does??? MS says
that the CLR can run over any OS, so it looks like they're trying
to sneak into the unices world. Apparently, any .net IL program
can run on any platform with the CLR.

My Visual C++.net also targets native machine code, which is the way I
use it, plus it's a nice editor. In fact, unless someone actually held
a gun to my head, why on earth would I want to interface to Visual
Basic? (Okay, there are legitimate reasons for doing this)

Which begs the question: how durable is Microsoft's .NET
architecture?

[grin] Time will tell. MS-DOS was suprisingly durable (for some
definition of durable) despite being a pretty "kiddie" OS.

I heard that they were gambling the company on it, so they
obviously think it's a really good idea that will last.

IIRC, the author mentions they're spending 80% of their R&D on .net!

Go Objects!!!

We're strictly an MS shop here, so .net is clearly in my future
(hence the book! .

No no no, programming's supposed to be difficult mutter mutter... ;-)

 

[Chris Dollin]

But, seeing how machine code is just a language, surely you could write
an emulator for that machine code to run anywhere. Which would probably
be just as quick as a bytecode/CLR to execute. But that would be
exposed as a pretty dumb way of doing things, so why are virtual
machines so widely accepted? Can't you just get decent binary
compatibility (it works with C++, but early implementations were
incompatible with each other), and make your OS provide a sandbox?

You're expecting binary compatability between, say, an ARM, an x86,
and a Power PC? The point of a VM is that the code is portable,
and each implementation makes its own arrangements for executing it.
Including, but not limited to:

* write an interpreter for the VM code
* write a compiler for VM code -> native code
* mix: write an interpreter that compiles often-used code
* write a *microcode* interpreter for the VM code
* use gets() for nasal demons, enslave them, have them run the code

Does this mean a processor will eventually be able to execute CLR
instructions, if the whole world has to go .net?

No. [It might, but that doesn't mean it will.]

 

[Irrwahn Grausewitz]

You're expecting binary compatability between, say, an ARM, an x86,
and a Power PC? The point of a VM is that the code is portable,
and each implementation makes its own arrangements for executing it.
Including, but not limited to:

* write an interpreter for the VM code
* write a compiler for VM code -> native code
* mix: write an interpreter that compiles often-used code
* write a *microcode* interpreter for the VM code
* use gets() for nasal demons, enslave them, have them run the code

*lol*

Anyway, one addition:
The VM code may actually be identical to a specific native machine code.
IIRC there's a virtual machine called "Virtual PC" for the Mac which is
able to execute native x86 code, possibly generated by some C compiler.

<SNIP>

Regards

Irrwahn

 

[Gerry Quinn]

In theory, yes. C and Java are targetted at different audiences. In
practice however, they both get used for a lot of things that they're
not exactly suited for... more often in C than Java.

That's because they are both general purpose languages. I.E. they are
particularly intended for the purpose of being used for purposes they
are not particularly intended for ;-)

Gerry Quinn

 

[Calum]

Calum wrote:

But, seeing how machine code is just a language, surely you could write
an emulator for that machine code to run anywhere. Which would probably
be just as quick as a bytecode/CLR to execute. But that would be
exposed as a pretty dumb way of doing things, so why are virtual
machines so widely accepted? Can't you just get decent binary
compatibility (it works with C++, but early implementations were
incompatible with each other), and make your OS provide a sandbox?

You're expecting binary compatability between, say, an ARM, an x86,
and a Power PC? The point of a VM is that the code is portable,
and each implementation makes its own arrangements for executing it.
Including, but not limited to:

* write an interpreter for the VM code
* write a compiler for VM code -> native code
* mix: write an interpreter that compiles often-used code
* write a *microcode* interpreter for the VM code
* use gets() for nasal demons, enslave them, have them run the code

Does this mean a processor will eventually be able to execute CLR
instructions, if the whole world has to go .net?

No. [It might, but that doesn't mean it will.]

I think my main objection was when CLR etc was interpreted. You're
absolutely right, if you have local translation to native code, my
objection evaporates.

Advantages of VM
- Portability
- Safety

Disadvantages
- Slower
- Requires more memory
- Reverse engineering easier

After getting all my photos wiped by a VB script (yes I did have a
backup), I'm not sure I trust a Microsoft VM to be "safe". And I'm
surprised that Microsoft, who have traditionally done everything to
obstruct portability, would cite that as an advantage. Why not just
harden their operating system, and sandbox programs that way?

Calum

 

[Programmer Dude]

I'm not sure what the exact difference is between a bytecode and an
intermediate language...

You know, I have no idea. Maybe it is very similar. I got the
impression (from the dump displays in the book) it was assembly-like.
Can Java bytecode be "disassembled"?

But, seeing how machine code is just a language, surely you could
write an emulator for that machine code to run anywhere.

Sure. A friend has a Commodore64 emulator for his PC. Weird to
see those old programs running on the latest hardware! (-:

Which would probably be just as quick as a bytecode/CLR to execute.

Well, what apparently happens is that the CLR uses JIT compiling to
translate the IL to real machine code at runtime, and ONLY when a
function is called. Once a function is compiled and put in memory,
the CLR "remembers" it and references it from then on. Thus you
only pay a translation penalty the first time you call any given
function.

...so why are virtual machines so widely accepted?

Because the bytecode/IL/PCode/whatever can--in principle--be
completely cross-platform. You need only implement the VM.

Can't you just get decent binary compatibility, and make your OS
provide a sandbox?

Direct machine code *always* runs faster, and each CPU has their
own machine code. Some are *vastly* different, other less so,
but 6502 code just ain't gonna run on a MIPS. (-:

Does this mean a processor will eventually be able to execute CLR
instructions, if the whole world has to go .net?

[shrug] No idea. Java supposedly was designed with a Java CPU as
a consideration, but it doesn't seem to have taken the world by
storm. Are there ANY Java CPUs in the commercial world?

In fact, unless someone actually held a gun to my head, why on
earth would I want to interface to Visual Basic? (Okay, there
are legitimate reasons for doing this)

Yes, there are. VB and I have done some nice things together!

 

[Corey Murtagh]

[followups set to comp.programming, since this has nothing to do with
the C language]

I'm not sure what the exact difference is between a bytecode and an
intermediate language... Perhaps Sun uses bytecode (TM) so Microsoft has
to call it something else?

The difference is subtle, and probably not important anymore. For the
most part .NET's 'intermediate language' and Java's 'bytecode' are
equivalent concepts.

Back when Java was young, bytecode was appropriate because the original
JVMs ran it directly (ie: it was their machine code). These days Java
bytecode is more often than not treated as an intermediate language, and
JIT compiling is used to translate that into native code for execution.

The way I understand it, .NET was designed from the bottom up to do JIT
compiling on CIL code. As such it's more correct (for certain values of
'correct') to call it an intermediate language.

But, seeing how machine code is just a language, surely you could write
an emulator for that machine code to run anywhere. Which would probably
be just as quick as a bytecode/CLR to execute.

And people have written emulators for various platforms. In effect a
JVM is an emulator of the Java platform, .NET and the MONO project are
emulators for the .NET platform, etc.

But that would be
exposed as a pretty dumb way of doing things, so why are virtual
machines so widely accepted? Can't you just get decent binary
compatibility (it works with C++, but early implementations were
incompatible with each other), and make your OS provide a sandbox?

C++ doesn't have binary compatibility between platforms. Never has.

The problem is that each platform has a number of major differences in
executable formats, different available APIs for doing the same thing,
various APIs that are available on one platform but not others, possibly
different CPUs with their own native machine code...

Creating a cross-platform standard for executables isn't going to
happen. Instead, Sun created a platform called Java, and provided
emulators for it to run on various platforms.

Does this mean a processor will eventually be able to execute CLR
instructions, if the whole world has to go .net?

There was talk a few years ago about Sun creating a Java CPU which could
be used to create an actual hardware+os implementation of the Java
platform. I don't know what became of it, but so far it has failed to
become a reality as far as I can see. Perhaps it was rendered pointless
by the vast improvements in JVMs.

I doubt that we'll see a .NET cpu any time soon.

 

[Minti]

You know, I have no idea. Maybe it is very similar. I got the
impression (from the dump displays in the book) it was assembly-like.
Can Java bytecode be "disassembled"?

Yup! I am new to Java but I know it can be done, and that is one of
the bad things about java, java Decompilation is FAST really fast, I
don't know why programmers don't just send their .java files instead
of .class when they know their code can be decompiled easily.

Check out.

http://members.fortunecity.com/neshkov/dj.html

Sure. A friend has a Commodore64 emulator for his PC. Weird to
see those old programs running on the latest hardware! (-:

Looking at the direction of your smily, I was just wondering if you
wrote that whole line R->L.

Which would probably be just as quick as a bytecode/CLR to execute.

Well, what apparently happens is that the CLR uses JIT compiling to
translate the IL to real machine code at runtime, and ONLY when a
function is called. Once a function is compiled and put in memory,
the CLR "remembers" it and references it from then on. Thus you
only pay a translation penalty the first time you call any given
function.

...so why are virtual machines so widely accepted?

Because the bytecode/IL/PCode/whatever can--in principle--be
completely cross-platform. You need only implement the VM.

Can't you just get decent binary compatibility, and make your OS
provide a sandbox?

Direct machine code *always* runs faster, and each CPU has their
own machine code. Some are *vastly* different, other less so,
but 6502 code just ain't gonna run on a MIPS. (-:

Does this mean a processor will eventually be able to execute CLR
instructions, if the whole world has to go .net?

[shrug] No idea. Java supposedly was designed with a Java CPU as
a consideration, but it doesn't seem to have taken the world by
storm. Are there ANY Java CPUs in the commercial world?

IIRC picoJava is the thing you want. I have very little about it, but
I think it is a Java CPU.

Yes, there are. VB and I have done some nice things together!

--
Imanpreet Singh Arora
imanpreet_arora AT yahoo DOT co DOT in

"Good artists copy, great artists steal."
Pablo Picasso

 

[Minti]

Okay, so let me say that you are implementing the compiler for language
D by cross compiling and you are using language Z (on a different
platform) for this. Now how did you get the compiler/cross compiler for
Z in the first place?

Hmmmm, the question is quite similar to "In which language was early C
designed or maybe the first high level language designed?"

Well without a shadow of doubt the first high/middle level language
was designed in assembly itself only, but I believe that the usage
would have been limited to a minimalist set.

Even if you keep on cross compiling things, in the
end you will have to come to a lower level language like assembly to
create a minimalist compiler/cross compiler, and then you can continue
with cross compiling or creating compiler for a language using the
language itself.

Your above example try to go "histrically down" but this argument
"historically up", say what you wanna say.

Ultimately all the instructions have to be in machine language for a
processor to execute them. So all the high level programs have to be
ultimately converted into machine instructions. You cannot avoid this.
Certainly.

And that cannot avoid this means that utlimately you do need something
like an assembly language to create those machine instructions down the
line. Things like cross compiling etc can only make this conversion
indirect, but cannot eliminate this.

Nopes assembly might not be needed, I mean these binary instructions
are their in your executable file right now open your executable file
and you would see some weird text,

Now if I write a high level block

that puts in those characters in some file, I don't think you need
assembly my friend, I mean one of the aims of programming is to use
abstractions that are available.

You are however welcome to make clarifications.

My point is that you cannot keep on using non-low level language to
implement things like VMs and compilers endlessly. You will come to a
low level language like assembly in the end to provide the 'last mile'.

Please forgive me for not agreeing with you outright, I am like this
unless I feel that my attitude will offend others.

Forgiven ;-). But welcomed to make the same mistake.


HTH.