[Info-vax] Now for something On Topic

[Bill Gunshannon]

Just got a set of Hobbyist PAKs. Planning on bringing up a VAX or two
and maybe even my Alpha (which, unfortunately I only have one) and
do some playing around. Maybe even look at some Open Source widget
to port.

So, here's my question. I got one file. Is everything in there?
Do I just run this one file and it will activate VMS and all the
LP? I am confused because the old way there were two, One for
VMS and another for LP.

And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?
Within reason, of course. I may be retired, but I am not a
superman. :-)

Thanks everyone.

bill

[Jan-Erik Soderholm]

Post by Bill Gunshannon
Just got a set of Hobbyist PAKs. Planning on bringing up a VAX or two
and maybe even my Alpha (which, unfortunately I only have one) and
do some playing around. Maybe even look at some Open Source widget
to port.
So, here's my question. I got one file. Is everything in there?
Do I just run this one file and it will activate VMS and all the
LP? I am confused because the old way there were two, One for
VMS and another for LP.
And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?
Within reason, of course. I may be retired, but I am not a
superman. :-)
Thanks everyone.
bill

I checked my file I got in Jan-2012, and it is one file
including OPENVMS-ALPHA and OPENVMS-ALPHA-USER together
with all LP's.

So yes, I'd say that it is one file in the new process.

One thing that I saw right now is that there is a license
called "SQL-DEV". As far as I know, that is for the old
"development" licens for Rdb. Or is there some other
"SQL" tool that uses this license ?

No current tools from Oracle for Oracle Rdb uses PAKs
including pre-compilers and the database server as such.

Jan-Erik.

[Michael Unger]

Post by Bill Gunshannon
[...]
So, here's my question. I got one file. Is everything in there?

There are generally two files -- one for VAX _and_ Alpha and another one
for Itanium systems. Yes, the base VMS license(s), VMS-User and layered
products [1] are all contained therein.

Post by Bill Gunshannon
Do I just run this one file and it will activate VMS and all the
LP? I am confused because the old way there were two, One for
VMS and another for LP.
[...]

Michael


[1]
$! PAKs(112) listed below include:
$! ACMS, ACMS-REM, ACMS-RT, ACMSXP-DEV, ACMSXP-RT, ADA, ADAO-PDO, ADA-PDO,
$! ALLIN1-MAIL-DW-CLIENT, ALLIN1-MAIL-SERVER, ALLIN1-MAIL-SERVER-USER,
$! ALLIN1-MAIL-VT-CLIENT, ALLIN1-MAIL-VT-USER, ALLIN1-MAIL-WAN-SERVER,
$! AUDIOKIT-USER, AVAIL-MAN, BASIC, C, CMS, COBOL, CXX-V, DCE-APP-DEV,
DCE-CDS,
$! DCE-SECURITY, DCPS-OPEN, DCPS-PLUS, DECDCS-SRV-VA, DECMIGRATE, DECRAM,
$! DECWRITE, DECWRITE-USER, DESKTOP-ACMS, DFG, DFS, DQS, DTM, DTR,
$! DTR-UI-JAPANESE, DVNETEND, DVNETEXT, DVNETRTG, DW-MOTIF,
DW-MOTIF-UI-CESKY,
$! DW-MOTIF-UI-DEUTSCH, DW-MOTIF-UI-ESPANOL, DW-MOTIF-UI-FRANCAIS,
$! DW-MOTIF-UI-HANGUL, DW-MOTIF-UI-HANYU, DW-MOTIF-UI-HANZI,
$! DW-MOTIF-UI-HEBREW, DW-MOTIF-UI-ITALIANO, DW-MOTIF-UI-JAPANESE,
$! DW-MOTIF-UI-MAGYAR, DW-MOTIF-UI-POLSKI, DW-MOTIF-UI-RUSSKIJ,
$! DW-MOTIF-UI-SLOVENSKY, DW-MOTIF-UI-SVENSKA, DW-SNA-3270-TE-VMS,
$! EXT-MATH-LIB, EXT-MATH-LIB-RT, FMS, FMS-RT-UI-JAPANESE, FMS-UI-HANGUL,
$! FMS-UI-JAPANESE, FORMS, FORMS-RT, FORMS-RT-UI-HANGUL, FORMS-RT-UI-HANYU,
$! FORTRAN, GKS, GKS3D, GKS3D-RT, GKS-RT, GKS-RT-UI-JAPANESE,
GKS-UI-JAPANESE,
$! LSE, MACRO64, MAILBUS-400-API, MAILBUS-400-MTA, MMOV-DV, MMOV-RT, MMS,
$! NOTES, OPENVMS-ALPHA, OPENVMS-ALPHA-USER, OPENVMS-HOBBYIST, OPS5,
PASCAL,
$! PCA, PHIGS, PHIGS-RUNTIME, PHIGS-RUNTIME-UI-JAPAN, PHIGS-UI-JAPANESE,
$! RMSJNL, RTR-CL, RTR-SVR, SQL-DEV, SSU, UCX, UCX-IP-CLIENT, UCX-IP-NFS,
$! UCX-IP-RT, VAXCLUSTER, VAXSET, VAX-VMS, VMSCLUSTER, VMS-UI-JAPANESE,
$! VOLSHAD, X25, X25-CLIENT, X500-ADMIN-FACILITY, X500-DIRECTORY-SERVER

[Phillip Helbig---undress to reply]

Post by Bill Gunshannon
And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?

A modern web browser.

[Bill Gunshannon]

Post by Phillip Helbig---undress to reply

Post by Bill Gunshannon
And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?

A modern web browser.

On my VAX? :-) How about right after Java support. :-)

bill

[Bob Koehler]

Post by Bill Gunshannon
On my VAX? :-) How about right after Java support. :-)

Sure. You can blow your own chip with IEEE instructions added,
right? 8-)

[JF Mezei]

Post by Bob Koehler

Post by Bill Gunshannon
On my VAX? :-) How about right after Java support. :-)

Sure. You can blow your own chip with IEEE instructions added,
right? 8-)

OK, I have to ask.

Say I take the Java source code and compile it on VAX. Won't it just
natively use the vax floating point format in those same 64 bits of
storage ?

So if a Java application asks to add 2.5 to 2.4, won't get a result that
is close to 4.9 whether it is calculated in VAX floating point or IEEE ?

I realise that for data exchanges with other platforms, you will have
problems, but wouldn'T most data exchanges now be done in text form such
as XML where the number 2.9 would be writted out as the characters 2 dot
and 9 instead of some binary value ?

When people converted from VAX to Alpha, didn't they just adopt IEEE
floating by default when they recompiled without problem (specifying vax
floating point only when the program had to read binary files where
floating point values were created in vax float format ?)

[Stephen Hoffman]

Post by JF Mezei

Post by Bob Koehler

Post by Bill Gunshannon
On my VAX? :-) How about right after Java support. :-)

Sure. You can blow your own chip with IEEE instructions added,
right? 8-)

OK, I have to ask.
Say I take the Java source code and compile it on VAX. Won't it just
natively use the vax floating point format in those same 64 bits of
storage ?

VAX floating point is close to, but isn't IEEE floating point.

IEEE floating point compatibility is a prerequisite to passing the Java tests.

Passing the Java tests is a prerequisite to being able to call the
results of your efforts Java.

Software emulation of IEEE FP was looked at, and performance
unsurprisingly stank.

And in general, Oracle is seemingly increasingly ending up owning the
costs of maintaining and updating Java on various platforms, and I'd be
surprised if Oracle was particularly interested in picking up ownership
of Java on any of the HP OpenVMS platforms.

[glen herrmannsfeldt]

Stephen Hoffman <***@hoffmanlabs.invalid> wrote:
(snip, someone wrote)

Post by Stephen Hoffman

Post by JF Mezei
OK, I have to ask.
Say I take the Java source code and compile it on VAX. Won't it just
natively use the vax floating point format in those same 64 bits of
storage ?

VAX floating point is close to, but isn't IEEE floating point.

Well, if you change the byte order it is close.

Post by Stephen Hoffman
IEEE floating point compatibility is a prerequisite to passing the Java tests.

IBM added it to ESA/390, as far as I know one of the reasons
was to support Java.

Post by Stephen Hoffman
Passing the Java tests is a prerequisite to being able to call the
results of your efforts Java.

Most other languages don't restrict the floating point format,
but Java does.

Post by Stephen Hoffman
Software emulation of IEEE FP was looked at, and performance
unsurprisingly stank.

-- glen

[JF Mezei]

Post by Stephen Hoffman
VAX floating point is close to, but isn't IEEE floating point.
IEEE floating point compatibility is a prerequisite to passing the Java tests.

Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

In other words for the bit arrangement in a floating point binary "blob"
really matter to Java, or just the ability to perform floating point math ?

When people ported they VAX applications that ran using VAX floating
point format to Alpha and then IA64, did the change to IEEE internal
format make much of a difference ?

[Stephen Hoffman]

Post by JF Mezei

Post by Stephen Hoffman
VAX floating point is close to, but isn't IEEE floating point.
IEEE floating point compatibility is a prerequisite to passing the Java tests.

Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

No.

Post by JF Mezei
In other words for the bit arrangement in a floating point binary "blob"
really matter to Java, or just the ability to perform floating point math ?

Whatever it might be, your creation here is not Java, Dr Frankenstein.

That's axiomatic.

No matter how much lightning you run through that VAX.

With no IEEE floating point, the tests won't pass, so the results are
not and cannot be called Java.

Post by JF Mezei
When people ported they VAX applications that ran using VAX floating
point format to Alpha and then IA64, did the change to IEEE internal
format make much of a difference ?

Alpha supports both VAX and IEEE formats.

Itanium supports IEEE FP, and can (mostly-transparently) emulate VAX FP.

It's possible to convert among the various formats via the cvt$ftof
call and via other mechanisms.

Reading material:
<http://h71000.www7.hp.com/openvms/integrity/i64-floating-pt-wp.pdf>

As for what you're driving at with your question...

A mongrel software package that started with the Java source code and
is thus somewhat Java-like or Java-flavored, but that's based on VAX
floating point, and that doesn't and won't pass the Java tests? Sure.
Whatever. Have at.

Whatever you decide to call it - that's not Java - will be VAX slow,
and won't be compliant with what folks want, some Java stuff'll fall
over when run, and your not-Java will still need a whole lot of VAX
memory while it's running VAX slow.

And your not-Java will be incompatible with Java, and compatibility is
the whole point of Java.

And you'll probably have to build and maintain a VAX-specific JIT, if
you want the performance of your not-Java to be less-bad.

And all for a hardware platform that's been off the market for a decade.

But other than those minor details, sure, it'll be feasible. Technically.

But then what's technically possible is often not financially viable.

[JF Mezei]

Post by Stephen Hoffman
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 ?

[glen herrmannsfeldt]

JF Mezei <***@vaxination.ca> wrote:

(snip)

Post by JF Mezei
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 )

Most likely that works right, if you put the bytes in the
right order.

But things like Infinity and NaN are likely the problem.

Post by JF Mezei
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 ?

Most libraries have routines that depend on the bits to be right.

In Java, you can even do that at the Java source level. Look at
floatToIntBits and doubleToLongBits.

Post by JF Mezei
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 ?

-- glen

[Johnny Billquist]

Post by JF Mezei

Post by Stephen Hoffman
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.

Johnny

[Michael Kraemer]

Post by Johnny Billquist
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.

OK, so the only option left would be that a hypothetical
Java/VAX VM somehow emulates IEEE FP,
even if it comes with a huge performance penalty.
But otoh, how many Java apps rely heavily on FP math?
Java/VAX would be slow anyway.

[JF Mezei]

Post by Johnny Billquist
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.


I was originaly thinking about processing JAVA source code, not stuff
that is pre compiled in a java binary.

[Johnny Billquist]

Post by JF Mezei

Post by Johnny Billquist
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.

Post by JF Mezei
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?

Johnny

[glen herrmannsfeldt]

Johnny Billquist <***@softjar.se> wrote:

(snip, someone wrote)

Post by Johnny Billquist

Post by JF Mezei
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.

-- glen

[Arne Vajhøj]

Post by Johnny Billquist

Post by JF Mezei

Post by Johnny Billquist
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.

Arne

[Johnny Billquist]

Post by Arne Vajhøj

Post by Johnny Billquist

Post by JF Mezei

Post by Johnny Billquist
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.

Johnny

[Arne Vajhøj]

Post by Johnny Billquist

Post by JF Mezei

Post by Stephen Hoffman
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.

Arne

[Johnny Billquist]

Post by Arne Vajhøj

Post by Johnny Billquist

Post by JF Mezei

Post by Stephen Hoffman
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?

Johnny

[Bob Koehler]

Post by JF Mezei
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. Of course,
the fix for any little endian system would work on all.

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

[glen herrmannsfeldt]

Post by Bob Koehler

Post by JF Mezei
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. Of course,
the fix for any little endian system would work on all.

Well, it only has to swap where it is visible from outside.

That is mostly in I/O routines. You aren't allowed, for example,
to look at a long as two consecutive ints. There are no operations
to allow it, until you write it to a file (I suppose also an
internal file) and then examine the bytes.

Post by Bob Koehler
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 haven't looked at the code at all, but I suspect that it only
does it at the places where it is visible. Though IA32 has a nice
instruction to do the swap.

-- glen

[Bob Koehler]

Post by glen herrmannsfeldt

Post by Bob Koehler
Yes, that's a second problem. Java specifies big endian. All little
endian systems with Java spend CPU cycles byte swapping. Of course,
the fix for any little endian system would work on all.

Well, it only has to swap where it is visible from outside.

You can see it when you shift or mask. Unless the compiler works
really hard to hide it.

[Arne Vajhøj]

Post by Bob Koehler

Post by JF Mezei
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.

Post by Bob Koehler
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.

Arne

[Johnny Billquist]

Post by Arne Vajhøj

Post by Bob Koehler

Post by JF Mezei
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.

Johnny

[Bob Koehler]

Post by JF Mezei
(aka: 2.0 + 2.0 must equal 4.0000000000000001 and VAX floating point
might yield 4.0000000000000002 )

Hm. Poor choice. I think 2 and 4 are exactly representable in all
floating point formats.

Now 3, that could be a pain.

But yes, you could make Java "run" on a VAX. Just don't call it
Java.

And let us know when ou've got it running, we might like a copy to
play around with. 8-)

[Phillip Helbig---undress to reply]

Post by Bob Koehler
Yes, that's a second problem. Java specifies big endian. All little
endian systems with Java spend CPU cycles byte swapping. Of course,
the fix for any little endian system would work on all.
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.

VAX, ALPHA and Intel are little-endian and other HP, IBM AIX, SUN and
SGI are/were big-endian, right?

[Michael Kraemer]

Post by Phillip Helbig---undress to reply
VAX, ALPHA and Intel are little-endian and other HP, IBM AIX, SUN and
SGI are/were big-endian, right?

Yep.
Or, in other words, HP(PA), IBM(Power,S/3xx), Sun(Sparc), Motorola(68K),
SGI(Mips) did it right (natural order), whereas intel did it wrong :-)
And DEC should have known better.

[glen herrmannsfeldt]

Post by Michael Kraemer

Post by Phillip Helbig---undress to reply
VAX, ALPHA and Intel are little-endian and other HP, IBM AIX, SUN and
SGI are/were big-endian, right?

Yep.
Or, in other words, HP(PA), IBM(Power,S/3xx), Sun(Sparc), Motorola(68K),
SGI(Mips) did it right (natural order), whereas intel did it wrong :-)
And DEC should have known better.

It looks to me like DEC considered it a challenge.

I especially like the VMS DUMP program, which makes it especially
obvious that they know which way it goes.

-- glen

[Johnny Billquist]

Post by Michael Kraemer

Post by Phillip Helbig---undress to reply
VAX, ALPHA and Intel are little-endian and other HP, IBM AIX, SUN and
SGI are/were big-endian, right?

Yep.
Or, in other words, HP(PA), IBM(Power,S/3xx), Sun(Sparc), Motorola(68K),
SGI(Mips) did it right (natural order), whereas intel did it wrong :-)
And DEC should have known better.

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.

All hail the PDP-11. Middle endian is the way to go! :-)

Johnny

[glen herrmannsfeldt]

Johnny Billquist <***@softjar.se> wrote:

(snip)

Post by Johnny Billquist
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.

Post by Johnny Billquist
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.)

-- glen

[Johnny Billquist]

Post by glen herrmannsfeldt
(snip)

Post by Johnny Billquist
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.

I totally disagree. The point for little endian is that the pointer does
not change if you just want to read parts of a long word. You'll just
get a truncated value. People sometimes likes to do such things. Or any
kind of other manipulation of values through pointers, where the sizes
might differ. Why would that become invalid after the 6502, which by the
way hardly even can do anything in larger quantities than 8 bits... It's
rather that on the 6502, the argument isn't valid, and it only becomes
valid when you have slightly more capable CPUs.

Johnny

[Joseph Huber]

Post by Johnny Billquist
I totally disagree. The point for little endian is that the pointer does
not change if you just want to read parts of a long word. You'll just
get a truncated value. People sometimes likes to do such things. Or any
kind of other manipulation of values through pointers, where the sizes
might differ. Why would that become invalid after the 6502, which by the
way hardly even can do anything in larger quantities than 8 bits... It's
rather that on the 6502, the argument isn't valid, and it only becomes
valid when you have slightly more capable CPUs.
Johnny

Exactly my experience. when I was moving from PDP to VAX, at the times
of sloppy Fortran programming, quite often there were library-subroutines
expecting short integers, but were called with just integers. On a big
endian machine this never works.

And (although the endianess wars are over since long :-),
what is "natural" in writing/reading numbers in decimal "arabic" ciphers ?
It simply is a cultural convention. Arabic writes/read right to left,
so decimal numbers are little endian, only for us "latin" writers they look
big endian.

[Paul Sture]

Post by Joseph Huber
And (although the endianess wars are over since long :-),
what is "natural" in writing/reading numbers in decimal "arabic" ciphers ?
It simply is a cultural convention. Arabic writes/read right to left,
so decimal numbers are little endian, only for us "latin" writers they look
big endian.

That's an excellent point :-)

[Bill Gunshannon]

Post by Paul Sture

Post by Joseph Huber
And (although the endianess wars are over since long :-),
what is "natural" in writing/reading numbers in decimal "arabic" ciphers ?
It simply is a cultural convention. Arabic writes/read right to left,
so decimal numbers are little endian, only for us "latin" writers they look
big endian.

That's an excellent point :-)

Actually, it's not. Arabs write letters from right to left but number go
left to right just like we do. (been there, done that, got the teeshirt.)

bill

[Joseph Huber]

Post by Bill Gunshannon

Post by Paul Sture

Post by Joseph Huber
And (although the endianess wars are over since long :-),
what is "natural" in writing/reading numbers in decimal "arabic" ciphers
? It simply is a cultural convention. Arabic writes/read right to left,
so decimal numbers are little endian, only for us "latin" writers they
look big endian.

That's an excellent point :-)

Actually, it's not. Arabs write letters from right to left but number go
left to right just like we do. (been there, done that, got the teeshirt.)
bill

Yes, but reading from right to left, the low order decimals come first
in reading direction.

[Bill Gunshannon]

Post by Joseph Huber

Post by Bill Gunshannon

Post by Paul Sture

Post by Joseph Huber
And (although the endianess wars are over since long :-),
what is "natural" in writing/reading numbers in decimal "arabic" ciphers
? It simply is a cultural convention. Arabic writes/read right to left,
so decimal numbers are little endian, only for us "latin" writers they
look big endian.

That's an excellent point :-)

Actually, it's not. Arabs write letters from right to left but number go
left to right just like we do. (been there, done that, got the teeshirt.)
bill

Yes, but reading from right to left, the low order decimals come first
in reading direction.

Maybe so but the statement above says numbers are little-endian for
arabic writes and big-endian for "us latin writers" but I was pointing
out that arabic writers do numbers the same way we latin writers do.

bill

[glen herrmannsfeldt]

Bill Gunshannon <***@cs.uofs.edu> wrote:

(snip)

Post by Bill Gunshannon
Maybe so but the statement above says numbers are little-endian for
arabic writes and big-endian for "us latin writers" but I was pointing
out that arabic writers do numbers the same way we latin writers do.

As well as I understand it (maybe not so well) it is the other
way around. We inherited the number writing system from the arabs

http://en.wikipedia.org/wiki/Arabic_numerals

still, unless you want to start writing program right to left...

By the way, anyone notice that all high-level languages use English
keywords, even when used in non-English speaking countries?

-- glen

[Joseph Huber]

Post by glen herrmannsfeldt
(snip)

Post by Bill Gunshannon
Maybe so but the statement above says numbers are little-endian for
arabic writes and big-endian for "us latin writers" but I was pointing
out that arabic writers do numbers the same way we latin writers do.

As well as I understand it (maybe not so well) it is the other
way around. We inherited the number writing system from the arabs
http://en.wikipedia.org/wiki/Arabic_numerals
still, unless you want to start writing program right to left...

Thanks Glen for this hint:
Citation:
Hence, from the point of view of the reader, numerals in Western texts are
written with the highest power of the base first whereas numerals in Arabic
texts are written with the lowest power of the base first.

expresses better what I meant.

[Bill Gunshannon]

Post by Joseph Huber

Post by glen herrmannsfeldt
(snip)

Post by Bill Gunshannon
Maybe so but the statement above says numbers are little-endian for
arabic writes and big-endian for "us latin writers" but I was pointing
out that arabic writers do numbers the same way we latin writers do.

As well as I understand it (maybe not so well) it is the other
way around. We inherited the number writing system from the arabs
http://en.wikipedia.org/wiki/Arabic_numerals
still, unless you want to start writing program right to left...

Hence, from the point of view of the reader, numerals in Western texts are
written with the highest power of the base first whereas numerals in Arabic
texts are written with the lowest power of the base first.
expresses better what I meant.

Ahhh... Now I understand. You are talking about the order they write them,
not the order in which they appear. Only problem I see with this concept
is that they are still interpreted the same as ours. For example, this year
is 2012. An arab would use a different character set but write them in the
same order. One would think that that would then be read backwards as the
year 2-1-0-2, but that is not the case. To confude things even more, the
sentence "it is the year 2012" would be written in arabic (please pardon
the use of the english charset but I don't know how to do arabic in a news
posting) as "2-0-1-2- -r-a-e-y- -e-h-t- -s-i- -t-i". I always found this
curious. But I will admit I was able to learn to deal with it on things
like signs.

bill

[Bill Gunshannon]

Post by glen herrmannsfeldt
(snip)

Post by Bill Gunshannon
Maybe so but the statement above says numbers are little-endian for
arabic writes and big-endian for "us latin writers" but I was pointing
out that arabic writers do numbers the same way we latin writers do.

As well as I understand it (maybe not so well) it is the other
way around. We inherited the number writing system from the arabs

OK, I'll admit to being confused. We were talking big-endian/little-endian
not who inherited what. And my statement was that numbers writen by arabs
have the same order as numbers written by "us latin writers" therefore
we are both the same-endian not one big and one little. or is that not
what was being discussed at all? Now, if by "latin writers" you meant
roman numerals, all bets are off. :-)

Post by glen herrmannsfeldt
http://en.wikipedia.org/wiki/Arabic_numerals

I don't know what the wiki says (but we all know wikis are never wrong)
but I can give you pictures I took in Qatar that will clearly show that
the arabs write their numbers in the same order we do even though their
letter and word order is reversed.

Post by glen herrmannsfeldt
still, unless you want to start writing program right to left...
By the way, anyone notice that all high-level languages use English
keywords, even when used in non-English speaking countries?

Hmm.... Do you think that could be because all the major ones were
products of the US? Has there ever been a practical programming
language developed in another country that used non-english as its
base?

bill

[glen herrmannsfeldt]

Johnny Billquist <***@softjar.se> wrote:

(snip regarding little endianness)

Post by Johnny Billquist

Post by glen herrmannsfeldt
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.

I totally disagree. The point for little endian is that the pointer does
not change if you just want to read parts of a long word. You'll just
get a truncated value. People sometimes likes to do such things.

The claim by little endian proponents is that it allows one
to process multiple byte addition, with carry, in the right order.
Note that the 6502 at least has to update a 16 bit program counter.

In a subroutine call, the 6502 doesn't push the address of the
next instruction on the stack, but one less. That is the number
that happens to be in the register at the time it needs to go.
Then RET has to increment it before using it.

I first found this in reading a program with a jump table, which
loads a value from a table pushes it onto the stack, and RET.
The table values are one less than the desired address!

(I believe it is one, I could have forgotten, maybe it is two.)

Post by Johnny Billquist
Or any
kind of other manipulation of values through pointers, where the sizes
might differ. Why would that become invalid after the 6502, which by the
way hardly even can do anything in larger quantities than 8 bits... It's
rather that on the 6502, the argument isn't valid, and it only becomes
valid when you have slightly more capable CPUs.

There are two cases. First, the case where you forgot the size,
such as mismatched arguments to Fortran subroutines.

Better to fix them. Easier to find them when the program doesn't
seem to work right, and then fail later.

In the case where you actually know that the size is different,
it isn't so hard to fix. A reasonable processor has an address mode
with an offset, but it isn't so hard to increment the pointer.
I believe that even the 6502 has an index+offset addressing mode.

Now, consider the opposite case: passing a pointer to a smaller
value to a routine expecting a larger one. It might work, but too
often the rest of the word will have the wrong value.

Even in the first case, the program will seem to work until the
needed value gets too big for the register. Better to fix it in
the first place. (If I remember right, the PDP-11 Fortran compilers
will store 16 bit numbers in 32 bit locations, but do 16 bit
arithmetic on them. Fortran requires INTEGER and REAL to be the
same size, though many compilers ignore the requirement.)

-- glen

[Paul Sture]

Post by Johnny Billquist
The point for little endian is that the pointer does
not change if you just want to read parts of a long word. You'll just
get a truncated value. People sometimes likes to do such things.

Among other things that is useful for COBOL when calling subroutines
which have Integer:1 parameters*. COBOL doesn't have an Integer:1
equivalent, but on a litte endian system you can pass an Integer:2 and
the subroutine gets the correct value.

* experience tells me to avoid this if you are going to provide
subroutines which can be called from multiple languages including COBOL.

[glen herrmannsfeldt]

Post by Paul Sture

Post by Johnny Billquist
The point for little endian is that the pointer does
not change if you just want to read parts of a long word. You'll just
get a truncated value. People sometimes likes to do such things.

Among other things that is useful for COBOL when calling subroutines
which have Integer:1 parameters*. COBOL doesn't have an Integer:1
equivalent, but on a litte endian system you can pass an Integer:2 and
the subroutine gets the correct value.

On a big endian system, you can pass 256 times the value, and the
subroutine gets the correct value. (Or left shift 8 if that
operator is available.)

Post by Paul Sture
* experience tells me to avoid this if you are going to provide
subroutines which can be called from multiple languages including COBOL.

I can almost see it in assembly programming, maybe in calling an
assembler routine from a HLL, but it should not be done in HLL
calling HLL if you care at all about portability.


-- glen

[Bob Koehler]

Post by Michael Kraemer
And DEC should have known better.

DEC had it both ways, even before bi-endian Alpha (PDP-10 was
big-endian).

[glen herrmannsfeldt]

Post by Bob Koehler

Post by Michael Kraemer
And DEC should have known better.

DEC had it both ways, even before bi-endian Alpha (PDP-10 was
big-endian).

If VAX had the PDP-10 as an ancestor, instead of the PDP-11,
then things might have been different.

It seems to me that at the time being different from IBM was
sometimes seen as an advantage, even when it wasn't.

-- glen

[Rich Alderson]

Post by glen herrmannsfeldt

Post by Bob Koehler

Post by Michael Kraemer
And DEC should have known better.

DEC had it both ways, even before bi-endian Alpha (PDP-10 was
big-endian).

If VAX had the PDP-10 as an ancestor, instead of the PDP-11,
then things might have been different.

Oh, Glen, that's the way to start a really really big, bitter fight.

[Rich Alderson]

Post by Bob Koehler

Post by Michael Kraemer
And DEC should have known better.

DEC had it both ways, even before bi-endian Alpha (PDP-10 was
big-endian).

The 18-bit (PDP-1, PDP-4/7/9/15) and 12-bit (PDP-5/8) systems were also
big-endian, so the PDP-11 was really an anomaly.

[Stephen Hoffman]

Post by Phillip Helbig---undress to reply
VAX, ALPHA and Intel are little-endian and other HP, IBM AIX, SUN and
SGI are/were big-endian, right?

VAX, x86 and x86-64 are little-endian.

Alpha, Itanium, MIPS and SPARC are bi-endian.

POWER is big-endian.

http://en.wikipedia.org/wiki/Endianness

[Phillip Helbig---undress to reply]

Post by Stephen Hoffman
Alpha, Itanium, MIPS and SPARC are bi-endian.

Right, but on VMS ALPHA is little-endian, IIRC. As I mentioned, I think
Cray used some big-endian ALPHA, but that was, shall we say, not a
common system (in any sense).

[Michael Kraemer]

Post by Phillip Helbig---undress to reply
Right, but on VMS ALPHA is little-endian, IIRC. As I mentioned, I think
Cray used some big-endian ALPHA, but that was, shall we say, not a
common system (in any sense).

They probably retained the endianness of the predecessor machines.
Just like DEC ran Mips processors little-endian to be compatible
with VAX.

[Stephen Hoffman]

Post by Phillip Helbig---undress to reply

Post by Stephen Hoffman
Alpha, Itanium, MIPS and SPARC are bi-endian.

Right, but on VMS ALPHA is little-endian, IIRC. As I mentioned, I think
Cray used some big-endian ALPHA, but that was, shall we say, not a
common system (in any sense).

Pedantic... "Alpha" is what you asked, and that's is bi-endian.
"OpenVMS Alpha" is little-endian.

And in one supported configuration, OpenVMS I64 runs little-endian on
Itanium, but the host OS runs big-endian.

As for those less-common Cray computers, there's a T94-class box - a
series not based on Alpha, AFAIK - on eBay right now. They're around.

[Bob Koehler]

Post by Phillip Helbig---undress to reply
VAX, ALPHA and Intel are little-endian and other HP, IBM AIX, SUN and
SGI are/were big-endian, right?

No. VAX and Intel x86 are little endian. IBM 360/370 and
Motorlola 68K are big endian.

Alpha, SPARC, HP PARC (I think), and Intel IA64, are bi-endian. IBM
RISC 6000 might be, too; most RISC architectures are.

HP, IBM, and Sun, are companies which sell/sold little endian,
big endian, and bi-endian computers. I'm not so sure about all the
systems SGI sold.

[Arne Vajhøj]

Post by JF Mezei

Post by Stephen Hoffman
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.

Post by JF Mezei
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.

Post by JF Mezei
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.

Arne

[glen herrmannsfeldt]

Arne Vajhøj <***@vajhoej.dk> wrote:

(snip)

Post by Arne Vajhøj

Post by JF Mezei
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.

-- glen

[Arne Vajhøj]

Post by JF Mezei

Post by Stephen Hoffman
VAX floating point is close to, but isn't IEEE floating point.
IEEE floating point compatibility is a prerequisite to passing the Java tests.

Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?
In other words for the bit arrangement in a floating point binary "blob"
really matter to Java, or just the ability to perform floating point math ?
When people ported they VAX applications that ran using VAX floating
point format to Alpha and then IA64, did the change to IEEE internal
format make much of a difference ?

If you create a software product and call it Java and it is
not able to pass the Java compatibility test, then you will
hear from the lawyers of the company that owns the Java trademark.

SUN got 20 M$ from MS on that basis.

I am willing to predict that Oracle would request a lot
more money than that. In general Oracle does that. And Oracle
and HP are not exactly close these days.

So HP will not create a software product called Java
with no IEEE FP support. It would be legal suicide.

They could create something called Foobar which had an
amazing similarity with Java except that it used VAX FP.

Or they could do software emulation for IEEE FP.

But I can not imagine there being a business case for
either of those.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by JF Mezei

Post by Stephen Hoffman
VAX floating point is close to, but isn't IEEE floating point.
IEEE floating point compatibility is a prerequisite to passing the Java tests.

Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?
In other words for the bit arrangement in a floating point binary "blob"
really matter to Java, or just the ability to perform floating point math ?
When people ported they VAX applications that ran using VAX floating
point format to Alpha and then IA64, did the change to IEEE internal
format make much of a difference ?

If you create a software product and call it Java and it is
not able to pass the Java compatibility test, then you will
hear from the lawyers of the company that owns the Java trademark.
SUN got 20 M$ from MS on that basis.
I am willing to predict that Oracle would request a lot
more money than that. In general Oracle does that. And Oracle
and HP are not exactly close these days.
So HP will not create a software product called Java
with no IEEE FP support. It would be legal suicide.
They could create something called Foobar which had an
amazing similarity with Java except that it used VAX FP.
Or they could do software emulation for IEEE FP.
But I can not imagine there being a business case for
either of those.

Only Java without IEEE FP is Java ME CLDC 1.0.

That is the Java from 1999 for platforms
where memory is measured in KB.

Arne

[JF Mezei]

Post by Arne Vajhøj
Only Java without IEEE FP is Java ME CLDC 1.0.
That is the Java from 1999 for platforms
where memory is measured in KB.

I realise that an official port of JAVA to VAX-VMS is not possible in
this universe. There is no business reason to port it to a dead
architecture and dying operating system, and thus no reason to try to
overcome the IEEE issues.

But my question was more about whether format of float internally really
matters for 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.

I don't care that a certificartion test fails because one float
operation yielded an asnwer that was different by 0.000000001 (or
whetever differences in results exist between VAX and IEEE floating points)

I care about whether it could be made to work *in principle*

[Johnny Billquist]

Post by JF Mezei

Post by Arne Vajhøj
Only Java without IEEE FP is Java ME CLDC 1.0.
That is the Java from 1999 for platforms
where memory is measured in KB.

I realise that an official port of JAVA to VAX-VMS is not possible in
this universe. There is no business reason to port it to a dead
architecture and dying operating system, and thus no reason to try to
overcome the IEEE issues.
But my question was more about whether format of float internally really
matters for 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.
I don't care that a certificartion test fails because one float
operation yielded an asnwer that was different by 0.000000001 (or
whetever differences in results exist between VAX and IEEE floating points)
I care about whether it could be made to work *in principle*

The biggest fault in your thinking here is that Java is an interpreted
language. It is not. It's a compiled language. And the compiled code
will produce various FP constants, who will all be in IEEE FP format if
compiled anywhere else.

Johnny

[Arne Vajhøj]

Post by JF Mezei
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.

Post by JF Mezei
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.

Arne

[Doug Phillips]

Post by Arne Vajhøj

Post by JF Mezei
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.

Post by JF Mezei
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.
Arne

Interesting discussion.

Here is an article from 1998, "An Interview with the Old Man of
Floating-Point" that tells the story of how the IEEE standard came to be.

http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html

Some interesting bits from the article:

"In 1976 Intel began to design a floating-point co-processor for its
i8086/8 and i432 microprocessors. Dr. John Palmer persuaded Intel that
it needed an arithmetic standard to prevent different boxes with "Intel"
on the outside from computing disparate results inside. At Stanford ten
years earlier, Palmer had heard a visiting professor, William Kahan,
analyze commercially significant arithmetics and assess how much their
anomalies inflated the costs of reliable and portable numerical
software. Kahan had also enhanced the numerical prowess of a successful
line of Hewlett-Packard calculators. Palmer, now the manager of Intel's
floating-point effort, recruited Kahan as a consultant to help design
the arithmetic for the i432 ( which died later ) and for the i8086/8's
upcoming i8087 coprocessor.

"Intel had decided they wanted really good arithmetic. I suggested that
DEC VAX's floating-point be copied because it was very good for its
time. But Intel wanted the `best' arithmetic. Palmer told me they
expected to sell vast numbers of these co-processors, so `best' meant
`best for a market much broader than anyone else contemplated' at that
time. He and I put together feasible specifications for that `best'
arithmetic. Subsequently Silicon Valley heard rumors ( not from me )
about the i8087. They were aghast; how could Intel pack all that into a
chip with only several thousand transistors?"

[The draft was called K-C-S until p753 adopted it.]

"Quickly, the choice narrowed down to two proposals. The existing DEC
VAX formats, inherited from the PDP-11, had the advantage of a huge
installed base. But DEC's original double precision `D' format had the
same eight exponent bits as had its single precision `F' format. This
exponent range had turned out too narrow for some double precision
computations. DEC reacted by introducing its `G' double precision format
with an 11 bit exponent that had served well enough in CDC's 6600/7600
machines for over a decade; K-C-S had chosen that exponent range too for
its double precision.

"With its `G' format, DEC's VAX disagreed with the K-C-S draft primarily
in their treatments of underflow, which the VAX flushed to zero instead
of handling gradually. Consequently their exponent biases and
over/underflow thresholds differed; K-C-S let numbers grow twice as big
as VAX did without overflowing. Exponent biases differed by 2 . If only
K-C-S exponents could have been reduced by this picayune difference, all
arithmetics conforming to IEEE 754 would now use the VAX's formats, much
to DEC's advantage. Why didn't IEEE 754 go that way?"

[Phillip Helbig---undress to reply]

Post by Doug Phillips
Here is an article from 1998, "An Interview with the Old Man of
Floating-Point" that tells the story of how the IEEE standard came to be.
http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html

Hopefully the most significant bits. :-)

[Bob Koehler]

Post by JF Mezei
Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

Run, yes. Run Java, no. The "politics" control that second statement.

Post by JF Mezei
When people ported they VAX applications that ran using VAX floating
point format to Alpha and then IA64, did the change to IEEE internal
format make much of a difference ?

For some yes. The change from VAX D_FLOAT to VAX G_FLOAT as the
default double precision did come up during ports from VAX to Alpha,
even before changing to IEEE was considered.

For others, getting the code to run on VMS didn't happen until
Alpha and IEEE. Java was one such beast.

[Johnny Billquist]

Post by Bob Koehler

Post by JF Mezei
Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

Run, yes. Run Java, no. The "politics" control that second statement.

This is *not* politics. It's a very real technical issue. I'm surprised
people don't understand this...

Johnny

[Stephen Hoffman]

Post by Johnny Billquist

Post by Bob Koehler

Post by JF Mezei
Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

Run, yes. Run Java, no. The "politics" control that second statement.

This is *not* politics. It's a very real technical issue. I'm surprised
people don't understand this...

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.

[Johnny Billquist]

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Bob Koehler

Post by JF Mezei
Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

Run, yes. Run Java, no. The "politics" control that second statement.

This is *not* politics. It's a very real technical issue. I'm
surprised people don't understand this...

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.

This is where I might disagree. If it don't run almost any random Java
program, it's pretty irrelevant what it calls itself, or what the
results of a test suite is. It's simply just not usable in the proposed
role.

Now, let's say it did run any random Java program that I might be
interested in, but failed on some test suite, then it would come more
relevant to talk legalese about it.

Post by Stephen Hoffman
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.

Well, who cares if it calls itself Java and don't pass a test suite,
when it can't run a Java program fed to it?

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?

Johnny

[Stephen Hoffman]

Post by Johnny Billquist

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Bob Koehler

Post by JF Mezei
Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

Run, yes. Run Java, no. The "politics" control that second statement.

This is *not* politics. It's a very real technical issue. I'm
surprised people don't understand this...

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.

This is where I might disagree. If it don't run almost any random Java
program, it's pretty irrelevant what it calls itself, or what the
results of a test suite is. It's simply just not usable in the proposed
role.

Which is why it's not a technical issue. Duh.

Post by Johnny Billquist
Now, let's say it did run any random Java program that I might be
interested in, but failed on some test suite, then it would come more
relevant to talk legalese about it.

The owner of Java might have a differing interpretation.

Post by Johnny Billquist

Post by Stephen Hoffman
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.

Well, who cares if it calls itself Java and don't pass a test suite,
when it can't run a Java program fed to it?

The owner of Java cares.

Post by Johnny Billquist
I could just as well call any program Java with the same effect.

The owner of Java might disagree.

Post by Johnny Billquist
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?

Given this was discussing porting Java to VAX - but not passing the
test suite - I'd say Oracle's legal team could assemble a pretty good
case, particularly if you referred to the results as "Java". In
general, the owner of Java - Oracle - has more lawyers than you do.

Do feel free to become a test case with your hypothetical Java editor,
of course. I'll get the popcorn.

[Johnny Billquist]

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Bob Koehler

Post by JF Mezei
Forgetting Oracle/Java politics for a second, would Java still work if
it were compiled on VMS using the VAX floating point instead of IEEE ?

Run, yes. Run Java, no. The "politics" control that second statement.

This is *not* politics. It's a very real technical issue. I'm
surprised people don't understand this...

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.

This is where I might disagree. If it don't run almost any random Java
program, it's pretty irrelevant what it calls itself, or what the
results of a test suite is. It's simply just not usable in the
proposed role.

Which is why it's not a technical issue. Duh.

Not being able to run any Java program is not a technical issue... Right.

Post by Stephen Hoffman

Post by Johnny Billquist
Now, let's say it did run any random Java program that I might be
interested in, but failed on some test suite, then it would come more
relevant to talk legalese about it.

The owner of Java might have a differing interpretation.

Really? Did you even read what I wrote?

Post by Stephen Hoffman

Post by Johnny Billquist

Post by Stephen Hoffman
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.

Well, who cares if it calls itself Java and don't pass a test suite,
when it can't run a Java program fed to it?

The owner of Java cares.

Are we talking about the owner of Java, the language, or "Java" the
word? Who is the owner of the word?

Post by Stephen Hoffman

Post by Johnny Billquist
I could just as well call any program Java with the same effect.

The owner of Java might disagree.

See above.

Post by Stephen Hoffman

Post by Johnny Billquist
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?

Given this was discussing porting Java to VAX - but not passing the test
suite - I'd say Oracle's legal team could assemble a pretty good case,
particularly if you referred to the results as "Java". In general, the
owner of Java - Oracle - has more lawyers than you do.

And I was pointing out that it would fail much more than just some test
suite.

Post by Stephen Hoffman
Do feel free to become a test case with your hypothetical Java editor,
of course. I'll get the popcorn.

mv emacs Java

Done. Now what?

Johnny

[Stephen Hoffman]

Post by Johnny Billquist
mv emacs Java
Done. Now what?

Start advertising your new "Java" editor and make sure you highlight
your interpreter, while I go get the popcorn. Duh.

[glen herrmannsfeldt]

Johnny Billquist <***@softjar.se> wrote:

(snip)

Post by Johnny Billquist
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.)

-- glen

[Single Stage to Orbit]

Post by Johnny Billquist

Post by Johnny Billquist
Do Oracle claim to have exclusive use of the word "Java"? Because

that

Post by Johnny Billquist
is the only point where legalese might also become relevant, since

if I

Post by Johnny Billquist
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...

[Phillip Helbig---undress to reply]

Post by Single Stage to Orbit

Post by glen herrmannsfeldt
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.

[Arne Vajhøj]

Post by glen herrmannsfeldt
(snip)

Post by Johnny Billquist
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.

Arne

[Phillip Helbig---undress to reply]

Post by glen herrmannsfeldt
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.

[JF Mezei]

Post by Phillip Helbig---undress to reply
Right. There is a VAX vacuum cleaner, and some VMS system which milks
cows.

Yeah, but both suck... one sucks dust, the other sucks milk :-)

(and VAX computers also tended to suck dust from the floor into their
innards and give birth to dust bunnies.)

[Paul Sture]

Post by JF Mezei

Post by Phillip Helbig---undress to reply
Right. There is a VAX vacuum cleaner, and some VMS system which milks
cows.

Yeah, but both suck... one sucks dust, the other sucks milk :-)
(and VAX computers also tended to suck dust from the floor into their
innards and give birth to dust bunnies.)

Actually the VAX vacuum cleaner could suck liquids. I bought the carpet
cleaning kit for mine, which simultaneously delivered soapy water and
sucked it up. That was hard work because you were fighting the suction
to move the cleaning head across the carpet.

[Michael Kraemer]

Post by Phillip Helbig---undress to reply

Post by glen herrmannsfeldt
If two products have differnet markets, and buyers won't be
confused, then they can have the same name. (Note to fruit sellers.)

The RAF was a German terrorist group and the Royal Air Force.

Well, both are in the bombing business.

[Arne Vajhøj]

Post by Phillip Helbig---undress to reply

Post by glen herrmannsfeldt
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.

Arne

[Arne Vajhøj]

Post by Johnny Billquist
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.

Arne

[Michael Kraemer]

Post by Arne Vajhøj
Oracles lawyers do not have a reputation for being
super friendly.

But, considering recent court rulings, they no longer have
the reputation of being super successful either :-)

[glen herrmannsfeldt]

Stephen Hoffman <***@hoffmanlabs.invalid> wrote:

(snip)

Post by Stephen Hoffman
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.

-- glen

[Stephen Hoffman]

Post by glen herrmannsfeldt
That is why we have GhostScript, Octave, LessTif, PSPP, and such.
You can get around trademarks by changing the name.

Dalvik is at least partially open-source, as was mentioned up-thread.

[John E. Malmberg]

Post by Stephen Hoffman

Post by glen herrmannsfeldt
That is why we have GhostScript, Octave, LessTif, PSPP, and such.
You can get around trademarks by changing the name.

Dalvik is at least partially open-source, as was mentioned up-thread.

Dalvik description. It is a VM that runs pre-compiled code.

http://www.dalvikvm.com/

Dalvik source code.

http://code.google.com/p/dalvik/


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:

http://jikes.sourceforge.net/

Open source JDK

http://openjdk.java.net/

I have no idea if any of this could be built on any VMS platform, or
what the performance would be.

Regards,
-John
***@qsl.network
Personal Opinion Only

[Phillip Helbig---undress to reply]

Post by glen herrmannsfeldt
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.

[Arne Vajhøj]

Post by JF Mezei

Post by Bob Koehler

Post by Bill Gunshannon
On my VAX? :-) How about right after Java support. :-)

Sure. You can blow your own chip with IEEE instructions added,
right? 8-)

OK, I have to ask.
Say I take the Java source code and compile it on VAX. Won't it just
natively use the vax floating point format in those same 64 bits of
storage ?
So if a Java application asks to add 2.5 to 2.4, won't get a result that
is close to 4.9 whether it is calculated in VAX floating point or IEEE ?
I realise that for data exchanges with other platforms, you will have
problems, but wouldn'T most data exchanges now be done in text form such
as XML where the number 2.9 would be writted out as the characters 2 dot
and 9 instead of some binary value ?

All that stuff is well defined in Java, so without it would not be
Java. And could not be Java for legal reasons.

But even if we ignore that aspect, then it is still not just
a recompile.

The JIT compiler inside the JVM generates native code, so it
would need to be modified to generate VAX instructions instead
of Alpha instructions.

I would be surprised if the C code in JVM and the native parts
of the Java API did not use SYS$/LIB$/CRTL features that are
only available on Alpha. Requiring significant work to make
it work on VAX.

Arne

[Phillip Helbig---undress to reply]

Post by JF Mezei
When people converted from VAX to Alpha, didn't they just adopt IEEE
floating by default when they recompiled without problem (specifying vax
floating point only when the program had to read binary files where
floating point values were created in vax float format ?)

The ALPHA chip itself can do IEEE. It can even run in big-endian mode
(I think Cray did this). However, on VMS, the native floating-point
format on ALPHA is NOT IEEE.

[Bob Koehler]

Post by JF Mezei
Say I take the Java source code and compile it on VAX. Won't it just
natively use the vax floating point format in those same 64 bits of
storage ?

That's a violation of the Java standard, copyright Oracle (nee Sun),
which says floating point must be done in IEEE.

Folks at DEC did look at emulating IEEE on VAX for a Java port, and
gave it up (the port).

[Phillip Helbig---undress to reply]

Post by Bill Gunshannon

Post by Phillip Helbig---undress to reply

Post by Bill Gunshannon
And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?

A modern web browser.

On my VAX? :-) How about right after Java support. :-)

Well, first you'll need the cross-compiler for ALPHA. :-)

[Bob Koehler]

Post by Phillip Helbig---undress to reply
Well, first you'll need the cross-compiler for ALPHA. :-)

That's what we really need: an Alpha emulator that runs on VAXen.

Talk about slow. 8-)

[Stephen Hoffman]

Just got a set of Hobbyist PAKs...
So, here's my question. I got one file. Is everything in there?

Existentially, no.

But otherwise, just invoke the file for whichever PAKs you asked HP for.

If it blows up, call.

[Phillip Helbig---undress to reply]

Post by Stephen Hoffman

Just got a set of Hobbyist PAKs...
So, here's my question. I got one file. Is everything in there?

Existentially, no.

:-)

The yogi comes up to the hotdog stand: "Make me one with everything!"

[Bill Gunshannon]

Post by Phillip Helbig---undress to reply

Post by Stephen Hoffman

Just got a set of Hobbyist PAKs...
So, here's my question. I got one file. Is everything in there?

Existentially, no.

:-)
The yogi comes up to the hotdog stand: "Make me one with everything!"

I heard you cold only do that att he zen hotdog stand.


Thanks for the help, all. Looking forwad to playing with VMS again, even
if it is only playing.

By the way, if there is anybody out there that needs some COBOL or Fortran
help and will accept tele-commuting, I am available for small contracting
gigs. Can always use beer money, even when retired.

bill

[Stephen Hoffman]

Post by Bill Gunshannon
By the way, if there is anybody out there that needs some COBOL or Fortran
help and will accept tele-commuting, I am available for small contracting
gigs. Can always use beer money, even when retired.

If you're headed that way, get yourself an LLC, and that for various reasons.
One of those reasons being access into the HP AllianceONE
<http://hp.com/go/allianceone> program.

[Bill Gunshannon]

Post by Stephen Hoffman

Post by Bill Gunshannon
By the way, if there is anybody out there that needs some COBOL or Fortran
help and will accept tele-commuting, I am available for small contracting
gigs. Can always use beer money, even when retired.

If you're headed that way, get yourself an LLC, and that for various reasons.
One of those reasons being access into the HP AllianceONE
<http://hp.com/go/allianceone> program.

Well, I wasn't really looking to start a business. Just pick up a
little extra scratch. And, actually, I don't really expect to hear
from anyone, but it didn't cost anything to throw it out there. I
just know from very recent experience (my last full-time gig) that
there is still a lot of COBOL and Fortran out there and less people
who can work with it every day.

bill

[Stephen Hoffman]

...Well, I wasn't really looking to start a business...

The AllianceONE program has various benefits, and having an LLC has
legal and tax benefits for both you and for somebody that might choose
to hire you.

[Richard B. Gilbert]

Post by Bill Gunshannon

Post by Stephen Hoffman

Post by Bill Gunshannon
By the way, if there is anybody out there that needs some COBOL or Fortran
help and will accept tele-commuting, I am available for small contracting
gigs. Can always use beer money, even when retired.

If you're headed that way, get yourself an LLC, and that for various reasons.
One of those reasons being access into the HP AllianceONE
<http://hp.com/go/allianceone> program.

Well, I wasn't really looking to start a business. Just pick up a
little extra scratch. And, actually, I don't really expect to hear
from anyone, but it didn't cost anything to throw it out there. I
just know from very recent experience (my last full-time gig) that
there is still a lot of COBOL and Fortran out there and less people
who can work with it every day.
bill

If anyone needs help writing, or reading, FORTRAN, I'm available,
for my customary outrageous fee! The math might as well be Greek
to me but if you break it down to arithmetic operations I can beat it
to death with my trusty computer!

I used to do that for my living back in the days when most people had
never seen a computer, let alone used one!

[BillPedersen]

Post by Bill Gunshannon
Just got a set of Hobbyist PAKs. Planning on bringing up a VAX or two
and maybe even my Alpha (which, unfortunately I only have one) and
do some playing around. Maybe even look at some Open Source widget
to port.
So, here's my question. I got one file. Is everything in there?
Do I just run this one file and it will activate VMS and all the
LP? I am confused because the old way there were two, One for
VMS and another for LP.
And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?
Within reason, of course. I may be retired, but I am not a
superman. :-)
Thanks everyone.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

The PAKs come as a single file for either the VAX/Alpha or IA64.

As far as Open Source we would be very happy to have your join the VMS-Ports Source Forge Project. We are working to centralize all the VMS Open Source porting activity or at least mirror source sites so as to reduce the likelihood of orphaned software or "lost" software.

We have fortnightly conference calls with OpenVMS Engineering on topics affecting open source ports as well as workarounds for issues dealing with porting to OpenVMS.

Good luck with your efforts.

Hope to see you around the VMS-Ports project.

Bill.

[Toby Thain]

Post by Bill Gunshannon
Just got a set of Hobbyist PAKs. Planning on bringing up a VAX or two
and maybe even my Alpha (which, unfortunately I only have one) and
do some playing around. Maybe even look at some Open Source widget
to port.
So, here's my question. I got one file. Is everything in there?
Do I just run this one file and it will activate VMS and all the
LP? I am confused because the old way there were two, One for
VMS and another for LP.
And, as long as I am asking, any suggestions on what from the
Open Source world that is not already on VMS might be of use?
Within reason, of course. I may be retired, but I am not a
superman. :-)

Somebody on #vax asked about Lua on VMS the other day.

Other suggestions:
* Latest PostgreSQL
* the esteemed SWI-Prolog http://www.swi-prolog.org/

--Toby

Post by Bill Gunshannon
Thanks everyone.
bill