C to Java Byte Code

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.

It's called MPC (for Multi-Platform C) and you can download the beta
version at http://www.axiomsol.com or at http://freshmeat.net

Napi

napi wrote:[color=blue]
> 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.[/color]

Probably because writing C for a VM like the Java VM is pretty stupid,
when you /should/ be linking to precompiled libraries from within your
Java (or Perl, or whatever) code.
[color=blue]
> 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.[/color]

I can honestly say I've never needed to port legacy C to a VM
environment like the Java VM. I honestly can't see the need, as I've
said above.
[color=blue]
>
> We have been developing such a tool over the last 2 years and currently
> beta testing it.
>
> It's called MPC (for Multi-Platform C) and you can download the beta
> version at http://www.axiomsol.com or at http://freshmeat.net[/color]

Heh. /All/ C should be multi-platform, if the programmer is paying
attention to the relevant standards.

On 14 Oct 2004 20:32:39 -0700, napi@axiomsol.com (napi) wrote:
[color=blue]
>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.[/color]

I don't know about availability, but there was work done on this from
at least 5 years ago: http://www.cs.ucla.edu/~ashapiro/cminusjava/
[color=blue]
> 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.
>
>It's called MPC (for Multi-Platform C) and you can download the beta
>version at http://www.axiomsol.com or at http://freshmeat.net[/color]

Why is it restricted to Linux only?

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Alan Balmer wrote:
[color=blue][color=green]
>>Probably because writing C for a VM like the Java VM is pretty stupid,
>>when you /should/ be linking to precompiled libraries from within your
>>Java (or Perl, or whatever) code.
>>[/color]
> Not the same thing. This is the Microsoft .NET approach (which some
> people also think is stupid.)[/color]

Incidentally, portable.net includes a C compiler which generates .NET
executables...

Daniel

napi wrote:
[color=blue]
> I think you would agree with me[/color]

Are you mad?

<snipped>

goose,

napi wrote:[color=blue]
> 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.
>
> It's called MPC (for Multi-Platform C) and you can download the beta
> version at http://www.axiomsol.com or at http://freshmeat.net[/color]

C is a procedural language. Unless I am missing something, JVM is only
an OO platform. So, how does it work?

It sounds something like C++ to me.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

napi@axiomsol.com (napi) wrote in message news:<a9083a87.0410141932.589c5eb5@posting.google. com>...[color=blue]
> 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.[/color]

Alternately, one could bite the bullet and, you know, learn Java for
new development*.
[color=blue]
> Also, old programs (with some tweaking) could be re-compiled and ported
> to the JVM.[/color]

That's certainly an interesting idea.

So. How do you handle stuff like graphics, networking, sound, file
system management, etc., that have all traditionally been handled by
third-party libraries? Have you provided your own set of libraries
for this (a la Neuron Data's Open Interface Elements)? What vendor
extensions can you handle? I can think of some code I've encountered
over the years that would require a bit more than "some tweaking" to
conform to a new API.
[color=blue]
> We have been developing such a tool over the last 2 years and currently
> beta testing it.
>
> It's called MPC (for Multi-Platform C) and you can download the beta
> version at http://www.axiomsol.com or at http://freshmeat.net
>
> Napi[/color]

* "Java sucks" is not an excuse.

Alan Balmer <albalmer@att.net> wrote:[color=blue]
> I don't know about availability, but there was work done on this from
> at least 5 years ago: http://www.cs.ucla.edu/~ashapiro/cminusjava/[/color]

<shameless plug>
There is also NestedVM (http://nestedvm.ibex.org/, but unfortunately
we don't really have a website for it yet). You can read about it in
our IVME paper at http://www.megacz.com/research/paper...dvm.ivme04.pdf

NestedVM is open source and runs on any platform that GCC runs on. For
more information email Adam Megacz and I (email addrs in the paper).
</shameless plug>

-Brian

brian@brianweb.net (Brian Alliet) writes:[color=blue]
> NestedVM is open source and runs on any platform that GCC runs on. For
> more information email Adam Megacz and I (email addrs in the paper).
> </shameless plug>[/color]

Also in the paper you'll find references to a number of
products/projects like MPC (for example, the Java Bytecode backend for
gcc).

NestedVM has a few other advantages as well; it's not restricted to C
(we've used it on Fortran and Pascal programs as well) and it has no
difficulties with compiler-specific quirks (gcc-specific or
MSVC-specific hacks) since it doesn't try to replace the compiler.

- a

--
I wrote my own mail server and it still has a few bugs.
If you send me a message and it bounces, please forward the
bounce message to megacz@gmail.com. Thanks!

john_bode@my-deja.com (John Bode) wrote in message news:<43618c0e.0410151155.5313a302@posting.google. com>...[color=blue]
> napi@axiomsol.com (napi) wrote in message news:<a9083a87.0410141932.589c5eb5@posting.google. com>...[color=green]
> > 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.[/color]
>
> Alternately, one could bite the bullet and, you know, learn Java for
> new development*.
>[color=green]
> > Also, old programs (with some tweaking) could be re-compiled and ported
> > to the JVM.[/color]
>
> That's certainly an interesting idea.
>
> So. How do you handle stuff like graphics, networking, sound, file
> system management, etc., that have all traditionally been handled by
> third-party libraries? Have you provided your own set of libraries
> for this (a la Neuron Data's Open Interface Elements)? What vendor
> extensions can you handle? I can think of some code I've encountered
> over the years that would require a bit more than "some tweaking" to
> conform to a new API.[/color]

Currently MPC is in beta and we only support most of the ANSI C
library which includes the file system management. The release
version should support some UNIX system calls library, TCP/IP library,
and graphics library.

MPC is available to be used on Linux/x86 for now which produces code
for the
JVM. Next we will port it to MacOS followed by Solaris and then
Windows XP/NT.

Cheers.

Napi

In article <43618c0e.0410151155.5313a302@posting.google.com >,
John Bode <john_bode@my-deja.com> wrote:[color=blue]
>napi@axiomsol.com (napi) wrote in message
>news:<a9083a87.0410141932.589c5eb5@posting.google .com>...[color=green]
>> 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.[/color]
>
>Alternately, one could bite the bullet and, you know, learn Java for
>new development*.[/color]

Yes, you can. But some people prefer C to Java and there are many C
programmers out there I believe. It has been around since 1969 starting
at Bell Labs..
[color=blue][color=green]
>> Also, old programs (with some tweaking) could be re-compiled and ported
>> to the JVM.[/color]
>
>That's certainly an interesting idea.
>
>So. How do you handle stuff like graphics, networking, sound, file
>system management, etc., that have all traditionally been handled by
>third-party libraries? Have you provided your own set of libraries
>for this (a la Neuron Data's Open Interface Elements)? What vendor
>extensions can you handle? I can think of some code I've encountered
>over the years that would require a bit more than "some tweaking" to
>conform to a new API.[/color]

File system mgmt is covered, while the other APIs we still working on.
We try to use available APIs written in Java and interface to them using
the C syntax. This was what we did with the File System Mgmt, i.e., using
the ones available from J2SDK. MPC is still in Beta, so it's still work in
progress.
[color=blue][color=green]
>> We have been developing such a tool over the last 2 years and currently
>> beta testing it.
>>
>> It's called MPC (for Multi-Platform C) and you can download the beta
>> version at http://www.axiomsol.com or at http://freshmeat.net
>>
>> Napi[/color]
>
>* "Java sucks" is not an excuse.[/color]

I think it's just a matter of preference.

Napi

--
http://www.cs.indiana.edu/hyplan/napi.html

Mohd Hanafiah Abdullah wrote:
[color=blue]
> In article <43618c0e.0410151155.5313a302@posting.google.com >,
> John Bode <john_bode@my-deja.com> wrote:[color=green]
>>napi@axiomsol.com (napi) wrote in message
>>news:<a9083a87.0410141932.589c5eb5@posting.googl e.com>...[color=darkred]
>>> 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.[/color]
>>
>>Alternately, one could bite the bullet and, you know, learn Java for
>>new development*.[/color]
>
> Yes, you can. But some people prefer C to Java and there are many C
> programmers out there I believe. It has been around since 1969 starting
> at Bell Labs..[/color]

You know, Mr. Abdullah, it would serve the truth better if you explained
what your product cannot do, and if you tried to avoid a marked tendency to
replace candor with marketing hype.
[color=blue]
>[color=green][color=darkred]
>>> Also, old programs (with some tweaking) could be re-compiled and ported
>>> to the JVM.[/color]
>>
>>That's certainly an interesting idea.[/color][/color]

And it's false. If, as has been revealed, C programs that use byte indexing
and addressing have to be substantially rewritten to accommodate this
product, how does the above "tweaking" remark accurately describe this
requirement?
[color=blue][color=green]
>>
>>So. How do you handle stuff like graphics, networking, sound, file
>>system management, etc., that have all traditionally been handled by
>>third-party libraries? Have you provided your own set of libraries
>>for this (a la Neuron Data's Open Interface Elements)? What vendor
>>extensions can you handle? I can think of some code I've encountered
>>over the years that would require a bit more than "some tweaking" to
>>conform to a new API.[/color]
>
> File system mgmt is covered, while the other APIs we still working on.
> We try to use available APIs written in Java and interface to them using
> the C syntax. This was what we did with the File System Mgmt, i.e., using
> the ones available from J2SDK. MPC is still in Beta, so it's still work
> in progress.
>[color=green][color=darkred]
>>> We have been developing such a tool over the last 2 years and currently
>>> beta testing it.
>>>
>>> It's called MPC (for Multi-Platform C) and you can download the beta
>>> version at http://www.axiomsol.com or at http://freshmeat.net[/color][/color][/color]

Since Mr. Abdullah has seen fit to start a new cross-posted thread promoting
this commercial C -> Java project, I think it only fair to point out that
the claims on his Web site are not met by his product.

According to the evidence, this project won't actually convert most existing
C programs into Java with a little "tweaking", as is claimed above.

The project may eventually meet some of its claims, but it certainly does
not now, and anyone contemplating involvement with this project should be
very skeptical of the claims being made.

Mr. Abdullah has repeatedly cross-posted messages that are pure marketing
hype, then, when confronted by tough questions, replies with the defense
that the product is in beta, without acknowledging that it very simply
cannot meet the claims posted on the Web site.

--
Paul Lutus
http://www.arachnoid.com

In article <10npbpmkjaqdqa3@corp.supernews.com>, nospam@nosite.zzz
says...[color=blue]
> Mohd Hanafiah Abdullah wrote:[/color]
[color=blue][color=green][color=darkred]
> >>> Also, old programs (with some tweaking) could be re-compiled and ported
> >>> to the JVM.
> >>
> >>That's certainly an interesting idea.[/color][/color]
>
> And it's false. If, as has been revealed, C programs that use byte indexing
> and addressing have to be substantially rewritten to accommodate this
> product, how does the above "tweaking" remark accurately describe this
> requirement?[/color]

As I understand it, this issue only affects incompetent programmers who
write code that assumes that bytes have eight bits. The sort of
programmers in whose code unions are "ubiquitous".

- Gerry Quinn

Gerry Quinn wrote:
[color=blue]
> In article <10npbpmkjaqdqa3@corp.supernews.com>, nospam@nosite.zzz
> says...[color=green]
>> Mohd Hanafiah Abdullah wrote:[/color]
>[color=green][color=darkred]
>> >>> Also, old programs (with some tweaking) could be re-compiled and
>> >>> ported to the JVM.
>> >>
>> >>That's certainly an interesting idea.[/color]
>>
>> And it's false. If, as has been revealed, C programs that use byte
>> indexing and addressing have to be substantially rewritten to accommodate
>> this product, how does the above "tweaking" remark accurately describe
>> this requirement?[/color]
>
> As I understand it, this issue only affects incompetent programmers who
> write code that assumes that bytes have eight bits.[/color]

No, the original prohibition to which I refer was provided by Mr. Abdullah,
who said:

<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."

************************************************** ***

Care to retract your argument now, or later?
[color=blue]
> The sort of
> programmers in whose code unions are "ubiquitous".[/color]

If you think unions are the work of the devil, why not argue for their
removal in some other thread? But *not* *here*, it is not the topic.

Since unions are not supported in the product being discussed, their
ubiquity is not the issue, and your argument is just that, nothing more.
Also, the only "union" supported in the product is to make two or more
references to the same integer-sized variable (language provided by Mr.
Abdullah). Therefore, in point of fact, the product cannot map two
distinct, same-size entities onto one another, which is what a "union"
should be capable of doing. This means that Mr. Abdullah's claims in this
specific regard are, like so many others, not correct.

In any case, your argument fails because, no matter what misconceptions a
prorgammer brings to the table, and according to Mr. Abdullah as quoted
above, none of them will work on this product unless "byte" is strictly
defined as having the same size as a Java native integer, which violates
the same rule you are trying to use as an argument -- bytes can have many
different sizes. In this product this requirement is not met.

If you intend to argue without thinking, don't bother to post.

--
Paul Lutus
http://www.arachnoid.com

In article <10nqamhfej8qqf5@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>Gerry Quinn wrote:[/color]
[color=blue][color=green]
>> As I understand it, this issue only affects incompetent programmers who
>> write code that assumes that bytes have eight bits.[/color]
>
>No, the original prohibition to which I refer was provided by Mr. Abdullah,
>who said:
>
><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."
>
>************************************************* ****
>
>Care to retract your argument now, or later?[/color]

....So it doesn't provide a byte-addressable memory model.

Care to provide a reference to support your claim that C requires a
byte-addressable memory model?

[color=blue]
>Since unions are not supported in the product being discussed, their
>ubiquity is not the issue, and your argument is just that, nothing more.
>Also, the only "union" supported in the product is to make two or more
>references to the same integer-sized variable (language provided by Mr.
>Abdullah). Therefore, in point of fact, the product cannot map two
>distinct, same-size entities onto one another, which is what a "union"
>should be capable of doing. This means that Mr. Abdullah's claims in this
>specific regard are, like so many others, not correct.[/color]

I haven't been following this thread too closely, but if I'm not mistaken,
union support was never claimed to be this limited (except by you).

What was claimed is that a float is the same size as an unsigned char;
the two distinct same-size entities that are mapped onto each other
by the union in your example are a single float and an array of one
unsigned char.

The fact that this implementation provides word-addressed memory and
every primitive type's size is a single word doesn't prevent anything
from aliasing any values with an array of unsigned char; it only means
that each primitive type can be aliased with a single unsigned char
(instead of an array of more than one unsigned char) that can be used
to determine the bit pattern.

[color=blue]
>In any case, your argument fails because, no matter what misconceptions a
>prorgammer brings to the table, and according to Mr. Abdullah as quoted
>above, none of them will work on this product unless "byte" is strictly
>defined as having the same size as a Java native integer, which violates
>the same rule you are trying to use as an argument -- bytes can have many
>different sizes. In this product this requirement is not met.[/color]

Does your favorite implementation allow bytes to have many different
sizes?

Bytes have a size that is fixed on a single implementation and can
vary between implementations. I don't think anybody is trying to claim
otherwise.

[color=blue]
>If you intend to argue without thinking, don't bother to post.[/color]

dave

--
Dave Vandervies dj3vande@csclub.uwaterloo.ca

Some of us even have a grip on reality. This is a university, remember?
--Giles Malet in uw.general

Dave Vandervies wrote:
[color=blue]
> In article <10nqamhfej8qqf5@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:[color=green]
>>Gerry Quinn wrote:[/color]
>[color=green][color=darkred]
>>> As I understand it, this issue only affects incompetent programmers who
>>> write code that assumes that bytes have eight bits.[/color]
>>
>>No, the original prohibition to which I refer was provided by Mr.
>>Abdullah, who said:
>>
>><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."
>>
>>************************************************ *****
>>
>>Care to retract your argument now, or later?[/color]
>
> ...So it doesn't provide a byte-addressable memory model.
>
> Care to provide a reference to support your claim that C requires a
> byte-addressable memory model?[/color]

Before you try to shift the burden of evidence, care to find where I made
this claim? Please do not drift the tread -- this is the easiest imaginable
activity, but it sheds no light on anyting.
[color=blue][color=green]
>>Since unions are not supported in the product being discussed, their
>>ubiquity is not the issue, and your argument is just that, nothing more.
>>Also, the only "union" supported in the product is to make two or more
>>references to the same integer-sized variable (language provided by Mr.
>>Abdullah). Therefore, in point of fact, the product cannot map two
>>distinct, same-size entities onto one another, which is what a "union"
>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>specific regard are, like so many others, not correct.[/color]
>
> I haven't been following this thread too closely, but if I'm not mistaken,
> union support was never claimed to be this limited (except by you).[/color]

The OP eventually admitted that all variables are mapped to Java native
integers -- all of them. This means there is no support for the property of
unions that they can conjoin two unrelated data types so long as their size
is adjusted to be the same.

If you think about Java's design, you will quickly realize there is no
support for directly conjoining any two variable types, because of strict
data typing, therefore the claim made by Mr. Abdullah:

<cl7gbh$7th$1@hood.uits.indiana.edu>

************************************************** *****************

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
the cause for this.**The*indexes*to*this*large*array*are*treated *as
addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.**Unions*are*supported."

************************************************** *****************

.... is false, because if everything is mapped to a native Java integer, the
property and primary value of unions is not provided.
[color=blue]
>
> What was claimed is that a float is the same size as an unsigned char;
> the two distinct same-size entities that are mapped onto each other
> by the union in your example are a single float and an array of one
> unsigned char.[/color]

But if they are both Java native integers, no mapping is taking place. If
there are two accesses to a simple integer value, the term "mapping" is not
appropriate, but if a C union is provided and two different data types are
mapped/conjoined, the term in appropriate.
[color=blue][color=green]
>>In any case, your argument fails because, no matter what misconceptions a
>>prorgammer brings to the table, and according to Mr. Abdullah as quoted
>>above, none of them will work on this product unless "byte" is strictly
>>defined as having the same size as a Java native integer, which violates
>>the same rule you are trying to use as an argument -- bytes can have many
>>different sizes. In this product this requirement is not met.[/color]
>
> Does your favorite implementation allow bytes to have many different
> sizes?[/color]

Now we have had the argument from both sides. Mr. Quinn thinks it silly that
someone would make any assumptions about the size of a byte, your position
is that it is silly to assume there is any signifgicant flexibility about
this. Maybe you should address Mr. Quinn's argument directly, as I was
doing.
[color=blue]
> Bytes have a size that is fixed on a single implementation and can
> vary between implementations. I don't think anybody is trying to claim
> otherwise.[/color]

True, and see above.

--
Paul Lutus
http://www.arachnoid.com

Paul wrote:
)> I haven't been following this thread too closely, but if I'm not mistaken,
)> union support was never claimed to be this limited (except by you).
)
) The OP eventually admitted that all variables are mapped to Java native
) integers -- all of them. This means there is no support for the property of
) unions that they can conjoin two unrelated data types so long as their size
) is adjusted to be the same.

That's an odd thing to say. Maybe I'm not reading you correctly, but you
seem to be saying that a union between a float and a long is not this
"conjoin two unrelated data types ..." business you speak of, and that
unions are primarily designed for you to split a float into chunks ?

) If you think about Java's design, you will quickly realize there is no
) support for directly conjoining any two variable types, because of strict
) data typing, therefore the claim made by Mr. Abdullah:
)
) <snip>
)
) ... is false, because if everything is mapped to a native Java integer, the
) property and primary value of unions is not provided.

On every single computer, everything is eventually mapped to a single data
type, namely the bit.

) But if they are both Java native integers, no mapping is taking place. If
) there are two accesses to a simple integer value, the term "mapping" is not
) appropriate, but if a C union is provided and two different data types are
) mapped/conjoined, the term in appropriate.

Again not making sense here. A float is mapped to a java integer by the
product, probably by some glue code. You seem to be claiming that a float
*is* an int in this case. Which is silly, because then you couldn't do
floating point math on it, could you ?

) Now we have had the argument from both sides. Mr. Quinn thinks it silly that
) someone would make any assumptions about the size of a byte, your position
) is that it is silly to assume there is any signifgicant flexibility about
) this. Maybe you should address Mr. Quinn's argument directly, as I was
) doing.

You're not having the argument from both sides, you're just not making
sense. Again. It's actually quite simple: The *platform* _dictates_ the
size of the byte, and the *programmer* has to be _flexible_ about the size
of the byte. Unless you're on a weird machine like a PDP-10 or something.

)> Bytes have a size that is fixed on a single implementation and can
)> vary between implementations. I don't think anybody is trying to claim
)> otherwise.
)
) True, and see above.

So if you admit this is true, then why did you make that silly argument
about how the product fixed the byte size ?

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Willem wrote:
[color=blue]
> Paul wrote:
> )> I haven't been following this thread too closely, but if I'm not
> mistaken, )> union support was never claimed to be this limited (except by
> you). )
> ) The OP eventually admitted that all variables are mapped to Java native
> ) integers -- all of them. This means there is no support for the property
> of ) unions that they can conjoin two unrelated data types so long as
> their size ) is adjusted to be the same.
>
> That's an odd thing to say. Maybe I'm not reading you correctly, but you
> seem to be saying that a union between a float and a long is not this
> "conjoin two unrelated data types ..." business you speak of, and that
> unions are primarily designed for you to split a float into chunks ?[/color]

1. In C, unions can be used to do what you suggest, this is not their only
purpose. My original example program did just that, but the result using
this product didn't.

2. The product being discussed doesn't map different data types together. It
reads the original C program and (according to the OP) creates everything
using native Java integer data types. What this means in practice is that,
on the Java side, it does not map a float and a long together, for a number
of reasons, not least of which is that Java will not allow this.

So the OP's claim the "unions are spported" is false. One cannot map, as in
the original example, a float and a byte array, as one can do in C. In this
scheme both are turned into Java native integers, so any references to one
or the other read from a single instance of a Java native integer. IOW the
same entity is being accessed in the same way.
[color=blue]
>
> ) If you think about Java's design, you will quickly realize there is no
> ) support for directly conjoining any two variable types, because of
> strict ) data typing, therefore the claim made by Mr. Abdullah:
> )
> ) <snip>
> )
> ) ... is false, because if everything is mapped to a native Java integer,
> the ) property and primary value of unions is not provided.
>
> On every single computer, everything is eventually mapped to a single data
> type, namely the bit.[/color]

Could you please stop posting these wonderful, albeit tautological,
arguments? Or, alternative, ask yourself how much light is shed on this or
any topic through such arguments?
[color=blue]
> ) But if they are both Java native integers, no mapping is taking place.
> If ) there are two accesses to a simple integer value, the term "mapping"
> is not ) appropriate, but if a C union is provided and two different data
> types are ) mapped/conjoined, the term in appropriate.[/color]

You really need to set up your newsreader properly. Use this post as an
example of standard quoting style.
[color=blue]
>
> Again not making sense here. A float is mapped to a java integer by the
> product, probably by some glue code.[/color]

This is false. A float is not mapped to an integer. According to the OP, an
integer is "mapped" to an integer, in fact, it is the same integer. In any
case, Java is strongly typed and will not allow what you suggest.
[color=blue]
> You seem to be claiming that a float
> *is* an int in this case.[/color]

No, the OP claimed this. Perhaps you could read the posted data before
posting.
[color=blue]
> Which is silly, because then you couldn't do
> floating point math on it, could you ?[/color]

False again. Programmers can do this, and in this case will be required to
do it, because Java will not accommodate a revolving door between integers
and floats.
[color=blue]
>
> ) Now we have had the argument from both sides. Mr. Quinn thinks it silly
> that ) someone would make any assumptions about the size of a byte, your
> position ) is that it is silly to assume there is any signifgicant
> flexibility about ) this. Maybe you should address Mr. Quinn's argument
> directly, as I was ) doing.
>
> You're not having the argument from both sides, you're just not making
> sense. Again. It's actually quite simple: The *platform* _dictates_ the
> size of the byte, and the *programmer* has to be _flexible_ about the size
> of the byte. Unless you're on a weird machine like a PDP-10 or something.[/color]

Try reading your own sentences before posting, theh delete the ones that
don't make any sense. This will have a salutary effect on the length of
your posts. When I said earlier that there was little flexibility about the
size of bytes, you argued the opposite position -- that bytes could have
any size. Now you argue that there is little flexibility about the size of
bytes, for which I can only add, read the thread more carefully and try to
avoid revesing your position so readily.
[color=blue]
> )> Bytes have a size that is fixed on a single implementation and can
> )> vary between implementations. I don't think anybody is trying to claim
> )> otherwise.
> )
> ) True, and see above.
>
> So if you admit this is true, then why did you make that silly argument
> about how the product fixed the byte size ?[/color]

That argument was made by Mr. Abdullah, not my me, and it is time for you to
do you own reading:

<cl7gbh$7th$1@hood.uits.indiana.edu>

************************************************** *****************

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
the cause for this.**The*indexes*to*this*large*array*are*treated *as
addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.**Unions*are*supported."

************************************************** *****************

Translation: "Unions are not supported, instead everything is translated
into an integer".

--
Paul Lutus
http://www.arachnoid.com

Willem wrote:
[color=blue]
> Paul wrote:
> )> I haven't been following this thread too closely, but if I'm not
> mistaken, )> union support was never claimed to be this limited (except by
> you). )
> ) The OP eventually admitted that all variables are mapped to Java native
> ) integers -- all of them. This means there is no support for the property
> of ) unions that they can conjoin two unrelated data types so long as
> their size ) is adjusted to be the same.
>
> That's an odd thing to say.**Maybe*I'm*not*reading*you*correctly,*but*you
> seem to be saying that a union between a float and a long is not this
> "conjoin two unrelated data types ..." business you speak of, and that
> unions are primarily designed for you to split a float into chunks ?[/color]

1. In C, unions can be used to do what you suggest, this is not their only
purpose. My original example program did just that, but the result using
this product didn't.

2. The product being discussed doesn't map different data types together. It
reads the original C program and (according to the OP) creates everything
using native Java integer data types. What this means in practice is that,
on the Java side, it does not map a float and a long together, for a number
of reasons, not least of which is that Java will not allow this.

So the OP's claim the "unions are spported" is false. One cannot map, as in
the original example, a float and a byte array, as one can do in C. In this
scheme both are turned into Java native integers, so any references to one
or the other read from a single instance of a Java native integer. IOW the
same entity is being accessed in the same way.
[color=blue]
>
> ) If you think about Java's design, you will quickly realize there is no
> ) support for directly conjoining any two variable types, because of
> strict ) data typing, therefore the claim made by Mr. Abdullah:
> )
> )**<snip>
> )
> ) ... is false, because if everything is mapped to a native Java integer,
> the ) property and primary value of unions is not provided.
>
> On every single computer, everything is eventually mapped to a single data
> type, namely the bit.[/color]

Could you please stop posting these wonderful, albeit tautological,
arguments? Or, alternative, ask yourself how much light is shed on this or
any topic through such arguments?
[color=blue]
> ) But if they are both Java native integers, no mapping is taking place.
> If ) there are two accesses to a simple integer value, the term "mapping"
> is not ) appropriate, but if a C union is provided and two different data
> types are ) mapped/conjoined, the term in appropriate.[/color]

You really need to set up your newsreader properly. Use this post as an
example of standard quoting style.
[color=blue]
>
> Again not making sense here.**A*float*is*mapped*to*a*java*integer*by*the
> product, probably by some glue code.[/color]

This is false. A float is not mapped to an integer. According to the OP, an
integer is "mapped" to an integer, in fact, it is the same integer. In any
case, Java is strongly typed and will not allow what you suggest.
[color=blue]
> You seem to be claiming that a float
> is an int in this case.[/color]

No, the OP claimed this. Perhaps you could read the posted data before
posting.
[color=blue]
> Which is silly, because then you couldn't do
> floating point math on it, could you ?[/color]

False again. Programmers can do this, and in this case will be required to
do it, because Java will not accommodate a revolving door between integers
and floats.
[color=blue]
>
> ) Now we have had the argument from both sides. Mr. Quinn thinks it silly
> that ) someone would make any assumptions about the size of a byte, your
> position ) is that it is silly to assume there is any signifgicant
> flexibility about ) this. Maybe you should address Mr. Quinn's argument
> directly, as I was ) doing.
>
> You're not having the argument from both sides, you're just not making
> sense.**Again.**It's*actually*quite*simple:**The*p latform*dictates*the
> size of the byte, and the programmer has to be flexible about the size
> of the byte.**Unless*you're*on*a*weird*machine*like*a*PDP-10*or*something.[/color]

Try reading your own sentences before posting, theh delete the ones that
don't make any sense. This will have a salutary effect on the length of
your posts. When I said earlier that there was little flexibility about the
size of bytes, you argued the opposite position -- that bytes could have
any size. Now you argue that there is little flexibility about the size of
bytes, for which I can only add, read the thread more carefully and try to
avoid revesing your position so readily.
[color=blue]
> )> Bytes have a size that is fixed on a single implementation and can
> )> vary between implementations.**I*don't*think*anybody*is*trying* to*claim
> )> otherwise.
> )
> ) True, and see above.
>
> So if you admit this is true, then why did you make that silly argument
> about how the product fixed the byte size ?[/color]

That argument was made by Mr. Abdullah, not my me, and it is time for you to
do you own reading:

<cl7gbh$7th$1@hood.uits.indiana.edu>

************************************************** *****************

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
the cause for this.**The*indexes*to*this*large*array*are*treated *as
addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.**Unions*are*supported."

************************************************** *****************

Translation: "Unions are not supported, instead everything is translated
into an integer".

--
Paul Lutus
http://www.arachnoid.com

In article <10nqj6r9cavr842@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
[color=blue]
>So the OP's claim the "unions are spported" is false. One cannot map, as in
>the original example, a float and a byte array, as one can do in C. In this
>scheme both are turned into Java native integers, so any references to one
>or the other read from a single instance of a Java native integer. IOW the
>same entity is being accessed in the same way.[/color]

And on the 386 running the web server in my closet, the C implementation
doesn't support unions; one cannot map a float and a byte array, because
both are turned into the processor's native bytes, so any references to
one or the other read from a single set of the processor's native bytes;
IOW the same entity is being accessed in the same way.

[I don't actually have a 386 running a web server in my closet, but
it's not at all an unreasonable thing to expect, and it's really no
different from a JVM; any floating-point operations are done by the
runtime environment and not the underlying hardware, just as the C-on-JVM
implementation under discussion appears to do.]

Where the data is stored doesn't make it a float; how it's treated does.
If you can stuff the value 42 in and look at the bit pattern and see `00
00 28 42', you have something that (for this value at least) acts like
a 32-bit IEEE floating point number, and you DO NOT have a Java integer.

There's nothing stopping a C implementation from storing its floating
point values in a processor's native bytes, or in Java integers, or in
a cave somewhere in Antarctica (well, perhaps common sense and physical
laws, but nothing in the definition of the language), as long as an
attempt to look at the bytes AS DEFINED IN THE DEFINITION OF THE LANGUAGE
(which allows them to be 32 bits long, f'rexample for a word-addressed
platform) that make up that float succeeds and gives reasonable values.

[color=blue][color=green]
>> Again not making sense here.**A*float*is*mapped*to*a*java*integer*by*the
>> product, probably by some glue code.[/color]
>
>This is false. A float is not mapped to an integer. According to the OP, an
>integer is "mapped" to an integer, in fact, it is the same integer. In any
>case, Java is strongly typed and will not allow what you suggest.[/color]

A float is represented by a bit pattern that happens to be stored in a
Java integer.
An int is represented by a bit pattern that happens to be stored in a
Java integer.

Is this really that difficult to understand?

[color=blue][color=green]
>> Which is silly, because then you couldn't do
>> floating point math on it, could you ?[/color]
>
>False again. Programmers can do this, and in this case will be required to
>do it, because Java will not accommodate a revolving door between integers
>and floats.[/color]

I see no revolving door here; I see a particular method of storing
bits being used to store bits that happen to be the representation of
a floating point value.

[color=blue][color=green]
>> )> Bytes have a size that is fixed on a single implementation and can
>> )> vary between implementations.**I*don't*think*anybody*is*trying* to*claim
>> )> otherwise.
>> )
>> ) True, and see above.
>>
>> So if you admit this is true, then why did you make that silly argument
>> about how the product fixed the byte size ?[/color]
>
>That argument was made by Mr. Abdullah, not my me, and it is time for you to
>do you own reading:
>
><cl7gbh$7th$1@hood.uits.indiana.edu>
>
>************************************************* ******************
>
>"The size of each char, int, long, or float is 1 word (32 bits long).
>So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
>you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
>the cause for this.**The*indexes*to*this*large*array*are*treated *as
>addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
>And programs that assume a byte-addressable architecture will need to be
>modified to suit the one used by MPC.**Unions*are*supported."
>
>************************************************* ******************
>
>Translation: "Unions are not supported, instead everything is translated
>into an integer".[/color]

Everything is translated into bit patterns that can be stored in an
integer. (Call it a "virtual machine word" if calling it an integer
bothers you.)

Just like on an implementation for a general-purpose hardware processor,
everything is translated into bit patterns that can be stored in a set
of memory bytes.

By your logic, the compiler I use on the workstation in front of
me doesn't support unions; instead, everything is translated into a
string of bytes, and if I try to look at something with a union it's
just reading from a single instance of that string of bytes.

Are you really so thick you're still not getting this, or are you just
pathologically unable to admit that you might be wrong about something?

dave

--
Dave Vandervies dj3vande@csclub.uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

In article <10nqefd36j5pod2@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>Dave Vandervies wrote:
>[color=green]
>> In article <10nqamhfej8qqf5@corp.supernews.com>,
>> Paul Lutus <nospam@nosite.zzz> wrote:[color=darkred]
>>>Gerry Quinn wrote:[/color]
>>[color=darkred]
>>>> As I understand it, this issue only affects incompetent programmers who
>>>> write code that assumes that bytes have eight bits.
>>>
>>>No, the original prohibition to which I refer was provided by Mr.
>>>Abdullah, who said:
>>>
>>><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."
>>>
>>>*********************************************** ******
>>>
>>>Care to retract your argument now, or later?[/color]
>>
>> ...So it doesn't provide a byte-addressable memory model.
>>
>> Care to provide a reference to support your claim that C requires a
>> byte-addressable memory model?[/color]
>
>Before you try to shift the burden of evidence, care to find where I made
>this claim? Please do not drift the tread -- this is the easiest imaginable
>activity, but it sheds no light on anyting.[/color]

A few lines above in the quoted material, you present the fact that
code requiring a byte-addressable memory model will not work with this
implementation as support for your claim that this implementation imposes
unreasonable constraints on the programmer.

Unless you can demonstrate that C requires a byte-addressable memory
model, your complaint is with the language, not with the implementation.

[color=blue][color=green][color=darkred]
>>>Since unions are not supported in the product being discussed, their
>>>ubiquity is not the issue, and your argument is just that, nothing more.
>>>Also, the only "union" supported in the product is to make two or more
>>>references to the same integer-sized variable (language provided by Mr.
>>>Abdullah). Therefore, in point of fact, the product cannot map two
>>>distinct, same-size entities onto one another, which is what a "union"
>>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>>specific regard are, like so many others, not correct.[/color]
>>
>> I haven't been following this thread too closely, but if I'm not mistaken,
>> union support was never claimed to be this limited (except by you).[/color]
>
>The OP eventually admitted that all variables are mapped to Java native
>integers -- all of them. This means there is no support for the property of
>unions that they can conjoin two unrelated data types so long as their size
>is adjusted to be the same.[/color]

Really? What's stopping it? Is it really that difficult to treat a bit
pattern as a float when you store it and then treat it as an unsigned
char when you retreive it?
They're not stored "as integers"; they're stored in an array of integers
that gets treated as a word-addressed memory space. The same way an
implementation producing code for an Intel processor stores its variables
in an array of bytes that gets treated as a byte-addressed memory space.

[color=blue]
>If you think about Java's design, you will quickly realize there is no
>support for directly conjoining any two variable types, because of strict
>data typing,[/color]

....which invalidates the claim that this is a C-to-Java translator in
the sense that it outputs Java code that runs directly on the JVM.

It does NOT invalidate the claim that this is a C implementation targeting
the JVM, with runtime code that treats a large array of Java integers
as a word-addressable memory space.

[color=blue][color=green]
>> What was claimed is that a float is the same size as an unsigned char;
>> the two distinct same-size entities that are mapped onto each other
>> by the union in your example are a single float and an array of one
>> unsigned char.[/color]
>
>But if they are both Java native integers, no mapping is taking place. If
>there are two accesses to a simple integer value, the term "mapping" is not
>appropriate, but if a C union is provided and two different data types are
>mapped/conjoined, the term in appropriate.[/color]

They're not Java native integers. They're values that happen to be
represented by a 32-bit word, that happens to fit nicely in a Java
integer.

[color=blue][color=green][color=darkred]
>>>In any case, your argument fails because, no matter what misconceptions a
>>>prorgammer brings to the table, and according to Mr. Abdullah as quoted
>>>above, none of them will work on this product unless "byte" is strictly
>>>defined as having the same size as a Java native integer, which violates
>>>the same rule you are trying to use as an argument -- bytes can have many
>>>different sizes. In this product this requirement is not met.[/color]
>>
>> Does your favorite implementation allow bytes to have many different
>> sizes?[/color]
>
>Now we have had the argument from both sides. Mr. Quinn thinks it silly that
>someone would make any assumptions about the size of a byte, your position
>is that it is silly to assume there is any signifgicant flexibility about
>this. Maybe you should address Mr. Quinn's argument directly, as I was
>doing.[/color]

Implementations need not be flexible; a C implementation is constrained
only by the requirement that CHAR_BIT be not less than 8.

This means that, by assuming a byte-addressed memory model with 8-bit
bytes, a programmer is restricting the set of implementations their code
works on to those that match that assumption, which is a proper subset
of "all C implementations". If not being able to read word-addressed
memory a byte at a time bothers you, your choices are to restrict your
selection of implementations to those that match your assumptions or
to remove byte-addressibility from the list of things you expect from
word-addressed implementations.

dave

--
Dave Vandervies dj3vande@csclub.uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

Dave Vandervies wrote:
[color=blue]
> In article <10nqj6r9cavr842@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
>[color=green]
>>So the OP's claim the "unions are spported" is false. One cannot map, as
>>in the original example, a float and a byte array, as one can do in C. In
>>this scheme both are turned into Java native integers, so any references
>>to one or the other read from a single instance of a Java native integer.
>>IOW the same entity is being accessed in the same way.[/color]
>
> And on the 386 running the web server in my closet, the C implementation
> doesn't support unions;[/color]

Please do not leave the topic, and try to avoid invention to support your
argument. Unions are part of ANSI C.
[color=blue]
> one cannot map a float and a byte array, because
> both are turned into the processor's native bytes,[/color]

If the compiler is ANSI C compliant, my example program will compile on that
compiler and run on that plartform. Unions are supported by C, they are not
supported by Java, and they are not supported by the program under
discussion.
[color=blue]
> so any references to
> one or the other read from a single set of the processor's native bytes;
> IOW the same entity is being accessed in the same way.[/color]

Just stop posting. You want to argue, not think, fortunately for you there
are plenty of suitable newsgroups for this onanistic activity.
[color=blue]
>
> [I don't actually have a 386 running a web server in my closet, but
> it's not at all an unreasonable thing to expect, and it's really no
> different from a JVM; any floating-point operations are done by the
> runtime environment and not the underlying hardware, just as the C-on-JVM
> implementation under discussion appears to do.]
>
> Where the data is stored doesn't make it a float; how it's treated does.[/color]

This discussion unfortunately is not just about C, it is about C and Java.
Java does not agree wth you. Floats are treated as a unique data type, and
mixing of data types, as for example in a union, is not allowed in Java.
[color=blue]
> If you can stuff the value 42 in and look at the bit pattern and see `00
> 00 28 42', you have something that (for this value at least) acts like
> a 32-bit IEEE floating point number, and you DO NOT have a Java integer.[/color]

At which word did your brain go offline? Post the stack dump.

If you read a thread like this, and you have nothing to contribute, do not
reply. It is a simple rule.

/ ...
[color=blue]
> A float is represented by a bit pattern that happens to be stored in a
> Java integer.
> An int is represented by a bit pattern that happens to be stored in a
> Java integer.[/color]

Java recognizes that a float and an integer are different data types, and
refuses them to be freely mixed, as C allows in a union. This is wy the OP
chose to make all the data types the same. This is why his product does not
suppoert doubles at all -- he had some hard choices to make.

On the topic of hard choices, is there a timetable for you to bring your
brain back on line?

--
Paul Lutus
http://www.arachnoid.com

Paul wrote:
) Willem wrote:
)> That's an odd thing to say.**Maybe*I'm*not*reading*you*correctly,*but*you
)> seem to be saying that a union between a float and a long is not this
)> "conjoin two unrelated data types ..." business you speak of, and that
)> unions are primarily designed for you to split a float into chunks ?
)
) 1. In C, unions can be used to do what you suggest, this is not their only
) purpose. My original example program did just that, but the result using
) this product didn't.

I would say that chopping op a float into chunks is usually only used in
'hackish' code, and probably falls under the 'undefined behaviour' clause.

) So the OP's claim the "unions are spported" is false. One cannot map, as in
) the original example, a float and a byte array, as one can do in C. In this
) scheme both are turned into Java native integers, so any references to one
) or the other read from a single instance of a Java native integer. IOW the
) same entity is being accessed in the same way.

I really don't understand what you're saying here. Firstly, one can most
certainly map a float and a byte array. That the array has a different
size is not relevant to that.

)> On every single computer, everything is eventually mapped to a single data
)> type, namely the bit.
)
) Could you please stop posting these wonderful, albeit tautological,
) arguments? Or, alternative, ask yourself how much light is shed on this or
) any topic through such arguments?

I just wanted to point out that your argument about floats and bytes being
mapped to integers is stupid, because on most computers, as I just wrote,
they are also being mapped to a single something.
I assume you understood that perfectly and, unable to respond to the actual
argument, chose this ad hominem approach instead.

)> ) But if they are both Java native integers, no mapping is taking place.
)> If ) there are two accesses to a simple integer value, the term "mapping"
)> is not ) appropriate, but if a C union is provided and two different data
)> types are ) mapped/conjoined, the term in appropriate.
)
) You really need to set up your newsreader properly. Use this post as an
) example of standard quoting style.

Your newsreader and/or editor is the one that rewraps the lines, not mine.
If you're complaining about my use of a closing paren instead of a
greater-than, then your complaint is noted and ignored.

)> Again not making sense here. A float is mapped to a java integer by
)> the product, probably by some glue code.
)
) This is false. A float is not mapped to an integer. According to the OP, an
) integer is "mapped" to an integer, in fact, it is the same integer. In any
) case, Java is strongly typed and will not allow what you suggest.

Your claim about what else is mapped to an integer is meaningless.
The actual question is what do you claim happens with the float ?

)> You seem to be claiming that a float
)> is an int in this case.
)
) No, the OP claimed this. Perhaps you could read the posted data before
) posting.

The OP claimed that all data types are represented as integers, not that
they are treated the same. Heed your own words.

)> Which is silly, because then you couldn't do
)> floating point math on it, could you ?
)
) False again. Programmers can do this, and in this case will be required to
) do it, because Java will not accommodate a revolving door between integers
) and floats.

According to the OP, his product does do floating point math on the
floating point numbers even though they are represented as integers.

)> You're not having the argument from both sides, you're just not making
)> sense. Again. It's actually quite simple: The platform dictates the
)> size of the byte, and the programmer has to be flexible about the size
)> of the byte. Unless you're on a weird machine like a PDP-10 or something.
)
) Try reading your own sentences before posting, theh delete the ones that
) don't make any sense. This will have a salutary effect on the length of
) your posts. When I said earlier that there was little flexibility about the
) size of bytes, you argued the opposite position -- that bytes could have
) any size. Now you argue that there is little flexibility about the size of
) bytes, for which I can only add, read the thread more carefully and try to
) avoid revesing your position so readily.

You must be trolling, because in the very sentence above this, I said quite
clearly what my position is, which involves both flexibility in byte sizes
(on the part of the programmer) and inflexibility in byte sizes (on the
part of the platform).

If you fail to apply context to arguments, then obviously they will make
little sense. This only shows that you're either too stupid to read the
context in which arguments are made, or that you're deliberately
misinterpreting me. Which, IMO, is also stupid.

)> So if you admit this is true, then why did you make that silly argument
)> about how the product fixed the byte size ?
)
) That argument was made by Mr. Abdullah, not my me, and it is time for you to
) do you own reading:

You may want to reread what I wrote.
I did not say 'argument that the product',
I said 'argument about how the product'.
That means that I was talking about your response to the
argument you quoted below.

)<cl7gbh$7th$1@hood.uits.indiana.edu>
)
) ************************************************** *****************
)
) "The size of each char, int, long, or float is 1 word (32 bits long).
) So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
) you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
) the cause for this.**The*indexes*to*this*large*array*are*treated *as
) addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
) And programs that assume a byte-addressable architecture will need to be
) modified to suit the one used by MPC.**Unions*are*supported."
)
) ************************************************** *****************
)
) Translation: "Unions are not supported, instead everything is translated
) into an integer".

I fail to see where you get this weird translation from.
You must think that the sole purpose of a union is to be able to chop up
certain data types into chunks.
This must also mean that you think a union between a float and an int is
completely useless, and actually not even a union.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Dave Vandervies wrote:
[color=blue]
> In article <10nqefd36j5pod2@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:[color=green]
>>Dave Vandervies wrote:[/color][/color]

/ ...
[color=blue][color=green][color=darkred]
>>> Care to provide a reference to support your claim that C requires a
>>> byte-addressable memory model?[/color]
>>
>>Before you try to shift the burden of evidence, care to find where I made
>>this claim? Please do not drift the tread -- this is the easiest
>>imaginable activity, but it sheds no light on anyting.[/color]
>
> A few lines above in the quoted material, you present the fact that
> code requiring a byte-addressable memory model will not work with this
> implementation as support for your claim that this implementation imposes
> unreasonable constraints on the programmer.[/color]

Post the quote in which I used these words, or retract the claim. I never
said what you claim I said.
[color=blue]
> Unless you can demonstrate that C requires a byte-addressable memory
> model, your complaint[/color]

The quote on wuich you are relying is an invention of yours. I never used
the words you posted. Start retracting and apologizing for misquoting now.

Mr. Abdullah made this statement, I did not. He said:

<cl7gbh$7th$1@hood.uits.indiana.edu>

************************************************** *****************

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
the cause for this.**The*indexes*to*this*large*array*are*treated *as
addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.**Unions*are*supported."

************************************************** *****************

/ ...
[color=blue][color=green]
>>The OP eventually admitted that all variables are mapped to Java native
>>integers -- all of them. This means there is no support for the property
>>of unions that they can conjoin two unrelated data types so long as their
>>size is adjusted to be the same.[/color]
>
> Really? What's stopping it? Is it really that difficult to treat a bit
> pattern as a float when you store it and then treat it as an unsigned
> char when you retreive it?[/color]

This is not a tutorial about Java, and you can do your own reading. In any
case, I never made the claim, the OP did.
[color=blue]
> They're not stored "as integers";[/color]

They are stored as Java native integers.
[color=blue]
> they're stored in an array of integers
> that gets treated as a word-addressed memory space.[/color]

Onanism.

/ ...
[color=blue][color=green]
>>If you think about Java's design, you will quickly realize there is no
>>support for directly conjoining any two variable types, because of strict
>>data typing,[/color]
>
> ...which invalidates the claim that this is a C-to-Java translator in
> the sense that it outputs Java code that runs directly on the JVM.[/color]

Yes, correct, therefore the OP's claims are false.
[color=blue]
> It does NOT invalidate the claim that this is a C implementation targeting
> the JVM, with runtime code that treats a large array of Java integers
> as a word-addressable memory space.[/color]

Ther OP made false claims both here and on his Web site. I said the claims
were false. At which point did you lose track of the topic?
[color=blue][color=green][color=darkred]
>>> What was claimed is that a float is the same size as an unsigned char;
>>> the two distinct same-size entities that are mapped onto each other
>>> by the union in your example are a single float and an array of one
>>> unsigned char.[/color]
>>
>>But if they are both Java native integers, no mapping is taking place. If
>>there are two accesses to a simple integer value, the term "mapping" is
>>not appropriate, but if a C union is provided and two different data types
>>are mapped/conjoined, the term in appropriate.[/color]
>
> They're not Java native integers.[/color]

In fact, that is exactly what they are. The term "native" in Java has a
different meaning than you may be familiar with.
[color=blue]
> They're values that happen to be
> represented by a 32-bit word, that happens to fit nicely in a Java
> integer.[/color]

They are Java native integers, as distinct from java Integer class
instances.

/ ...
[color=blue]
> This means that, by assuming a byte-addressed memory model with 8-bit
> bytes, a programmer is restricting the set of implementations their code
> works on to those that match that assumption, which is a proper subset
> of "all C implementations". If not being able to read word-addressed
> memory a byte at a time bothers you,[/color]

It doesn't bother me, it bothers the OP. His program cannot do it. He
requires programmers to rewrite their C programs to accommmodate his
program.

At which word, in which post, did you lose track of the topic?

--
Paul Lutus
http://www.arachnoid.com

In article <cljnfj$htm$1@rumours.uwaterloo.ca>,
Dave Vandervies <dj3vande@csclub.uwaterloo.ca> wrote:
[color=blue]
>Find a word-addressed processor that does 32-bit chars and 32-bit floats
>in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
>a Cray-1 or a DSP.)[/color]

Note that 64-bit words and CHAR_BIT==64 is also acceptable. (Requiring 32
would invalidate the use of a Cray-1 as an example.)

dave

--
Dave Vandervies dj3vande@csclub.uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

In article <10nqmt2okb8hnec@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:
[color=blue]
>If the compiler is ANSI C compliant, my example program will compile on that
>compiler and run on that plartform. Unions are supported by C, they are not
>supported by Java, and they are not supported by the program under
>discussion.[/color]

Fine.

Find a word-addressed processor that does 32-bit chars and 32-bit floats
in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
a Cray-1 or a DSP.)

Run your code snippet on it and tell us what you get back.

If you get more than one "byte" printed out (and can verify that my
conditions are met), I'll concede the point.

If you get a single "byte" printed out, then tell us why that
implementation doesn't support unions.

If this is too much trouble, you're clearly not interested in paying
attention to what I'm saying and reading for comprehension, so there's
no point in me continuing.

dave

--
Dave Vandervies dj3vande@csclub.uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

Dave Vandervies wrote:
[color=blue]
> In article <10nqmt2okb8hnec@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:
>[color=green]
>>If the compiler is ANSI C compliant, my example program will compile on
>>that compiler and run on that plartform. Unions are supported by C, they
>>are not supported by Java, and they are not supported by the program under
>>discussion.[/color]
>
> Fine.
>
> Find a word-addressed processor that does 32-bit chars and 32-bit floats
> in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
> a Cray-1 or a DSP.)[/color]

When you are ready to address the topic of this thread, post again.

/ ...
[color=blue]
> If this is too much trouble, you're clearly not interested in paying
> attention to what I'm saying ...[/color]

When you are ready to address the topic of this thread, post again.
[color=blue]
> and reading for comprehension, so there's
> no point in me continuing.[/color]

There is no point in your valiant attempts to move this thread from its
topic.

--
Paul Lutus
http://www.arachnoid.com

"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10nqmt2okb8hnec@corp.supernews.com...
[snip][color=blue]
> If the compiler is ANSI C compliant, my example program will compile on
> that compiler and run on that plartform. Unions are supported by C, they
> are not supported by Java, and they are not supported by the program
> under discussion.[/color]

From these statements, I infer that you have an example program which
demonstrates that unions are not supported. Is this correct? And if so, what
is this example program?

Do you have any other evidence on which you base the claim above? And if so,
what is it?

Alex

Alex Fraser wrote:
[color=blue]
> "Paul Lutus" <nospam@nosite.zzz> wrote in message
> news:10nqmt2okb8hnec@corp.supernews.com...
> [snip][color=green]
>> If the compiler is ANSI C compliant, my example program will compile on
>> that compiler and run on that plartform. Unions are supported by C, they
>> are not supported by Java, and they are not supported by the program
>> under discussion.[/color]
>
> From these statements, I infer that you have an example program which
> demonstrates that unions are not supported. Is this correct? And if so,
> what is this example program?[/color]

1. The OP, unhappy with the original thread and eager to get some additional
free publicity for his commercial product, created a new thread. The old
thread has the same name and starts here:

<a9083a87.0410141937.1a7d4e1d@posting.google.com >

2. Java does not support the mapping of one variable type onto another.

3. The product in question solves this problem by turning everything into a
32-bit word, this making the "union" issue moot, since there is no point
creating a union betweeen a thing and itself.

The basic issue is that the disparate data types that can be mapped using
"union" in C, cannot be mapped at all in Java (because of the latter's
strong data typing). The OP solved this problem by making all data into
32-bit words.
[color=blue]
>
> Do you have any other evidence on which you base the claim above?[/color]

Please take the time to read this and the prior thread before raising closed
issues.
[color=blue]
> And if
> so, what is it?[/color]

*sigh*

<cl7gbh$7th$1@hood.uits.indiana.edu>

************************************************** *****************

"The size of each char, int, long, or float is 1 word (32 bits long).
So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
the cause for this.**The*indexes*to*this*large*array*are*treated *as
addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
And programs that assume a byte-addressable architecture will need to be
modified to suit the one used by MPC.**Unions*are*supported."

************************************************** *****************

If, as the OP claims, all data are 32-bit words, then the claim that unions
are supported is false, since (1) Java will not allow disparate data types
to be overlaid in memory, and (2) a union's purpose is the mapping of
disparate data types, and there aren't any disparate data types.

BTW there is also no support for anything that requires fewer or more than
32 bits, e.g no support for typical doubles as just one example.

--
Paul Lutus
http://www.arachnoid.com

In article <10nqq7cnnsv8525@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>Dave Vandervies wrote:
>[color=green]
>> In article <10nqmt2okb8hnec@corp.supernews.com>,
>> Paul Lutus <nospam@nosite.zzz> wrote:
>>[color=darkred]
>>>If the compiler is ANSI C compliant, my example program will compile on
>>>that compiler and run on that plartform. Unions are supported by C, they
>>>are not supported by Java, and they are not supported by the program under
>>>discussion.[/color]
>>
>> Fine.
>>
>> Find a word-addressed processor that does 32-bit chars and 32-bit floats
>> in hardware, with a C implementation that has CHAR_BIT==32. (F'rexample,
>> a Cray-1 or a DSP.)[/color]
>
>When you are ready to address the topic of this thread, post again.[/color]

I'm attempting to address the suitability of using an array of 32-bit
values to store values of varying types and use a union to convert
between the values stored there.

Since that's obviously not what you think the topic of this thread is,
there's not much point in me continuing.

This thread is going in the killfile as soon as I post this article.
This means you can claim I'm wrong, accuse me of onanism, and refuse to
accept that you might not know everything all you want, and I promise
not to reply unless somebody changes the subject line.

dave

--
Dave Vandervies dj3vande@csclub.uwaterloo.ca
[T]ry thinking someday. It might hurt a little at first, but you'll
be glad in retrospect.
--Joona I Palaste roasts a troll in comp.lang.c

Dave Vandervies wrote:
[color=blue]
> In article <10nqq7cnnsv8525@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:[/color]

/ ...
[color=blue][color=green]
>>When you are ready to address the topic of this thread, post again.[/color]
>
> I'm attempting to address the suitability of using an array of 32-bit
> values to store values of varying types and use a union to convert
> between the values stored there.[/color]

That is not the topic, and you need to find out what "thread drift" refers
to. You are always free to start any thread, on any topic, in any suitable
newsgroup. For this thread, a thread originated and cross-posted to four
nearly unrelated newsgroups by an unscrupulous commercial vendor eager for
free publicity, you have limited options other than addressing the topic.
[color=blue]
> Since that's obviously not what you think the topic of this thread is,[/color]

I did not start this thread, cross-post it, or choose its topic.
[color=blue]
> there's not much point in me continuing.[/color]

There is not much point in your continuing.
[color=blue]
> This thread is going in the killfile as soon as I post this article.[/color]

Why not before?
[color=blue]
> This means you can claim I'm wrong,[/color]

Post the quote of the statement you falsely claim I made, or retract your
false claim. Never invent statements for other people. I never said what
you claim, the ball is in your court, we won't hold our breath.

grep "wrong" (this thread) || echo "No evidence, no argument."
[color=blue]
> accuse me of onanism, and refuse to
> accept that you might not know everything all you want,[/color]

"Everything all you want"? I was right, your brain really is offline.
[color=blue]
> and I promise
> not to reply unless somebody changes the subject line.[/color]

We'll see.

--
Paul Lutus
http://www.arachnoid.com

Paul Lutus <nospam@nosite.zzz> writes:
[...][color=blue]
> ************************************************** *****************
>
> "The size of each char, int, long, or float is 1 word (32 bits long).
> So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
> you got the idea.**Using*a*large*array*of*int*to*mimic*address able*memory*is
> the cause for this.**The*indexes*to*this*large*array*are*treated *as
> addresses.**This*memory*is*word-addressable*and*not*byte-addressable.
> And programs that assume a byte-addressable architecture will need to be
> modified to suit the one used by MPC.**Unions*are*supported."
>
> ************************************************** *****************[/color]

If char is 32 bits, then a byte, as C uses the word, is 32 bits.
In that sense, the system is byte-addressable, even though it's not
octet-addressable.
[color=blue]
> If, as the OP claims, all data are 32-bit words, then the claim that unions
> are supported is false, since (1) Java will not allow disparate data types
> to be overlaid in memory, and (2) a union's purpose is the mapping of
> disparate data types, and there aren't any disparate data types.[/color]

Of course there are disparate data types. int and float may be the
same size, but they're distinct types with different representations.
If the implementation doesn't let you view a float as an array of
unsigned char (an array of length 1 in this case), then it's
non-conforming. And I would expect any reasonable C implementation to
let you look at the representation of a floating-point type by using a
union to alias it to an unsigned integer type of the same size, though
strictly speaking this is undefined behavior.
[color=blue]
> BTW there is also no support for anything that requires fewer or more than
> 32 bits, e.g no support for typical doubles as just one example.[/color]

Since a 32-bit floating-point type can't support the minimum
requirements for double, the implementation is presumably
non-conforming in that respect. (That doesn't necessarily mean it
can't be useful; I have no opinion on that.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Paul Lutus wrote:
[color=blue]
> <cl7gbh$7th$1@hood.uits.indiana.edu>
>
> ************************************************** *****************
>
> "The size of each char, int, long, or float is 1 word (32 bits long).
> So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
> you got the idea. Using a large array of int to mimic addressable memory is
> the cause for this. The indexes to this large array are treated as
> addresses. This memory is word-addressable and not byte-addressable.
> And programs that assume a byte-addressable architecture will need to be
> modified to suit the one used by MPC. Unions are supported."
>
> ************************************************** *****************
>
> If, as the OP claims, all data are 32-bit words, then the claim that unions
> are supported is false, since (1) Java will not allow disparate data types
> to be overlaid in memory, and[/color]

Quite clearly the results from running code posted in this thread
shows that MPC handles this correctly.
[color=blue]
> (2) a union's purpose is the mapping of
> disparate data types, and there aren't any disparate data types.[/color]

Can you please provide a reference from the standard for this claim.
I find no such wording anywhere.

As a starting point I suggest (of C99) 6.2.5, 6.5.2.3, 6.7.2.1.
Though I couldn't find anything there myself, you will probably
have to look elsewhere.
[color=blue]
>
> BTW there is also no support for anything that requires fewer or more than
> 32 bits, e.g no support for typical doubles as just one example.[/color]

This specific compiler is not 100% ISO C compliant, I agree. But its
support of unions is compliant to ISO C. I see mp reason that the other
issues I know of with this compiler cannot be solved.

I am curious, you seem to say this is impossible in the general case.
So, can you please give an example of a C program that cannot be validly
compiled to Java byte code according to the ISO C standard. If you are
using some other benchmark for what a C compiler is than the ISO C
standard please provide some definition for what you mean (and I can
also win any argument using definitions that suit me).

According to the standard a compiler is a C compiler if it can compile
any strictly conforming program. A program that assumes byte addressable
memory is not a strictly conforming C program.

If your claim is only about this specific instance then you are right in
saying that it is not an ISO C compiler (strictly speaking), but your
union argument does not provide evidence for this as the resulting code
is valid according to the standard.

--
Thomas.

"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10nqrekl7v9sp4b@corp.supernews.com...[color=blue]
> Alex Fraser wrote:[color=green]
> > "Paul Lutus" <nospam@nosite.zzz> wrote in message
> > news:10nqmt2okb8hnec@corp.supernews.com...
> > [snip][color=darkred]
> >> If the compiler is ANSI C compliant, my example program will compile
> >> on that compiler and run on that plartform. Unions are supported by C,
> >> they are not supported by Java, and they are not supported by the
> >> program under discussion.[/color]
> >
> > From these statements, I infer that you have an example program which
> > demonstrates that unions are not supported. Is this correct? And if so,
> > what is this example program?[/color][/color]
[snip]

You have not answered my question: do you have an example program which
demonstrates that unions are not supported?
[color=blue][color=green]
> > Do you have any other evidence on which you base the claim above?[/color]
>
> Please take the time to read this and the prior thread before raising
> closed issues.[/color]

I have read all the posts. I do not see the issue of your claim above as
closed, except perhaps in your mind. Nor do I see my questions answered,
otherwise I would not be asking them.

[snip][color=blue]
> If, as the OP claims, all data are 32-bit words, then the claim that
> unions are supported is false, since (1) Java will not allow disparate
> data types to be overlaid in memory, and (2) a union's purpose is
> the mapping of disparate data types, and there aren't any disparate
> data types.[/color]

The fact that all data are 32-bit words does not imply that there are no
"disparate data types"; I see nothing to substantiate your claim.

Next flawed argument, please.

Alex

In article <10nqamhfej8qqf5@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>
>Since unions are not supported in the product being discussed, their
>ubiquity is not the issue, and your argument is just that, nothing more.
>Also, the only "union" supported in the product is to make two or more
>references to the same integer-sized variable (language provided by Mr.
>Abdullah). Therefore, in point of fact, the product cannot map two
>distinct, same-size entities onto one another, which is what a "union"
>should be capable of doing. This means that Mr. Abdullah's claims in this
>specific regard are, like so many others, not correct.[/color]

Excuse me, but unions are supported in the product being discussed.

Napi
--
http://www.cs.indiana.edu/hyplan/napi.html

In article <10nqefd36j5pod2@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>Dave Vandervies wrote:
>[color=green]
>> In article <10nqamhfej8qqf5@corp.supernews.com>,
>> Paul Lutus <nospam@nosite.zzz> wrote:[color=darkred]
>>>Gerry Quinn wrote:[/color]
>>[color=darkred]
>>>> As I understand it, this issue only affects incompetent programmers who
>>>> write code that assumes that bytes have eight bits.
>>>
>>>No, the original prohibition to which I refer was provided by Mr.
>>>Abdullah, who said:
>>>
>>><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."
>>>
>>>*********************************************** ******
>>>
>>>Care to retract your argument now, or later?[/color]
>>
>> ...So it doesn't provide a byte-addressable memory model.
>>
>> Care to provide a reference to support your claim that C requires a
>> byte-addressable memory model?[/color]
>
>Before you try to shift the burden of evidence, care to find where I made
>this claim? Please do not drift the tread -- this is the easiest imaginable
>activity, but it sheds no light on anyting.
>[color=green][color=darkred]
>>>Since unions are not supported in the product being discussed, their
>>>ubiquity is not the issue, and your argument is just that, nothing more.
>>>Also, the only "union" supported in the product is to make two or more
>>>references to the same integer-sized variable (language provided by Mr.
>>>Abdullah). Therefore, in point of fact, the product cannot map two
>>>distinct, same-size entities onto one another, which is what a "union"
>>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>>specific regard are, like so many others, not correct.[/color]
>>
>> I haven't been following this thread too closely, but if I'm not mistaken,
>> union support was never claimed to be this limited (except by you).[/color]
>
>The OP eventually admitted that all variables are mapped to Java native
>integers -- all of them. This means there is no support for the property of
>unions that they can conjoin two unrelated data types so long as their size
>is adjusted to be the same.[/color]

All variables are located in the large array of int. As a result of
register allocation several of the variables end up cached in Java native
variables of int type or float type. But, their home locations are always
in the large array of int. And again, unions and structs are supported.

Napi

--
http://www.cs.indiana.edu/hyplan/napi.html

In article <10nqnnc7nau6m73@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>Dave Vandervies wrote:
>[color=green]
>> In article <10nqefd36j5pod2@corp.supernews.com>,
>> Paul Lutus <nospam@nosite.zzz> wrote:[color=darkred]
>>>Dave Vandervies wrote:[/color][/color]
>
>/ ...
>[color=green][color=darkred]
>>>> Care to provide a reference to support your claim that C requires a
>>>> byte-addressable memory model?
>>>
>>>Before you try to shift the burden of evidence, care to find where I made
>>>this claim? Please do not drift the tread -- this is the easiest
>>>imaginable activity, but it sheds no light on anyting.[/color]
>>[/color][/color]
....[color=blue][color=green]
>> It does NOT invalidate the claim that this is a C implementation targeting
>> the JVM, with runtime code that treats a large array of Java integers
>> as a word-addressable memory space.[/color]
>
>Ther OP made false claims both here and on his Web site. I said the claims
>were false. At which point did you lose track of the topic?[/color]

Actually neither I here nor the website ever claimed this is a conversion from
C to Java, but a conversion from C to Java Byte Code, and that's a big
difference. Please read carefully.

Napi

--
http://www.cs.indiana.edu/hyplan/napi.html

Mohd Hanafiah Abdullah wrote:
[color=blue]
> In article <10nqamhfej8qqf5@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:[color=green]
>>
>>Since unions are not supported in the product being discussed, their
>>ubiquity is not the issue, and your argument is just that, nothing more.
>>Also, the only "union" supported in the product is to make two or more
>>references to the same integer-sized variable (language provided by Mr.
>>Abdullah). Therefore, in point of fact, the product cannot map two
>>distinct, same-size entities onto one another, which is what a "union"
>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>specific regard are, like so many others, not correct.[/color]
>
> Excuse me, but unions are supported in the product being discussed.[/color]

Post the byte code in which a Java float is united with a Java integer. Or
retract your statement.

Unions are not supported in your product. A C union is a joining of two or
more distinct variable types with simultaneous access to both, e.g. it is
an example of a memory block shared between data types. This is not allowed
in Java because of strong typing.

You have arranged to create a single 32-bit word datatype to represent
everything, so there is no distinction between one kind of variable and
another. Therefore there are no disparate data types, therefore there are
no unions as that term is understood.

But, as I say above, prove me wrong. Post the Java bytecode that unites a
Java float and a Java integer in the same address space, something not
allowed in Java.

--
Paul Lutus
http://www.arachnoid.com

Mohd Hanafiah Abdullah wrote:
[color=blue]
> In article <10nqefd36j5pod2@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:[/color]

/ ...
[color=blue][color=green]
>>The OP eventually admitted that all variables are mapped to Java native
>>integers -- all of them. This means there is no support for the property
>>of unions that they can conjoin two unrelated data types so long as their
>>size is adjusted to be the same.[/color]
>
> All variables are located in the large array of int. As a result of
> register allocation several of the variables end up cached in Java native
> variables of int type or float type.[/color]

Please explain how you have used "register allocation" to circumvent Java's
strong data typing. Or are you talking about native code called by Java?
[color=blue]
> But, their home locations are always
> in the large array of int. And again, unions and structs are supported.[/color]

Show us the bytecode that overlays a Java float and a Java integer into the
same memory space. That is what a union is. Show us the Java bytecode that
allows one to manipulate individual bits of a Java float datatype, as a C
union allows.

If you use the obvious approach of translating the float using
Float.floatToIntBits() and the reverse method, it wil be interesting to se
how you handle simultanous changes to both forms. In any case, it is not a
union. Java doesn't allow this.

--
Paul Lutus
http://www.arachnoid.com

Mohd Hanafiah Abdullah wrote:
[color=blue]
> In article <10nqnnc7nau6m73@corp.supernews.com>,
> Paul Lutus <nospam@nosite.zzz> wrote:[/color]

/ ...
[color=blue][color=green]
>>Ther OP made false claims both here and on his Web site. I said the claims
>>were false. At which point did you lose track of the topic?[/color]
>
> Actually neither I here nor the website ever claimed this is a conversion
> from C to Java, but a conversion from C to Java Byte Code, and that's a
> big difference.[/color]

No, it is not a difference at all. This is because of "javap" and similar
tools, which allow one to acquire a rudimentary source file from any Java
bytecode file.

Or are you claiming that you have created Java bytecode that cannot be
rendered into human-readable form by "javap" and other similar tools? I am
sure Sun Microsystems will be very interested to hear of this development.
[color=blue]
> Please read carefully.[/color]

Please check your facts before posting. In any case, as anyone can see by
reading this and the thread you abandoned, the objections are not about
whether Java source or bytecode is generated, but whether the statements
made are valid claims or marketing hype.

--
Paul Lutus
http://www.arachnoid.com

In article <10nre1ja02ulldc@corp.supernews.com>,
Paul Lutus <nospam@nosite.zzz> wrote:[color=blue]
>Mohd Hanafiah Abdullah wrote:
>[color=green]
>> In article <10nqamhfej8qqf5@corp.supernews.com>,
>> Paul Lutus <nospam@nosite.zzz> wrote:[color=darkred]
>>>
>>>Since unions are not supported in the product being discussed, their
>>>ubiquity is not the issue, and your argument is just that, nothing more.
>>>Also, the only "union" supported in the product is to make two or more
>>>references to the same integer-sized variable (language provided by Mr.
>>>Abdullah). Therefore, in point of fact, the product cannot map two
>>>distinct, same-size entities onto one another, which is what a "union"
>>>should be capable of doing. This means that Mr. Abdullah's claims in this
>>>specific regard are, like so many others, not correct.[/color]
>>
>> Excuse me, but unions are supported in the product being discussed.[/color]
>
>Post the byte code in which a Java float is united with a Java integer. Or
>retract your statement.
>
>Unions are not supported in your product. A C union is a joining of two or
>more distinct variable types with simultaneous access to both, e.g. it is
>an example of a memory block shared between data types. This is not allowed
>in Java because of strong typing.
>
>You have arranged to create a single 32-bit word datatype to represent
>everything, so there is no distinction between one kind of variable and
>another. Therefore there are no disparate data types, therefore there are
>no unions as that term is understood.
>
>But, as I say above, prove me wrong. Post the Java bytecode that unites a
>Java float and a Java integer in the same address space, something not
>allowed in Java.[/color]

Here's an example:

#include <stdio.h>

typedef union abc
{ int x;
float y;
} a_union;

main()
{ a_union z;

z.x = 1078531719;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);

z.y = 3.142;
printf("int val = %d\n", z.x);
printf("float val = %f\n", z.y);
}

MPC produced:
int val = 1078531719
float val = 3.142
int val = 1078531719
float val = 3.142

gcc produced:
int val = 1078531719
float val = 3.142000
int val = 1078531719
float val = 3.142000

Napi

--
http://www.cs.indiana.edu/hyplan/napi.html

Paul Lutus wrote:[color=blue]
> Willem wrote:
>[/color]
.... snip ...[color=blue]
>[color=green]
>> ) But if they are both Java native integers, no mapping is taking
>> place. If ) there are two accesses to a simple integer value, the
>> term "mapping" is not ) appropriate, but if a C union is provided
>> and two different data types are ) mapped/conjoined, the term in[/color]
>
> You really need to set up your newsreader properly. Use this post
> as an example of standard quoting style.[/color]

His problem is extremely simple - stop using a non-standard quote
character. The standard is '>', not ')'.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Mohd Hanafiah Abdullah wrote:

/ ...
[color=blue][color=green]
>>But, as I say above, prove me wrong. Post the Java bytecode that unites a
>>Java float and a Java integer in the same address space, something not
>>allowed in Java.[/color]
>
> Here's an example:
>
> #include <stdio.h>
>
> typedef union abc
> { int x;
> float y;
> } a_union;
>
> main()
> { a_union z;
>
> z.x = 1078531719;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);
>
> z.y = 3.142;
> printf("int val = %d\n", z.x);
> printf("float val = %f\n", z.y);
> }
>
> MPC produced:
> int val = 1078531719
> float val = 3.142
> int val = 1078531719
> float val = 3.142[/color]

1. This doesn't reply to my post's request.

2. This is not a union, it it two instances of the same variable. Again, to
reply to my post, you need to provide the Java bytecode that unites a Java
float and a Java integer in the same address space, something that is not
allowed in Java.

I would ask that you post an example of two data types of innately different
sizes, but you have already designed your way out of that possibility,
along with any support for doubles and other data types larger or smaller
than 32 bits.

To summarize, this is a commercial exploitation of Usenet for private gain,
an attempt to market a product with hype rather than truth. The description
of the product in the thread by Mr. Abdullah directly, and on his Website,
simply does not correspond to the truth.

According to Mr. Abdullah, a little "tweaking" will make a typical C program
compatible with his product. But in tests and in the few moments of candor
from these threads, this turns out not to be true for several reasons.
Interested readers can read this thread and the one Mr. Abdullah abandoned
to assemble a more accurate picture.

I call on Mr. Abdullah to release review copies of his product to
professional reviewers, rather than try to construct set pieces that have
little to do with the information requested, while valiantly trying to
exploit Usenet for private gain.

--
Paul Lutus
http://www.arachnoid.com

Paul Lutus <nospam@nosite.zzz> writes:[color=blue]
> Mohd Hanafiah Abdullah wrote:[color=green][color=darkred]
>>>But, as I say above, prove me wrong. Post the Java bytecode that unites a
>>>Java float and a Java integer in the same address space, something not
>>>allowed in Java.[/color]
>>
>> Here's an example:
>>
>> #include <stdio.h>
>>
>> typedef union abc
>> { int x;
>> float y;
>> } a_union;
>>
>> main()
>> { a_union z;
>>
>> z.x = 1078531719;
>> printf("int val = %d\n", z.x);
>> printf("float val = %f\n", z.y);
>>
>> z.y = 3.142;
>> printf("int val = %d\n", z.x);
>> printf("float val = %f\n", z.y);
>> }
>>
>> MPC produced:
>> int val = 1078531719
>> float val = 3.142
>> int val = 1078531719
>> float val = 3.142[/color]
>
> 1. This doesn't reply to my post's request.
>
> 2. This is not a union, it it two instances of the same variable. Again, to
> reply to my post, you need to provide the Java bytecode that unites a Java
> float and a Java integer in the same address space, something that is not
> allowed in Java.[/color]

How is this not a union? What do you think a union is, anyway?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Paul Lutus wrote:[color=blue]
> Mohd Hanafiah Abdullah wrote:
>[color=green]
>>#include <stdio.h>
>>
>>typedef union abc
>>{ int x;
>> float y;
>> } a_union;
>>
>>main()
>>{ a_union z;
>>
>> z.x = 1078531719;
>> printf("int val = %d\n", z.x);
>> printf("float val = %f\n", z.y);
>>
>> z.y = 3.142;
>> printf("int val = %d\n", z.x);
>> printf("float val = %f\n", z.y);
>> }
>>
>>MPC produced:
>>int val = 1078531719
>>float val = 3.142
>>int val = 1078531719
>>float val = 3.142[/color]
>
>
> 1. This doesn't reply to my post's request.
>
> 2. This is not a union, it it two instances of the same variable. Again, to
> reply to my post, you need to provide the Java bytecode that unites a Java
> float and a Java integer in the same address space, something that is not
> allowed in Java.
>[/color]

How is the above not valid according to the C standard? (Hint: it is).

[snip]

--
Thomas.

Keith Thompson wrote:
[color=blue]
> Paul Lutus <nospam@nosite.zzz> writes:[/color]

/ ...
[color=blue][color=green]
>> 1. This doesn't reply to my post's request.
>>
>> 2. This is not a union, it it two instances of the same variable. Again,
>> to reply to my post, you need to provide the Java bytecode that unites a
>> Java float and a Java integer in the same address space, something that
>> is not allowed in Java.[/color]
>
> How is this not a union? What do you think a union is, anyway?[/color]

A union is two or more disparate variable types that share the same memory
space. Because of its strong data typing, Java simply doesn't allow this.
As a result, the program in question has to jump through hoops to pretend
to support a union such as is imagined to exist in the above examples and
those I provided earlier.

This is why I asked to see the Java bytecode, and this is why Mr. Abdullah
refused my request.

--
Paul Lutus
http://www.arachnoid.com

In message <10nre1ja02ulldc@corp.supernews.com>, Paul Lutus
<nospam@nosite.zzz> writes

[too much]

You don't appear to be discussing C++ here, so please remove
comp.lang.c++ from the newsgroups list in your future postings.

Followups set.

A study of BCPL 's type system might shed more light, in any case ;-)
--
Richard Herring

On Tue, 26 Oct 2004 01:54:05 -0700
Paul Lutus <nospam@nosite.zzz> wrote:
[color=blue]
> Keith Thompson wrote:
>[color=green]
> > Paul Lutus <nospam@nosite.zzz> writes:[/color]
>
> / ...
>[color=green][color=darkred]
> >> 1. This doesn't reply to my post's request.
> >>
> >> 2. This is not a union, it it two instances of the same variable.
> >> Again, to reply to my post, you need to provide the Java bytecode
> >> that unites a Java float and a Java integer in the same address
> >> space, something that is not allowed in Java.[/color]
> >
> > How is this not a union? What do you think a union is, anyway?[/color]
>
> A union is two or more disparate variable types that share the same
> memory space.[/color]

Well, his C code showed a float and an int occupying the same location.

In fact, with the possible exception of unsigned char, if you write
through one type then read through another you are invoking undefined
behaviour so, as far as the C standard is concerned, the implementation
can do anything it wants including aborting your program, launching a
nuclear attack against you next door neighbour or making demons fly out
of your nose.

The only mechanism C provides for examining data using any type other
than that which was written is the unsigned char, anything else the
implementation allows to work is at the whim of the implementation.
[color=blue]
> Because of its strong data typing, Java simply doesn't
> allow this. As a result, the program in question has to jump through
> hoops to pretend to support a union such as is imagined to exist in
> the above examples and those I provided earlier.[/color]

An implementation is allowed to jump through as many hoops as it wants
in order to achieve the results mandated by the C standard.
[color=blue]
> This is why I asked to see the Java bytecode, and this is why Mr.
> Abdullah refused my request.[/color]

I don't see the need to show the bytecode and it would be off topic in
comp.lang.c

I also believe that his advertising the product is off topic here, since
we deal with the language not specific implementations. However, if he
wants to put it in his sig whilst posting on topic that is fine.

I would also say that the OP saying his product does not support byte
addressing is misleading, since from what I have read it does, it's just
that the byte in question happens to be 32 bits. The C standard does not
use byte to mean 8 bits, a byte is merely the smallest unit that the
implementation chooses to provide and I've used implementations with 16
bit bytes before where sizeof(int)==1.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

Paul Lutus wrote:[color=blue]
> Mohd Hanafiah Abdullah wrote:
>
>[color=green]
>>In article <10nqamhfej8qqf5@corp.supernews.com>,
>>Paul Lutus <nospam@nosite.zzz> wrote:
>>
>>Excuse me, but unions are supported in the product being discussed.[/color]
>
>
> Post the byte code in which a Java float is united with a Java integer. Or
> retract your statement.[/color]

Surely the question of if he can unify a java float with a java integer
is not important? The question is if his program can take a program
written in according the the c standard, compile that program, execute
it, and then produce the output the standard says.

Your argument seems to me to read the same as saying "You can't turn C
into assembler on X processor, as X processor doesn't support floating
point". Of course you can, you just emulate the floating point so that
the user cannot tell.

Chris

Paul Lutus wrote:[color=blue]
> Alex Fraser wrote:
>
>[color=green]
>>"Paul Lutus" <nospam@nosite.zzz> wrote in message
>>news:10nqmt2okb8hnec@corp.supernews.com...[/color][/color]
[color=blue][color=green]
>>And if
>>so, what is it?[/color]
>
>
> *sigh*
>[/color]
I feel the urge to defend the writers of this product. What is it?[color=blue]
>
> If, as the OP claims, all data are 32-bit words, then the claim that unions
> are supported is false, since (1) Java will not allow disparate data types
> to be overlaid in memory, and (2) a union's purpose is the mapping of
> disparate data types, and there aren't any disparate data types.[/color]
Why is it false? Where do they violate the C standard[color=blue]
>
> BTW there is also no support for anything that requires fewer or more than
> 32 bits, e.g no support for typical doubles as just one example.[/color]
Does the C standard ever say that doubles must be bigger than 32 bits?

If you want to argue that their program doesn't support some commonly
used non-standard extensions to C then that is fine. But I believe in
their original claim (we support the C standard) then the areas where
you are complaining are not valid. (of course it looks like as of yet
they don't support all the C standard, but I see no problems with the
bits that they are talking about).

In fact, I believe that according to the C standard writing one type to
a union and then reading another type may be undefined behaviour, making
this conversation null anyway..

Chris

C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

re: C to Java Byte Code

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about