My apologies to Mike Yawn for taking so long to
reply;  there were some in-house things and
SIGIMAGE stuff I had to get done.   Anyway:

Mike after me:

>Ken Sletten b894 c332 x62525 ([log in to unmask]) wrote:
>: Plus I invite others to join the agitation for HP to
>: encourage (i.e.:  provide some $) for a serious
>: investigation into whether or not it is feasible to
>: "front end" Java on the GNU C++ compiler on the
>: 3000.  If it is technically feasible, then go for it.

[....SNIP....]
>Two questions: Why native compilation, rather than a
>Just-in-Time compiler, and second, why the GNU C++
>back-end?

>On the first topic, those of us working on Java internally
>seem to be unanimously agreed that we would prioritize a
>JIT ahead of a native compiler.  We don't yet have good data
>on what the relative performance of javac vs. jit vs. native
>compilers is / will be; but the JIT has the (to my mind,
>overwhelming) advantage of preserving Java's "write once,
>deploy anywhere" model: that is, you don't need access to
>the source code to run a Java class through the just-in-time
>compiler.  Some folks on the java newsgroups even seem to
>think that JITs may outperform native compilers over the
>long term......

Frist of all, please keep in mind that I am in no way, shape, or
form a techie expect in this area;  I was and am coming at this
from an end-user perspective;  and a site-specific perspective,
at that.  Let me try and expand a bit:

I was not trying to suggest that any current priorites should
change;  the things you are working on and the order you
are doing them seem reasonable and prudent to me.  I was
trying to look down the road a ways, with two things in mind:

(1)  From a couple talks I attended, and from experience
with other languages, I thought it was a forgone conclusion
that execution speed of a native Java compiler would be
MUCH faster.  I recall that the guy who wrote the "Java API
Super Bible" that gave a talk at NOWRUG this spring (his
name escapes me at the moment) said that in some other
cases on other platforms, the execution speed difference
was a much as 100-to-1.  If JIT compilers might end up
even coming close to native compiler performance, that's
a whole 'nother story..

(2)  On the 3000 end of our in-house client-server project,
we are a Transact/iX shop.  Transact does what it does
very well, but since it is a stack-based language, it does
not do client-server, sockets-based I/O very well, where
you may not know if the next packet(s) coming in on a
socket will total 100 bytes or 20KB.  Grabbing additional
memory space on the fly like you can with C doesn't work
very well (or hardly at all) in Transact (how many other
3000-based compilers are essentially in the same boat
I'm not sure;  but there is a huge amount of legacy (i.e.:
very valuable) code out there).

BUT:  If a network server process on the 3000 can call NM
Transact modules out of an XL to do the Image and MPE
file I/O and business rules, then we can keep using Transact
for most of the things it does best, while efficiently supporting
client-server I/O.  This is effect what we are implementing
here at NUWC Keyport, using the C server process Steve
Dirickson wrote.....  Even from the little I know about it, doing
PROC calls from C to do complex Image database I/O
doesn't look very appetizing:  In many cases I can probably
do in 10 lines of Transact code what takes ~100+ lines of C;
especially stuff like multi-level recursive routines, which can
be incredibly compact in Transact/iX.

SUMMARY:  What I was blue-skying was the possibility of
using JAVA for client-server programming on the 3000,
where we might never run the resulting code anywhere
except on the 3000.  And to be able to call Transact modules
out of an XL, I assumed (am I wrong ??) that we would have
to have a native Java compiler to be able to do that;  or at
least to be able to do that with any kind of acceptable
efficiency ??

BACKGROUND CONFESSION:   I am hopelessly behind on
becoming an accomplished "C" programmer.  Even though
Java may be based on C, if it ends up delivering on at least
some of the hype I was hoping the Java learning curve to
becoming at least a marginally proficient programmer would
be a lot shorter than starting from scratch with C.  So I was
really looking at the possibility of Java being useable as a
full-fledged programming language on the 3000.... But maybe
with an added benefit that we could use like the latest MS
J++ Developer's Studio environment or etc. to write the Java
code (A complete native Softbench environment on the 3000
would be nice, but not holding my breath for that anymore).
........  Like I said, I'm just blue-skying here.

>On the second topic, we have at least kicked around the
>possibility of a native compiler, and while one of the
>possibilities is to base it on GNU, at least one of the
>possibilities is to base it on something else.  Is there
>a reason why 'something else' is inherently inferior?

Not at all.....  I thought GNU was the only way to do it, since
it is the only C++ on the 3000....  If there is another option,
by all means explore all and use the best one.....

.... I should perhaps have educated myself a little better
before shooting off that last email......  On the other hand,
a lot of times that is how I manage to educate myself a little....

:-)  ,

Ken "waiting for all my Java books to get here" Sletten