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

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Jan-Erik Soderholm]

Bill Gunshannon wrote 2012-09-19 16:36:
> 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]

On 2012-09-19 16:36, "Bill Gunshannon" wrote:

> [...]

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

> 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

--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

[Phillip Helbig---undress to reply]

In article <abu3ka...@mid.individual.net>, bill...@cs.uofs.edu

(Bill Gunshannon) writes:

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

[Stephen Hoffman]

On 2012-09-19 14:36:58 +0000, Bill Gunshannon said:

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


--
Pure Personal Opinion | HoffmanLabs LLC

[BillPedersen]

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.

[Phillip Helbig---undress to reply]

In article <k3coua$hhv$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> On 2012-09-19 14:36:58 +0000, Bill Gunshannon said:
>
> > 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]

In article <k3cogq$j67$4...@online.de>,

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

[Bill Gunshannon]

In article <k3cpc2$j67$9...@online.de>,

hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:

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.

[Stephen Hoffman]

On 2012-09-19 16:33:33 +0000, Bill Gunshannon said:

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

In article <k3csga$c9t$1...@dont-email.me>,

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.

[Stephen Hoffman]

On 2012-09-19 16:45:10 +0000, Bill Gunshannon said:

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

[Bob Koehler]

In article <abua7g...@mid.individual.net>, bill...@cs.uofs.edu (Bill Gunshannon) writes:
>
> On my VAX? :-) How about right after Java support. :-)
>

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

[Phillip Helbig---undress to reply]

In article <abua7g...@mid.individual.net>, bill...@cs.uofs.edu

(Bill Gunshannon) writes:

> In article <k3cogq$j67$4...@online.de>,
> hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
> > In article <abu3ka...@mid.individual.net>, bill...@cs.uofs.edu
> > (Bill Gunshannon) writes:
> >
> >> 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. :-)

[JF Mezei]

Bob Koehler wrote:

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

On 2012-09-19 23:16:06 +0000, JF Mezei said:

> Bob Koehler wrote:
>
>>> 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 <seao...@hoffmanlabs.invalid> wrote:
(snip, someone wrote)

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

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

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

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

-- glen

[JF Mezei]

Stephen Hoffman wrote:

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

On 2012-09-20 00:26:54 +0000, JF Mezei said:

> Stephen Hoffman wrote:
>
>> 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.

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

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

[Arne Vajhøj]

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]

On 9/19/2012 7:16 PM, JF Mezei wrote:
> Bob Koehler wrote:
>
>>> 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

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

Arne

[JF Mezei]

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 ?

[JF Mezei]

Arne Vajhøj wrote:

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

[glen herrmannsfeldt]

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

(snip)

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

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

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

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

[Johnny Billquist]

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

[Michael Kraemer]

Johnny Billquist schrieb:

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

[Phillip Helbig---undress to reply]

In article <505a5237$0$39055$c3e8da3$88b2...@news.astraweb.com>, JF

Mezei <jfmezei...@vaxination.ca> writes:

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

[Richard B. Gilbert]

On 9/19/2012 12:45 PM, Bill Gunshannon wrote:
> In article <k3csga$c9t$1...@dont-email.me>,
> Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>> On 2012-09-19 16:33:33 +0000, Bill Gunshannon said:
>>
>>> 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!

[Bob Koehler]

In article <k3dgoe$66e$3...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
>
> 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-)

[Bob Koehler]

In article <505a5237$0$39055$c3e8da3$88b2...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>

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

[Bob Koehler]

In article <505a62cf$0$2013$c3e8da3$dd96...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>
> 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.

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

[Bob Koehler]

In article <505a7d83$0$12925$c3e8da3$40d4...@news.astraweb.com>, JF Mezei <jfmezei...@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. 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-)

[Bob Koehler]

In article <505a7d83$0$12925$c3e8da3$40d4...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>

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

[JF Mezei]

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.


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

[Phillip Helbig---undress to reply]

In article <KeDym3...@eisner.encompasserve.org>,

koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:

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

In article <k3fmhb$5c9$2...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip

Helbig---undress to reply) writes:

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

[Stephen Hoffman]

On 2012-09-20 18:16:11 +0000, Phillip Helbig---undress to reply said:

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

In article <k3fmt0$g6t$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

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

In article <k3fn87$5c9$4...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip

Helbig---undress to reply) writes:

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

[glen herrmannsfeldt]

Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
> In article <505a7d83$0$12925$c3e8da3$40d4...@news.astraweb.com>, JF Mezei <jfmezei...@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. 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.

> 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

[Stephen Hoffman]

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.

[glen herrmannsfeldt]

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]

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.

> 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

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

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

Johnny

[Johnny Billquist]

On 2012-09-20 19:29, Bob Koehler wrote:
> In article <505a62cf$0$2013$c3e8da3$dd96...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>>
>> 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]

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]

On 2012-09-20 21:01, Stephen Hoffman wrote:
> On 2012-09-20 18:53:41 +0000, Johnny Billquist said:
>
>> On 2012-09-20 19:29, Bob Koehler wrote:
>>> In article <505a62cf$0$2013$c3e8da3$dd96...@news.astraweb.com>, JF
>>> Mezei <jfmezei...@vaxination.ca> writes:
>>>>
>>>> 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.

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

On 2012-09-20 19:19:35 +0000, Johnny Billquist said:

> On 2012-09-20 21:01, Stephen Hoffman wrote:
>> On 2012-09-20 18:53:41 +0000, Johnny Billquist said:
>>
>>> On 2012-09-20 19:29, Bob Koehler wrote:
>>>> In article <505a62cf$0$2013$c3e8da3$dd96...@news.astraweb.com>, JF
>>>> Mezei <jfmezei...@vaxination.ca> writes:
>>>>>
>>>>> 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.

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

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

> I could just as well call any program Java with the same effect.

The owner of Java might disagree.

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

[glen herrmannsfeldt]

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

(snip, someone wrote)

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

[glen herrmannsfeldt]

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

(snip)

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

-- glen

[glen herrmannsfeldt]

Stephen Hoffman <seao...@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.

-- glen

[glen herrmannsfeldt]

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

(snip)

> 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

[Stephen Hoffman]

On 2012-09-20 20:33:10 +0000, glen herrmannsfeldt said:

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

[Phillip Helbig---undress to reply]

In article <k3fui6$piv$2...@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.

[Phillip Helbig---undress to reply]

In article <k3fuoh$qh2$1...@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.

[JF Mezei]

Phillip Helbig---undress to reply wrote:

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

[Single Stage to Orbit]

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

[Phillip Helbig---undress to reply]

In article <1348178030.1...@lithium.local.net>, Single Stage

to Orbit <alex....@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.

[Michael Kraemer]

Phillip Helbig---undress to reply schrieb:

> In article <k3fuoh$qh2$1...@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.)
>

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

Well, both are in the bombing business.

[Arne Vajhøj]

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.

Arne

[Arne Vajhøj]

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.

Arne

[Arne Vajhøj]

On 9/19/2012 10:20 PM, 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 ?

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 ?

Java use native integer format.

Arne

[Arne Vajhøj]

On 9/20/2012 1:36 PM, Bob Koehler wrote:

> In article <505a7d83$0$12925$c3e8da3$40d4...@news.astraweb.com>, JF Mezei <jfmezei...@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.

Arne

[Arne Vajhøj]

On 9/19/2012 10:28 PM, JF Mezei wrote:
> 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.

Arne

[Arne Vajhøj]

On 9/20/2012 3:19 PM, Johnny Billquist wrote:
> 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

[Arne Vajhøj]

Or a more on familiar example: DEC computers versus vacuum cleaners.

But Oracle is more aggressive in court than most companies.

Arne

[Arne Vajhøj]

The last may not be a good example.

Terrorist groups probably do not even try to adhere to
laws protecting trademarks.

Arne

[Michael Kraemer]

Arne Vajh�j schrieb:

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

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

(snip)

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

[John E. Malmberg]

On 9/20/2012 3:49 PM, Stephen Hoffman wrote:
> On 2012-09-20 20:33:10 +0000, glen herrmannsfeldt said:
>
>> 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
wb8...@qsl.network
Personal Opinion Only

[Johnny Billquist]

Except when it is a value for which there is no representation in VAX FP.

Johnny

[Johnny Billquist]

Yes it is, since not all IEEE values have equivalent VAX FP values. What
do you do then?

Johnny

[Johnny Billquist]

On 2012-09-21 04:04, Arne Vajhøj wrote:
> On 9/20/2012 1:36 PM, Bob Koehler wrote:
>> In article <505a7d83$0$12925$c3e8da3$40d4...@news.astraweb.com>, JF
>> Mezei <jfmezei...@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.

Johnny

[Johnny Billquist]

On 2012-09-20 22:30, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip)
>
>> 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

[Johnny Billquist]

On 2012-09-20 21:39, Stephen Hoffman wrote:
> On 2012-09-20 19:19:35 +0000, Johnny Billquist said:
>
>> On 2012-09-20 21:01, Stephen Hoffman wrote:
>>> On 2012-09-20 18:53:41 +0000, Johnny Billquist said:
>>>
>>>> On 2012-09-20 19:29, Bob Koehler wrote:
>>>>> In article <505a62cf$0$2013$c3e8da3$dd96...@news.astraweb.com>, JF
>>>>> Mezei <jfmezei...@vaxination.ca> writes:
>>>>>>
>>>>>> 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.

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

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

>> I could just as well call any program Java with the same effect.
>

> The owner of Java might disagree.

See above.

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

> 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

[Joseph Huber]

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.

--

Remove NOREPLY. from Email address.
Joseph Huber, http://www.huber-joseph.de

[glen herrmannsfeldt]

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

(snip regarding little endianness)

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

> 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

[Stephen Hoffman]

On 2012-09-21 08:06:04 +0000, Johnny Billquist said:

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

[Paul Sture]

In article <505b9093$0$39191$c3e8da3$3863...@news.astraweb.com>,

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.

--
Paul Sture

[Paul Sture]

In article <k3h6ot$b0s$2...@Iltempo.Update.UU.SE>,

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

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

--
Paul Sture

[Paul Sture]

In article <k3h88k$2jim$1...@gwdu112.gwdg.de>,

Joseph Huber <joseph...@NOREPLY.web.de> wrote:

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

--
Paul Sture

[Bill Gunshannon]

In article <nospam-98451A....@news.chingola.ch>,

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


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Joseph Huber]

Bill Gunshannon wrote:

> In article <nospam-98451A....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> writes:
>> In article <k3h88k$2jim$1...@gwdu112.gwdg.de>,
>> Joseph Huber <joseph...@NOREPLY.web.de> wrote:
>>
>>> 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]

In article <k3ho4t$1h1$1...@gwdu112.gwdg.de>,

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.

[Bob Koehler]

In article <k3fmhb$5c9$2...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
>
> 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.

[Bob Koehler]

In article <k3fmso$dqa$1...@lnx107.hrz.tu-darmstadt.de>, m.kr...@gsi.de (Michael Kraemer) writes:

> And DEC should have known better.

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

[Bob Koehler]

In article <k3fo7f$8um$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:

> Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
>> 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.

[Doug Phillips]

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]

In article <k3i0rq$ehh$1...@dont-email.me>, Doug Phillips

<dphi...@netscape.net> writes:

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

Hopefully the most significant bits. :-)

[glen herrmannsfeldt]

Paul Sture <nos...@sture.ch> wrote:
> In article <k3h6ot$b0s$2...@Iltempo.Update.UU.SE>,
> Johnny Billquist <b...@softjar.se> wrote:

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

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

[glen herrmannsfeldt]

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

(snip)

> 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

[glen herrmannsfeldt]

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]

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.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Rich Alderson]

glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:

> Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:

>> In article <k3fmso$dqa$1...@lnx107.hrz.tu-darmstadt.de>, m.kr...@gsi.de
>> (Michael Kraemer) writes:

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

[Joseph Huber]

glen herrmannsfeldt wrote:

> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>
> (snip)
>
>> 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.

--

Joseph Huber - http://www.huber-joseph.de

[Bill Gunshannon]

In article <k3i5i0$qtc$1...@speranza.aioe.org>,

glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>
> (snip)
>
>> 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. :-)

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

>
> 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 Gunshannon]

In article <4190927.e...@huber-joseph.homeip.net>,

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.

[JF Mezei]

Joseph Huber wrote:

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

I learned to read dumps on IBM systems and felt the big endian was very
natural to read. Never quite got the hang of reading little endian dumps.

Consider a binary value:

0011 1011 0111 1100

the rightmost bit in each nibble is the low order bit by convention, no
matter what endianness is involved.

so you end up with

3 B 7 C

It makes sense to consider C to be the low order nibble since this uses
the same principle of right most being low order.

Another way to put it:

which is more readable for value of 1 :

01000000 or 00000001 ?
little big


Back in the days where reading hex dumps was common, I suspect that the
choice of big endian may have been done to make the readon of those
dumps easier.

Also, consider multiplication by two. One would say "shift left 1 bit".
Works well for big endian, but for little endian, it becomes a mess
because you need to do this byte by byte and transpose the extra bit o
the leftmost byte onto the rightmost bit of the next byte.


Now, once reading printed hex dumps became less common, human
readability of dumps was less of an advantage.

However, at the CPU architecture/performance level, would it be correct
to state that bit shifting of 4 or 8 byte intergers is faster/simpler on
big endian than little endian ?