Re: C to Java Byte Code
From: Paul Lutus (nospam_at_nosite.zzz)
Date: 10/21/04
- Next message: Nick Landsberg: "Re: C/C++ Programmin Tutorials"
- Previous message: Alf P. Steinbach: "Re: please review my code"
- In reply to: Willem: "Re: C to Java Byte Code"
- Next in thread: Mohd Hanafiah Abdullah: "Re: C to Java Byte Code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 21 Oct 2004 10:37:38 -0700
Willem wrote:
> Paul wrote:
> ) You are not following the discussion. C is allowed to do things that
> Java ) cannot do, and you cannot write a compliant Java engine that can
> get around ) these constraints. My posted program as one example, which
> examines the ) details of a specific platform's float variable
> implementation. The result ) varies by platform, and this is by design. C
> can do this, Java cannot do ) this, end of story.
>
> Java can most certainly emulate any specific CPU, and run the C program in
> that emulation. According to the C standard, a C compiler is not required
> to make the result of your program depend on the underlying hardware.
Since you are so eager to abandon the topic, I will bring you up to date. We
are discussing specific claims:
<a9083a87.0410141937.1a7d4e1d@posting.google.com>
*****************************************************
"I think you would agree with me that a C compiler that directly
produces Java Byte Code to be run on any JVM is something that is
missing to software programmers so far. With such a tool one could
stay with C and still be able to produce Java byte code for
platform independent apps. Also, old programs (with some tweaking)
could be re-compiled and ported to the JVM."
"We have been developing such a tool over the last 2 years and currently
beta testing it."
*****************************************************
Note the use of the unadorned term "C". Not ANSI-compliant C, but C,
implying a typical C program compiled on a typical C compiler. On the
Website the language is more specific:
*****************************************************
"MPC is based upon the American National Standards Institute C (ANSI C),
X3.159-1989. There are however several minor differences between MPC and a
fully compliant ANSI C compiler. The differences of MPC with a fully
compliant ANSI C compiler are described in MPC's product description."
*****************************************************
But in fact, these "minor differences" include this requirement:
<cl7gbh$7th$1@hood.uits.indiana.edu>
*****************************************************
" ... programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC."
*****************************************************
That is a "minor difference"? All C programs that assume a byte-addressable
architecture will have to be rewritten? This is a fatal requirement for
anyting but a brief evaluation of the product. No one is going to rewrite
more than a few lines of code to accommodate such a requirement.
> I could, for example, run your program in a VMware running on a Sun
> sparcstation, and it would show Intel behaviour.
No, it wouldn't. This is not how VMware works. VMware doesn't emulate
different processors, it only emulates different operating system native to
a specific processor. You chose a very bad example.
> Are you claiming that
> that is somehow not acceptable behaviour ?
Are you willing to check your facts before posting?
/ ...
> )> Tell me, does that C program rely on non-standard behaviour ?
> )
> ) No, it is entirely standard ANSI C code. That is why I chose it.
>
> It invokes undefined behaviour.
What? It does nothing of the kind. On that topic, opening a file invokes
undefined behavior -- the file may not be present, the user may not have
read or write access, the file may not contain what the programmer expects.
Do you seriously intend to assert that code that invokes undefined behavior
cannot be accommodated in C programs?
> Therefore, a C compiler can do just about
> anything with it.
No, a compliant C compiler must compile it according to very specific rules,
and this is in fact what happens.
> It is not required to display the underlying hardware
> properties, it could just as well make demons fly out of your nose,
You need to stop posting brainless arguments.
> and still be a fully compilant C compiler.
This is false and unproductive. Among other errors, you are confusing
run-time behavior witih compile-time behavior.
-- Paul Lutus http://www.arachnoid.com
- Next message: Nick Landsberg: "Re: C/C++ Programmin Tutorials"
- Previous message: Alf P. Steinbach: "Re: please review my code"
- In reply to: Willem: "Re: C to Java Byte Code"
- Next in thread: Mohd Hanafiah Abdullah: "Re: C to Java Byte Code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
