Re: C to Java Byte Code
From: Willem (willem_at_stack.nl)
Date: 10/22/04
- Next message: ZalekBloom_at_hotmail.com: "Re: Vote to Save Your Job -- Vote for Kerry"
- Previous message: *********: "Re: OT: Any recommendation for an online CS / IT school?"
- In reply to: Paul Lutus: "Re: C to Java Byte Code"
- Next in thread: Paul Lutus: "Re: C to Java Byte Code"
- Reply: Paul Lutus: "Re: C to Java Byte Code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 22 Oct 2004 09:39:50 +0000 (UTC)
Paul wrote:
) Please. There is reasonable disagreement about what an int or a long is, but
) bytes are less flexible, unless of course you are arguing for the sake of
) argument.
Just for the record, there are machines on which a byte can be up to
36 bits long. Assuming that a byte is exactly 8 bits long is a sign of a
programmer who doesn't know how to write portable code.
But still, even though the product we're currently discussing doesn't
support it, that does not make it impossible. You are still claiming that
it is, even though I have shown it to be possible.
)> A byte is most certainly allowed to have 32 bits, I could easily come up
)> with a hardware design that only allowed 32-bit operands, and would
)> therefore have a 32-bit byte. C allows for this.
)
) The actual topic is about creating a Java equivalent for a C program. In
) such a case, the Java equivalent result should be ... equivalent. Yo might
) as well have argued that a byte, int, long, float, double can all be
) defined as one bit.
Well, no, because C has minima for the bitlengths of those types.
In any case, if I compiled said C program on a machine that had 32-bit
bytes, with a normal C compiler, then it would have the same results.
) Not in contemporary C, not with the expected results from floating point
) processing. In any case, you are now arguing solely to argue. In point of
) fact, a product like this cannot arbitrarily define these variables any way
) it pleases -- instead it must bear some relation to a typical C compiler's
) values. And it appears there is no support for doubles as that term is
) commonly understood.
The values of the compiler depend on the underlying hardware. In this
case, the underlying hardware has 32-bit bytes, and 32-bit floats.
The program merely shows this.
)> You really don't seem to understand how C works, do you ?
)
) Your eagerness to abandon the topic is sadly noted. I have been writing C
) programs for 20 years.
That doesn't mean you know how it works.
And I don't see where you get the idea that I'm eager to abandon anyting.
)> You're one of those people that assume a byte has 8 bits, etcetera.
)
) You're one of those people who can't stick to a topic, and who digresses at
) the drop of a hat.
It is entirely relevant to the topic. The flaw you see in the product,
which is the original topic, stems from your inability to entertain the
possibility of bytes that do not have 8 bits.
)> ) But you must address real system memory to do what C does. Otherwise the
)> ) many C programs that share or access memory directly will fail.
)>
)> No you don't. C does not require you to even have real system memory,
)
) Again, if the product is meant to imitate C, the claim, then it must do what
) C does. If C accesses system memory to do its job, the Java program must do
) this also.
They never claimed that you could compile device drivers with their
product, and I don't see how dragging such a niche of C code into the
discussion helps your point.
)> Yes they do. They just don't support addressing a 32-bit word's component
)> as 4 separate bytes.
)
) No, they do not support the common conception of bytes and old-style,
) pre-Unicode chars.
Could you back up this assertion with some evidence ?
)> Simple. It's 128 bits long, the first 32 bits map to both the float and
)> the first byte, and the rest maps to the other three bytes.
)
) If this were true, the MPC output from my test prorgam would have been
) different (look at it more carefully). So it is not true. Yo need to look
) at the entire post more carefully.
I looked at it. Your test program did not have a union between four bytes
and one float. It had a union between a float and however many bytes are
required to match it. One, in the case of MPC.
)> Are you too pigheaded to accept the possibility of hardware with 32-bit
)> bytes ?
)
) Are you this eager to abandon the topic? The Java equivalent program must
) rememble the original prorgam, otherwise the original program's goals
) cannot be met.
I really fail to understand why you are accusing me of abandoning the
topic. Unless, of course, you're trolling. Which I have already accused
you of once, by the way.
)> The 'platform' in this case, is Java, and
)> it has a given endianess, as shown by the compiled program. This is
)> perfectly acceptable behaviour.
)
) The result bears no relationship to the original. The loop produced one
) result where the original produced four.
That's simply because the two ran on different hardware. As I pointed out
several times before. Why do you keep attacking that, instead of coming to
the actual point I have repeatedly made ?
By the way, my above response was to your statement that the endianess was
wrong, and had nothing to do with how many results it should produce. Now
who's drifting from topics ?
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
- Next message: ZalekBloom_at_hotmail.com: "Re: Vote to Save Your Job -- Vote for Kerry"
- Previous message: *********: "Re: OT: Any recommendation for an online CS / IT school?"
- In reply to: Paul Lutus: "Re: C to Java Byte Code"
- Next in thread: Paul Lutus: "Re: C to Java Byte Code"
- Reply: Paul Lutus: "Re: C to Java Byte Code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|