C to Java Byte Code

[Paul Lutus]

Paul Lutus <[email protected]> wrote:

/ ...

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.

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?

But, their home locations are always
in the large array of int. And again, unions and structs are supported.

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]

Paul Lutus <[email protected]> wrote:

/ ...

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.

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.

Please read carefully.

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.

 

[Mohd Hanafiah Abdullah]

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.

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

 

[CBFalconer]

Willem wrote:
.... snip ...


You really need to set up your newsreader properly. Use this post
as an example of standard quoting style.

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

 

[Paul Lutus]

Mohd Hanafiah Abdullah wrote:

/ ...

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

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.

 

[Keith Thompson]

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.

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

 

[Thomas Stegen]

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.

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

[snip]

 

[Paul Lutus]

Paul Lutus <[email protected]> writes:

/ ...

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

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.

 

[Flash Gordon]

/ ...


A union is two or more disparate variable types that share the same
memory space.

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.

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.

An implementation is allowed to jump through as many hoops as it wants
in order to achieve the results mandated by the C standard.

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

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.

 

[Richard Herring]

In message <[email protected]>, Paul Lutus

[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 ;-)

 

[Azumanga]

Mohd Hanafiah Abdullah wrote:




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

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

 

[Azumanga]

Alex Fraser wrote:




*sigh*

I feel the urge to defend the writers of this product. What is it?

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.

Why is it false? Where do they violate the C standard

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.

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

 

[Azumanga]

Mohd Hanafiah Abdullah wrote:




/ ...




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?




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.

He doesn't have to overlay a java float and a java integer in the same
memory space. He merely has to show whatever he has decided to represent
a C integer and a C floating point number in the same memory location.
Of course it would be more efficent if these were java floats and java
integers, but in no way is this necessary (for example the way I would
do this would be to use a less inefficent implementation just for
unions, and then native java variables for non-unions).

Chris

 

[CBFalconer]

.... snip ...

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);

illegal statement here. You cannot access a field of a union as a
type other than what you last wrote into it.

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

Same thing here.

}

MPC produced:

Meaningless. This is undefined behavior.

 

[joe]

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.

It's not allowed in C/C++ either. Accessing a union member as anything
other than what it was last written as is undefined.

Joe

 

[Gerry Quinn]

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

Of course it's a union. It has two members x and y which are in this
instance of different types, although that is by no means part of the
specification.

Within the C program of which the above is a fragment, the data stored
in an instance of the union can be referenced as an int or a float, and
will be interpreted in the appropriate manner. THAT IS ALL. NOTHING
ELSE IS TO BE EXPECTED ACCORDING TO THE DEFINITION OF THE C LANGUAGE.

You can use it as a structured way to store variant data types compactly
(the basic function of unions), or you can use it in a hackerish way to
investigate data storage on a target system and implementation. You
used it in the latter fashion and for some reason you didn't like the
results. But it worked just fine. C doesn't make any promises about
the results of reinterpreting disparate types.

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.

There is no reason at all why the types should have to be be disparate,
although in this case they are, albeit their representations currently
happen to be the same size. And Java and its strong typing are
completely irrelevant, just as irrelevant as the details of whatever CPU
is running a compiled version of the C program containing the union
definition above. Neither bytecode nor machine code has unions. Unions
are a feature of C, not of compiled executables.

- Gerry Quinn

 

[boa]

It's not allowed in C/C++ either. Accessing a union member as anything
other than what it was last written as is undefined.

Joe

<C>
Is it undefined or unspecified? Annex J.1 in C99, page 488, lists "The
value of a union member other than the last one stored into", as
unspecified and refers to §6.2.6.1.

I'm not asking just to be a PITA, but because I recently spent at least
an hour browsing the standard for the chapter&verse which said that it
was undefined. Couldn't find anything except J.1.
</C>

boa

 

[Richard Bos]

# 3.6
# 1 byte
# addressable unit of data storage large enough to hold any member of
# the basic character set of the execution environment
# 2 NOTE 1 It is possible to express the address of each individual byte
# of an object uniquely.

Of course, a byte needn't be an octet, and in fact, in the
implementation under discussion, a byte is _not_ an octet.

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.

I cannot be certain what you mean by "conjoin", but if you mean, as
would be my guess, that you can assign a value to one member of an array
and then read from another member with another type, that capability
does not in fact exist in ISO C, unless the other type is unsigned char.

This does not mean that I think this implementation would be useless for
general programming, nor that this opinion is partly based on its
mapping all basic C types to a Java int. However, unions have little, if
anything, to do with it. <ctype.h> is a larger problem. So is EOF.

Richard

 

[Richard Bos]

This does not mean that I think this implementation would be useless for

^^^
do not

general programming,

*cough* Bloody fingers...

Richard

 

[Gerry Quinn]

[My apologies for accidental double post on comp.lang.c. Mr. Lutus is
now attempting to escape his embarrasment by silently changing follow-
ups.]

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

Of course it's a union. It has two members x and y which are in this
instance of different types, although that is by no means part of the
specification.

Within the C program of which the above is a fragment, the data stored
in an instance of the union can be referenced as an int or a float, and
will be interpreted in the appropriate manner. THAT IS ALL. NOTHING
ELSE IS TO BE EXPECTED ACCORDING TO THE DEFINITION OF THE C LANGUAGE.

You can use it as a structured way to store variant data types compactly
(the basic function of unions), or you can use it in a hackerish way to
investigate data storage on a target system and implementation. You
used it in the latter fashion and for some reason you didn't like the
results. But it worked just fine. C doesn't make any promises about
the results of reinterpreting disparate types.

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.

There is no reason at all why the types should have to be be disparate,
although in this case they are, albeit their representations currently
happen to be the same size. And Java and its strong typing are
completely irrelevant, just as irrelevant as the details of whatever CPU
is running a compiled version of the C program containing the union
definition above. Neither bytecode nor machine code has unions. Unions
are a feature of C, not of compiled executables.

- Gerry Quinn