>> I was originaly thinking about processing JAVA source code, not stuff
>> that is pre compiled in a java binary.
> I've never seen a Java source code interpreter. Do you have any pointers?
Actual source code intereters are rare, mostly command interpreters
that allow command files. (Unix sh, csh, etc.)
Others normally at least tokenize the text before processing, some
do more than that.
The HP2000 BASIC systems would tokenize a line on input, and regenerate
it on output (LIST). It might not come out the same way, and there
was no way to add a line with a syntax error.
So, traditionally Java compiles to JVM (bytecode), which is pretty
close to actual machine instructions. Without JIT, those codes are interpreted (or emulated as some might say).
This question is not specific to Java. The library routines for
many other languages have dependencies on the data format, especially
floating point. Some of that can be hidden in high-level language
coding, but not all of it.
> And apart from IBM, all those started making CPUs after DEC, not before...
> And there are good arguments for both little endian and big endian. > People who tries to deny that just haven't though enough about it.
There are such arguments, but the little endian ones go away pretty
soon after the 6502. The 6502 is an interesting processor, especially
look at the subroutine call/return instructions. If you think it
pushes the return address on the stack, like most other processors,
then you should read it again. Maybe even for the 8080, but past
that you might as well go big-endian.
> All hail the PDP-11. Middle endian is the way to go! :-)
Yes, middle endian is fun. I remember Z constants initializing
floating point values in VAX Fortran many years ago.
(Not quite in the middle for double precision, though.)
Stephen Hoffman <seaoh...@hoffmanlabs.invalid> wrote:
(snip)
> There are technical issues here, yes.
> But you're not running something called Java if you haven't passed the > Java test suite, and that's entirely licensing and related.
> If you call it Java (and it hasn't passed the test suite), then you're > in deep sneakers.
> Bob's statement is correct as written.
Yes, but everyone knows how to get around it.
That is why we have GhostScript, Octave, LessTif, PSPP, and such. You can get around trademarks by changing the name.
> I could just as well call any program Java with the same effect.
> Do Oracle claim to have exclusive use of the word "Java"? Because that > is the only point where legalese might also become relevant, since if I > call an editor Java (as an example), would I get into trouble with Oracle?
The rules are complicated, and IANAL, but consider the suit between
Apple records and Apple computer.
In the end, (many years ago) the computer company agreed not to get
into the music business, and the record company not in the computer
business. Oops.
If two products have differnet markets, and buyers won't be
confused, then they can have the same name. (Note to fruit sellers.)
In article <k3fui6$pi...@speranza.aioe.org>, glen herrmannsfeldt
<g...@ugcs.caltech.edu> writes: > That is why we have GhostScript, Octave, LessTif, PSPP, and such. > You can get around trademarks by changing the name.
In the case of PostScript, the language is published by Adobe, and there is no problem in writing programs to read or write PostScript. I have one written in Fortran. :-) Of course, you can't call it PostScript whatever or Adobe whatever, which I think is OK.
In article <k3fuoh$qh...@speranza.aioe.org>, glen herrmannsfeldt
<g...@ugcs.caltech.edu> writes: > If two products have differnet markets, and buyers won't be
> confused, then they can have the same name. (Note to fruit sellers.)
Right. There is a VAX vacuum cleaner, and some VMS system which milks cows. Eurex is an electronic trading platform, but also a brand of trousers and also a brand of window blinds. Focus is a (not very good) German news magazine and a car from Ford (though, bizarrely, the magazine challenged Ford in court---and lost; I don't see any confusion possible there at all). SGI is (was?) a computer company and a lottery company. The RAF was a German terrorist group and the Royal Air Force.
On Thu, 2012-09-20 at 20:36 +0000, glen herrmannsfeldt wrote:
> > Do Oracle claim to have exclusive use of the word "Java"? Because
> that > > is the only point where legalese might also become relevant, since
> if I > > call an editor Java (as an example), would I get into trouble with
> Oracle?
> The rules are complicated, and IANAL, but consider the suit between
> Apple records and Apple computer.
> In the end, (many years ago) the computer company agreed not to get
> into the music business, and the record company not in the computer
> business. Oops.
iTunes could be actionable...
-- Tactical Nuclear Kittens
In article <1348178030.17917.44.ca...@lithium.local.net>, Single Stage
to Orbit <alex.bu...@munted.eu> writes: > > In the end, (many years ago) the computer company agreed not to get
> > into the music business, and the record company not in the computer
> > business. Oops.
> iTunes could be actionable...
It's iPad, iPhone, iMac etc (and, as one pundit noted, iPaid). There is a biography of Jobs called iCon---good pun there, whether or not you agree with the sentiment of the biography. But why is it Apple TV?
Because ITV is a television station, and using ITV (even with camel case) for something having to do with TV would cause confusion, or could.
> On 2012-09-20 04:20, JF Mezei wrote:
>> Stephen Hoffman wrote:
>>> With no IEEE floating point, the tests won't pass, so the results are
>>> not and cannot be called Java.
>> I assume the tests give some equation, and check the answer against a
>> reference platform that uses IEEE ?
>> (aka: 2.0 + 2.0 must equal 4.0000000000000001 and VAX floating point
>> might yield 4.0000000000000002 )
>> I know it is not realistic to expect JAVA on VAX for political and
>> business reasons.
>> I was asking whether in real life, a VAX version of a java interpreter
>> would still run the average application even if internally, the floating
>> point isnt IEEE.
>> In other words, apart from the certification tests, does an interpreter
>> of a high level/abstracted language such as Java really care about the
>> bit format of a float, or wheter the machine is big or little endian ?
>> When you build the interpreter, wouldn't the compiler on the VAX
>> platform take care of the VAX's native binary value storage , as would a
>> compiler for HP-UX on PA-Risc or Itanium ?
> What all people seem to have missed in this question is that floating
> point in Java is not just a binary blob. And Java is not an interpreted
> language. Java is a compiled language, and your Java virtual machine
> have to be able to run compiled code that was compiled on a totally
> different machine, and that is actually not that uncommon to happen.
> And thus, the floating point is just as specified as the integer format.
> Your Java VM will be fed IEEE floating point values. Don't matter what
> the native floating point format of the machine is, or what floating
> point format you want to use in your Java VM. Java code compiled
> somewhere else needs to be able to run on your VM. If you skip that
> part, sure, you can go with your own FP format, just as you can go with
> your own integer format, but you will not be able to run any Java
> programs you get fed from somewhere else.
People may have missed the point, because it is not a valid
argument.
Having the JVM convert IEEE literals to another format when
reading the byte code is not a big problem.
> On 2012-09-20 19:53, JF Mezei wrote:
>> Johnny Billquist wrote:
>>> What all people seem to have missed in this question is that floating
>>> point in Java is not just a binary blob. And Java is not an interpreted
>>> language. Java is a compiled language, and your Java virtual machine
>>> have to be able to run compiled code that was compiled on a totally
>>> different machine, and that is actually not that uncommon to happen.
>> Ahh, this is the silver bullet/show stopper. I understand now. Pre
>> compiled code that says Pie = 3.141592654 will store that constant in
>> an IEEE blob of bytes in the java machine code so you can't just load
>> that blob into a VAX register and perform arithmetic on it.
> Correct.
Yes.
But converting it when loading it would be trivial.
>> With no IEEE floating point, the tests won't pass, so the results are
>> not and cannot be called Java.
> I assume the tests give some equation, and check the answer against a
> reference platform that uses IEEE ?
8 years ago the TCK was said to consist of 75000 tests.
It must be way over 100000 tests today.
It seems very likely that some of those will test FP corner
cases like NaN, Infinite, exception handling, subnormal numbers
etc..
VAX FP would not pass.
> I was asking whether in real life, a VAX version of a java interpreter
> would still run the average application even if internally, the floating
> point isnt IEEE.
It would not be Java.
But you could certainly create something Java like.
> In other words, apart from the certification tests, does an interpreter
> of a high level/abstracted language such as Java really care about the
> bit format of a float, or wheter the machine is big or little endian ?
> In article <505a7d83$0$12925$c3e8da3$40d4f...@news.astraweb.com>, JF Mezei <jfmezei.spam...@vaxination.ca> writes:
>> In other words, apart from the certification tests, does an interpreter
>> of a high level/abstracted language such as Java really care about the
>> bit format of a float, or wheter the machine is big or little endian ?
> Yes, that's a second problem. Java specifies big endian. All little
> endian systems with Java spend CPU cycles byte swapping.
No.
Java uses the native endianess for all in memory representations
and calculations.
Java only use bigendian on all platforms for serialization.
> Sun dealt with this when they ported Java from SPARC to x86. I
> suspect it's built into the shipped code and is very easy for the
> porting folks to get right.
> I suspect there are more x86 systems out there a than all the big
> endian systems combined. And x86 isn't the only little endian
> architecture in use. So most Java code is probably running on little
> endian systems, spinning those cycles.
> I wonder, if Sun had made the opposite choice, could we measure the
> relief on the power grid? 8-)
Most Java apps does not serialize floating point much, so it would have
had no measurable impact going little endian.
> But my question was more about whether format of float internally really
> matters for an interpreted language.
Well - Java is not really an interpreted language.
> Since any developper knows that any floating point operation yields an
> approximation of the answer, relying on the ability to produce an exact
> floating point value is a bit silly.
The handling of corner cases could be more important than just
a very small difference in the result.
> I could just as well call any program Java with the same effect.
> Do Oracle claim to have exclusive use of the word "Java"? Because that
> is the only point where legalese might also become relevant, since if I
> call an editor Java (as an example), would I get into trouble with Oracle?
Java is a registered trademark. Now owned by Oracle.
If call a programming language for Java you will be toast in court.
For something else I don't know.
Oracles lawyers do not have a reputation for being
super friendly.
>> I could just as well call any program Java with the same effect.
>> Do Oracle claim to have exclusive use of the word "Java"? Because that
>> is the only point where legalese might also become relevant, since if I
>> call an editor Java (as an example), would I get into trouble with Oracle?
> The rules are complicated, and IANAL, but consider the suit between
> Apple records and Apple computer.
> In the end, (many years ago) the computer company agreed not to get
> into the music business, and the record company not in the computer
> business. Oops.
> If two products have differnet markets, and buyers won't be
> confused, then they can have the same name. (Note to fruit sellers.)
Or a more on familiar example: DEC computers versus vacuum cleaners.
But Oracle is more aggressive in court than most companies.
On 9/20/2012 4:58 PM, Phillip Helbig---undress to reply wrote:
> In article <k3fuoh$qh...@speranza.aioe.org>, glen herrmannsfeldt
> <g...@ugcs.caltech.edu> writes:
>> If two products have differnet markets, and buyers won't be
>> confused, then they can have the same name. (Note to fruit sellers.)
> Right. There is a VAX vacuum cleaner, and some VMS system which milks
> cows. Eurex is an electronic trading platform, but also a brand of
> trousers and also a brand of window blinds. Focus is a (not very good)
> German news magazine and a car from Ford (though, bizarrely, the
> magazine challenged Ford in court---and lost; I don't see any confusion
> possible there at all). SGI is (was?) a computer company and a lottery
> company. The RAF was a German terrorist group and the Royal Air Force.
The last may not be a good example.
Terrorist groups probably do not even try to adhere to
laws protecting trademarks.
>> In other words, apart from the certification tests, does an interpreter
>> of a high level/abstracted language such as Java really care about the
>> bit format of a float, or wheter the machine is big or little endian ?
> Java use native integer format.
Well, to continue the discussion, Java requires twos complement
and binary.
C, on the other hand, allows (at least as of C89) sign magnitude
or ones complement. (No C compilers for the 7090 yet, though.)
Fortran not only allows for digit complement and radix complement,
but in any base greater than one.
https://github.com/kaffe/kaffe, an open source VM that claims to handle compiled Java that is not certified as a Java VM. The web site claims that the Kaffe project is dormant.
Jikes translates Java source code into JAVA bytecode for a Java VM to run. Source code at:
> On 9/20/2012 2:49 PM, Johnny Billquist wrote:
>> On 2012-09-20 19:53, JF Mezei wrote:
>>> Johnny Billquist wrote:
>>>> What all people seem to have missed in this question is that floating
>>>> point in Java is not just a binary blob. And Java is not an interpreted
>>>> language. Java is a compiled language, and your Java virtual machine
>>>> have to be able to run compiled code that was compiled on a totally
>>>> different machine, and that is actually not that uncommon to happen.
>>> Ahh, this is the silver bullet/show stopper. I understand now. Pre
>>> compiled code that says Pie = 3.141592654 will store that constant in
>>> an IEEE blob of bytes in the java machine code so you can't just load
>>> that blob into a VAX register and perform arithmetic on it.
>> Correct.
> Yes.
> But converting it when loading it would be trivial.
Except when it is a value for which there is no representation in VAX FP.
> On 9/20/2012 3:32 AM, Johnny Billquist wrote:
>> On 2012-09-20 04:20, JF Mezei wrote:
>>> Stephen Hoffman wrote:
>>>> With no IEEE floating point, the tests won't pass, so the results are
>>>> not and cannot be called Java.
>>> I assume the tests give some equation, and check the answer against a
>>> reference platform that uses IEEE ?
>>> (aka: 2.0 + 2.0 must equal 4.0000000000000001 and VAX floating point
>>> might yield 4.0000000000000002 )
>>> I know it is not realistic to expect JAVA on VAX for political and
>>> business reasons.
>>> I was asking whether in real life, a VAX version of a java interpreter
>>> would still run the average application even if internally, the floating
>>> point isnt IEEE.
>>> In other words, apart from the certification tests, does an interpreter
>>> of a high level/abstracted language such as Java really care about the
>>> bit format of a float, or wheter the machine is big or little endian ?
>>> When you build the interpreter, wouldn't the compiler on the VAX
>>> platform take care of the VAX's native binary value storage , as would a
>>> compiler for HP-UX on PA-Risc or Itanium ?
>> What all people seem to have missed in this question is that floating
>> point in Java is not just a binary blob. And Java is not an interpreted
>> language. Java is a compiled language, and your Java virtual machine
>> have to be able to run compiled code that was compiled on a totally
>> different machine, and that is actually not that uncommon to happen.
>> And thus, the floating point is just as specified as the integer format.
>> Your Java VM will be fed IEEE floating point values. Don't matter what
>> the native floating point format of the machine is, or what floating
>> point format you want to use in your Java VM. Java code compiled
>> somewhere else needs to be able to run on your VM. If you skip that
>> part, sure, you can go with your own FP format, just as you can go with
>> your own integer format, but you will not be able to run any Java
>> programs you get fed from somewhere else.
> People may have missed the point, because it is not a valid
> argument.
> Having the JVM convert IEEE literals to another format when
> reading the byte code is not a big problem.
Yes it is, since not all IEEE values have equivalent VAX FP values. What do you do then?
> On 9/20/2012 1:36 PM, Bob Koehler wrote:
>> In article <505a7d83$0$12925$c3e8da3$40d4f...@news.astraweb.com>, JF
>> Mezei <jfmezei.spam...@vaxination.ca> writes:
>>> In other words, apart from the certification tests, does an interpreter
>>> of a high level/abstracted language such as Java really care about the
>>> bit format of a float, or wheter the machine is big or little endian ?
>> Yes, that's a second problem. Java specifies big endian. All little
>> endian systems with Java spend CPU cycles byte swapping.
> No.
> Java uses the native endianess for all in memory representations
> and calculations.
Huh? How do you figure that? Any compiled Java code will have integer constants spread all over. They will be in one, decided, endianness.
And that is in the actual instruction flow, not in some kind of serialization.
