ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

	 ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

            Brest, France, September 11, 1997


Today, at the Workshop on Methods and Tools for Ada 95 in Brest, France, Ada
Core Technologies and ACT Europe announced a joint project to port the GNAT
Ada 95 technology to the Java programming environment. This work is partially
supported by the Ada Joint Program Office.

The Java(TM) technology, recently introduced by Sun Microsystems, is a
paradigm whose goal is to add programming flexibility to the Internet in a
platform-independent manner.

Although the Java environment comes with a default programming language, this
language is not a fundamental component of the technology. Any programming
language which can be mapped onto the Java Virtual Machine can be used to
develop Java applications.

The final GNAT-to-Java system, to be implemented entirely in Ada 95, will be
available from Ada Core Technologies and ACT Europe, with full commercial
support.

Following the standard policies of Ada Core Technologies, the entire system
will be distributed as free software, and will be freely available, with
source code, through the Internet.  Because of the large GNAT user community,
porting GNAT to the Java environment will be an effective way to reinforce
Ada's position in the emerging arena of Internet computing, making GNAT the
first end-to-end Free Software solution in this growing market.

An important objective of our project is to make our product fully
interoperable with Java, the programming language, allowing programmers to
freely and naturally interface between Ada packages and Java classes, with
the ability to have class (or tagged type) hierarchies cross language
boundaries. Programmers will be able to use the full Java API and Foundation
Classes as well as write JavaBeans components in Ada and be assured that
their code will be fully interoperable with the Java world and Java enabled
browsers.

A preliminary demo of an Ada-to-Java byte code compiler will be given at
Tri-Ada in St. Louis and public releases of the GNAT-to-Java system will be
made available periodically.

Commercial support for the GNAT-to-Java system will be available from
Ada Core Technologies. For more information please contact:

In the U.S., contact Ada Core Technologies at:
Tel: +1 (212) 620 7300 ext 117
Fax: +1 (212) 807 0162
Email: sales@gnat.com

In Europe, contact ACT Europe at:
Tel: +33 1 55 58 00 22
Fax: +33 1 55 58 00 23
Email: sales@act-europe.fr

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Stephen Leake]

Robert Dewar wrote:
> 
>          ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

All Right!

> <snip!>
>
> The final GNAT-to-Java system, to be implemented entirely in Ada 95,

This sounds like you are NOT planning on adapting the backend of gcc to
write JVM byte codes, but are instead implementing a new backend in Ada.
This is cool! Will this backend be as data-driven as gcc? What I really
want to know is; will I be able to adapt the new backend to my flight
processor, and abandon gcc? gcc is great, but adapting it means writing
K&R level C; I'd much rather be writing Ada95!

-- 
- Stephe

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Stephe says

<<This sounds like you are NOT planning on adapting the backend of gcc to
write JVM byte codes, but are instead implementing a new backend in Ada.
This is cool! Will this backend be as data-driven as gcc? What I really
want to know is; will I be able to adapt the new backend to my flight
processor, and abandon gcc? gcc is great, but adapting it means writing
K&R level C; I'd much rather be writing Ada95!>>

That's right -- making GCC produce JVM byte code makes no sense, since the
level of abstraction is quite wrong. What we are doing is a completely new
backend that generates JVM from the GNAT tree.

As to your question about adaptation, if you believe that going through
JVM and JIT compilers etc can yieled acceptably efficient code then indeed
you can follow this path (and perhaps you can also get a job as a publicity
agent for Sun :-)

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Ralph Paul]

Robert Dewar wrote:
> That's right -- making GCC produce JVM byte code makes no sense, since the
> level of abstraction is quite wrong. What we are doing is a completely new
> backend that generates JVM from the GNAT tree.
> 
> As to your question about adaptation, if you believe that going through
> JVM and JIT compilers etc can yieled acceptably efficient code then indeed
> you can follow this path (and perhaps you can also get a job as a publicity
> agent for Sun :-)

Hold on !! Sun has the HotFlash technology still waiting to used (;-).
I'm sure everything is going to be great once we get the benefit of this
stuff
(;-).

Has anybody thought about the slim binaries idea popular in the Oberon-2
camp ?
(Just a question)

Regards,

Ralph Paul

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Ralph Paul says

<<Hold on !! Sun has the HotFlash technology still waiting to used (;-).
I'm sure everything is going to be great once we get the benefit of this
stuff>>

Don't get me wrong, I think that the Ada to JVM technology has great
promise (or we would not be embarking on this project), but the idea
of using it to get greater portability in avionics applications seems
pushing things a bit :-)

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Ralph Paul]

Robert Dewar wrote:
> 
> Ralph Paul says
> 
> <<Hold on !! Sun has the HotFlash technology still waiting to used (;-).
> I'm sure everything is going to be great once we get the benefit of this
> stuff>>
> 
> Don't get me wrong, I think that the Ada to JVM technology has great
> promise (or we would not be embarking on this project), but the idea
> of using it to get greater portability in avionics applications seems
> pushing things a bit :-)

Just to clarify :
- I think that the Ada95 to JVM stuff is really important
  in letting Ada95 ( Aonix and sooner or later GNAT) surf the Java wave
  ( and offer better solutions in specific problem domains) 
  For example I was able to influence some managers to consider Ada95 as
  a possible standard language for really long term project because they 
  recognized that there is life besides C++,Fortran due to the Java
buzzword. 
  ( The prospect of using Ada95 compiled apps on the future NC's 
    isn't bad for business either. (:-) )
- Java is a interesting language and the environnment is a great step
forward towards
   portability. ( Being an OS/2 I can attest the small problems people
have
   when porting Java stuff from WinXX to other platforms. Just look at
the
   different version numbers of the JDK on Mac, WinXX, ... )
- I am just really sick of hearing the SUN people promising the famous
magic silver bullet
  every time that they annouce a new Java related product. 
  ( Serious software people/engineers/managers know that good software
is not 
    created by some "magic bullet" released from Sun-Labs. It's still
serious work by
    competent people )

Enough rambling for today and best wishes for a quick completion.

Ralph Paul

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Brian Rogoff]

On 14 Sep 1997, Robert Dewar wrote:
> Ralph Paul says
> 
> <<Hold on !! Sun has the HotFlash technology still waiting to used (;-).
> I'm sure everything is going to be great once we get the benefit of this
> stuff>>
> 
> Don't get me wrong, I think that the Ada to JVM technology has great
> promise (or we would not be embarking on this project), but the idea
> of using it to get greater portability in avionics applications seems
> pushing things a bit :-)

I realize that the JVM port is motivated (quite rightly, IMO) by economic 
reasons, but I wonder if some other "intermediate form" besides byte 
codes might be better if one wanted a portable format which could then 
be compiled. 

-- Brian

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Tarjei T. Jensen]

Brian Rogoff wrote:
> 
> I realize that the JVM port is motivated (quite rightly, IMO) by economic
> reasons, but I wonder if some other "intermediate form" besides byte
> codes might be better if one wanted a portable format which could then
> be compiled.
>

I suppose you just end up with a more high level machine code.

The internals of GCC may be what you want. There is som sort of
interface between the compiler and the code generator. The internals of
the code generator depends on the target.

Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Tarjei says

<<The internals of GCC may be what you want. There is som sort of
interface between the compiler and the code generator. The internals of
the code generator depends on the target.>>

That's very confused. No, the internals of the code generator do NOT
depend on the target, that's the whole point. The GCC has only one code
generator, which is data driven, where the data is the configuration file
that describes the machine architecture. As for 
some sort of interface", this interface is purely procedural.

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Ralph Paul]

Brian Rogoff wrote:
> 
> On 14 Sep 1997, Robert Dewar wrote:
> > Ralph Paul says
> >
> > <<Hold on !! Sun has the HotFlash technology still waiting to used (;-).
> > I'm sure everything is going to be great once we get the benefit of this
> > stuff>>
> >
> > Don't get me wrong, I think that the Ada to JVM technology has great
> > promise (or we would not be embarking on this project), but the idea
> > of using it to get greater portability in avionics applications seems
> > pushing things a bit :-)
> 
> I realize that the JVM port is motivated (quite rightly, IMO) by economic
> reasons, but I wonder if some other "intermediate form" besides byte
> codes might be better if one wanted a portable format which could then
> be compiled.
> 
> -- Brian

There already one such thing. It's called slim binaries and is used on
some 
Oberon-2 system. These system use some sort of abstract tree
representation
as "byte-code". This AST is then compiled on the fly on the supported
platform.
>From what I read on it  the technology gives you protable object-code
and
native peformance. Also the program flow analysis which is done in Java
to
determine malicious programs gets easier to do.

see http://www.ics.uci.edu/~franz/  and look for slim binaries.


CU,

Ralph Paul

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Ralph replies to Paul:

<<> I realize that the JVM port is motivated (quite rightly, IMO) by economic
> reasons, but I wonder if some other "intermediate form" besides byte
> codes might be better if one wanted a portable format which could then
> be compiled.
>
> -- Brian

There already one such thing. It's called slim binaries and is used on
some
Oberon-2 system. These system use some sort of abstract tree
representation
as "byte-code". This AST is then compiled on the fly on the supported
platform.
>From what I read on it  the technology gives you protable object-code
and
native peformance. Also the program flow analysis which is done in Java>>



Oh goodness, this is an OLD OLD idea, P-code is of course one of the earliest
and best known attempts (there was a whole technology of native code 
generators, and no doubt you could find a SMS sales person willing to make
the same absurd claim of 100% portability with native performance that is
always bandied about for such systems.

But there are literally dozens of designs and attempts in this direction,
it is after all a perfectly obvious idea, closely related to the ancient
UNCOL proposal.

For a slightly more credible attempt, see the DDCI technical product
information, which describes how they use one of the more sophisticated
approaches along these lines. If DDCI is listening, I will let them fill
in the details!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>There already one such thing. It's called slim binaries...

>Oh goodness, this is an OLD OLD idea, P-code is of course one of the earliest
>and best known attempts (there was a whole technology of native code 
>generators, and no doubt you could find a SMS sales person willing to make
>the same absurd claim of 100% portability with native performance that is
>always bandied about for such systems.

Nope.  "Slim binaries" are absolutely NOTHING LIKE P-code.
Slim binaries are based on two ideas:
    - source code compresses very well
    - IO is slow.

Slim Binaries are used in the Juice system, currently available for
PCs and PowerMacs.  The idea is very simple, and the implementation is
rather elegant.  The precompiler parses a source file, does all the
static checks, may make other completely portable transformations,
and then emits

    > compressed annotated abstract syntax graphs <

At run-time, the Juice system reads the slim binary, decompressing and
building the AST as it goes, and then runs a normal compiler back end
to generate native code.

>But there are literally dozens of designs and attempts in this direction,
>it is after all a perfectly obvious idea, closely related to the ancient
>UNCOL proposal.

Just how obvious is it?  Everybody else seems to have tried to invent some
kind of abstract machine.  The Oberon people seem to be the only people
who really noticed that source code compresses so well and discs are
(relatively) so slow these days that NOT having any kind of 'object' code
would yield a _faster_ system over-all.  They claim that they spend _less_
time decompressing and generating native code into memory than they used
to spend relocating conventional machine code, in large part because the
files are _dramatically_ smaller.

I have just spent a day trying the idea out for another language, and
gzipped stripped source code is about 7.5 times smaller than the existing
"portable object files" for this other language, to the point where the
great majority of modules take less than 8k.

With slim binaries, you get 100% of native performance BECAUSE YOU RUN
ONLY NATIVE CODE, generated by a perfectly conventional in-core compiler
back end.  If you look at a modern object file format like ELF, you will
appreciate that parsing object files is a non-trivial task, and that
object files are typically fairly large.  For example, a slim binary
doesn't _need_ a separate line number section, or a separate symbol
table, or a separate anything.

>For a slightly more credible attempt,

Slim binaries are as credible as anyone could wish for.
They apply well understood techniques in a novel way, and anyone
who wants to suck-it-and-see can download a copy of Juice and
measure loading times for himself.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Jon S Anthony]

In article <5vt73c$3nk$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

<slim binaries, the real scoop>

> Slim binaries are as credible as anyone could wish for.
> They apply well understood techniques in a novel way, and anyone
> who wants to suck-it-and-see can download a copy of Juice and
> measure loading times for himself.

This sounds very interesting.  Would you or anyone else post a
reference from where one can "suck-it-and-see"??

Many thanks,

/Jon

-- 
Jon Anthony
STL, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Jay Han]

In article <JSA.97Sep19161326@alexandria.organon.com>,
jsa@alexandria.organon.com (Jon S Anthony) wrote:

> In article <5vt73c$3nk$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au
(Richard A. O'Keefe) writes:
> 
> <slim binaries, the real scoop>
> 
> > Slim binaries are as credible as anyone could wish for.
> > They apply well understood techniques in a novel way, and anyone
> > who wants to suck-it-and-see can download a copy of Juice and
> > measure loading times for himself.
> 
> This sounds very interesting.  Would you or anyone else post a
> reference from where one can "suck-it-and-see"??
[...]
Alta-Vista?

Juice homepage:
http://www.ics.uci.edu/~juice/

Look at Prof. M. Franz's page as well.  His thesis is about an older
version of SB.

There was a thread on the subject on comp.compiler a few months ago.  Look
for the subject Slim Binary.

   J

> -- 
> Jon Anthony
> STL, Belmont, MA 02178, 617.484.3383 
> "Nightmares - Ha!  The way my life's been going lately,
>  Who'd notice?"  -- Londo Mollari

-- 
jayhan@wam.umd.edu

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Richard A. O'Keefe]

jsa@alexandria.organon.com (Jon S Anthony) writes:
>This sounds very interesting.  Would you or anyone else post a
>reference from where one can "suck-it-and-see"??

The Juice home page is
http://www.ics.uci.edu/~juice/

The inventor of Slim Binaries is Michael Franz, whose PhD thesis on
the subject is available from
ftp://ftp.inf.ethz.ch/pub/publications/dissertations/th10497.ps.gz

The crucial point here that makes "Uncol" an utterly inappropriate stick
to beat Slim Binaries with is that they aren't universal.  You need a
_different_ Slim Binary format for each different language.  To translate
Ada to Juice format, for example, would not just be as hard has source
translation to Oberon, it would _be_ source translation to Oberon.  This
is both a strength and a weakness, but then, what isn't?

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

<<Nope.  "Slim binaries" are absolutely NOTHING LIKE P-code.
Slim binaries are based on two ideas:
    - source code compresses very well
    - IO is slow.

Slim Binaries are used in the Juice system, currently available for
PCs and PowerMacs.  The idea is very simple, and the implementation is
rather elegant.  The precompiler parses a source file, does all the
static checks, may make other completely portable transformations,
and then emits

    > compressed annotated abstract syntax graphs <

At run-time, the Juice system reads the slim binary, decompressing and
building the AST as it goes, and then runs a normal compiler back end
to generate native code.>>


This only makes sense if your compilers have succeeded in employing the
techniques we developed in the 70's and early 80's to make compiler
front ends absurdly slow. Lexical analysis and parsing are instantaneous
if done right. My Ada lex/parser for Ada 83 runs at over 10 million
lines a minute on a reasonable fast PC, including IO, and trying to
optimize this part away is a waste of time. Distributing compressed
sources makes sense, doing anything more to them does not if you
are following this kind of approach. I find the slim binary approach
to be completely without merit.

But to understand why your "nope" is wrong, bump your level of 
abstraction up a bit. The slim binary approach and the P-Code approach
and the Java approach, and similar approaches over time, are all trying
to solve the problem of how to distribute software in a completely
portable manner. 

Actually it is not hard at all to solve this problem, you can just
distribute sourrce and be done with it, and that of course is
Richard Stallman's precsription for how to solve this problem.

In practice, distribution of source has two problems, of a very different
nature:

1. Building large systems from sources can be a very tricky business,
requiring skills that a user of the system does not necessarily have.

2. For those who want to keep their software proprietary, distributing
sources fills them with horror :-)

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 >[Richard O'Keefe writes:]
 ><<Nope.  "Slim binaries" are absolutely NOTHING LIKE P-code.
 >Slim binaries are based on two ideas:
 >    - source code compresses very well
 >    - IO is slow.
...
 >    > compressed annotated abstract syntax graphs <
 >
 >At run-time, the Juice system reads the slim binary, decompressing and
 >building the AST as it goes, and then runs a normal compiler back end
 >to generate native code.>>
 >
 >This only makes sense if your compilers have succeeded in employing the
 >techniques we developed in the 70's and early 80's to make compiler
 >front ends absurdly slow.

I don't agree.  There is an advantage in using a different format
than source code for distribution, even if parsing speed is ignored.
The advantage is that you can solve most of problem #1 of the two
you mention below.

 >In practice, distribution of source has two problems, of a very different
 >nature:
 >
 >1. Building large systems from sources can be a very tricky business,
 >requiring skills that a user of the system does not necessarily have.
 >
 >2. For those who want to keep their software proprietary, distributing
 >sources fills them with horror :-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

<<I don't agree.  There is an advantage in using a different format
than source code for distribution, even if parsing speed is ignored.
The advantage is that you can solve most of problem #1 of the two
you mention below.>>

I would be interested in why you think this? Is this based on experience
with slim binaries? I would guess not. In fact I doubt slim binaries have
been used on the kind of large projects where building from sources can
be an issue.

In fact building from sources works remarkably well. I am always impressed
when we pull off soe new GPL tool, type the configure command, and everything
works.

The problems I see in building from sources (e.g. which exact version of
what do you use for the build) would not be solved by slim binaries, since
they still have to be compiled, and indeed all the hard part of compilation
remains. 

So if anything the situation is worse. Now, we cannot simply use whatever
standard C compiler we have around to build a tool from scratch, but we
have to make sure we get the right binary version of the compiler to handle
the slim binary. Indeed this is what makes GNAT harder to build than GNU C.
You need a GNAT compiler to start with, and you have to make sure you get
all the right versions and pieces.

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Stephen Leake]

Robert Dewar wrote:
> 
> Stephe says
> 
> <<This sounds like you are NOT planning on adapting the backend of gcc to
> write JVM byte codes, but are instead implementing a new backend in Ada.
> This is cool! Will this backend be as data-driven as gcc? What I really
> want to know is; will I be able to adapt the new backend to my flight
> processor, and abandon gcc? gcc is great, but adapting it means writing
> K&R level C; I'd much rather be writing Ada95!>>
> 
> That's right -- making GCC produce JVM byte code makes no sense, since the
> level of abstraction is quite wrong. What we are doing is a completely new
> backend that generates JVM from the GNAT tree.

I guess I need to read up on the JVM. I've been assuming it was at the
same level as the UCSD Pascal P-machine; basically a virtual 32 bit
processor, with operations like a current-generation RISC chip. I guess
this is wrong.

Can anyone recommend a _good_ intro to the JVM? I go to Borders, and
have a hard time choosing from all the books promising to teach me Java
in 10 days :).

> 
> As to your question about adaptation, if you believe that going through
> JVM and JIT compilers etc can yieled acceptably efficient code then indeed
> you can follow this path (and perhaps you can also get a job as a publicity
> agent for Sun :-)

Yeah, and I can deliver a Working System Real Soon Now. I hoped I would
be able to take your new backend, and make it generate assembler for my
chip, instead of "assembler" for the JVM.

Even if you are not replacing gcc for real processors now, maybe you
could try to make it possible to eventually use this backend as a
replacement for part of gcc (talk about vague requirements!). We need to
get away from K&R in the core of our compilers sometime! 

I guess this is what Intermetrics has; the AdaMagic front end
accommodates several backends. Is that all written in Ada?

-- 
- Stephe

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Mark L. Fussell]

Stephen Leake wrote:
[SNIP]
> Can anyone recommend a _good_ intro to the JVM? I go to Borders, and
> have a hard time choosing from all the books promising to teach me Java
> in 10 days :).

Fortunately there are fewer books focused on the JVM.  The two main ones
are:
   Tim Lindholm & Frank Yellin, The Java Virtual Machine Specification
   Addison-Wesley, 1997.  ISBN 0-201-63452-X

   Jon Meyer & Troy Downing, Java Virtual Machine
   O'Reilly, 1997. ISBN 1-56592-194-1

Of these, I like the second slightly more but they can complement each
other on certain topics.  The Meyer book also includes a copy of Jasmin:
an Assembler for the JVM.

You can also browse/download an electronic copy of the Lindholm book
online at:
   http://www.javasoft.com/docs/books/vmspec/index.html

You can get a copy of Jasmin from:
   http://found.cs.nyu.edu/meyer/jasmin/

--Mark
mark.fussell@chimu.com

  i   ChiMu Corporation      Architectures for Information
 h M   info@chimu.com         Object-Oriented Information Systems
C   u    www.chimu.com         Architecture, Frameworks, and Mentoring

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Tucker Taft]

Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote:

: ...
: I guess this is what Intermetrics has; the AdaMagic front end
: accommodates several backends. Is that all written in Ada?

The AdaMagic front end was written in ANSI C.  One reason was to avoid 
the bootstrapping problem, which was profound for us since we
weren't building a general purpose backend, and we wanted to be the
first to validate an Ada 95 compiler (albeit for a 24-bit embedded
target).  

Perhaps more importantly, our target market is vendors selling compilers 
with backends generally written in C, so we felt this would ease 
the ability of our licensees to integrate our front end with their 
back end.  Amusingly enough, our first two backends, the one we ourselves 
wrote for the Patriot ground-systems control computer, and the one 
from Aonix, were both written in Ada (83).

In any case, we ended up writing in a kind of Ada95-ized C, with the 
equivalent of package specs and private types, represented using
visible and private header files and lots of accessor functions, and type 
extension represented using a nested parent component and explicit 
conversion functions, etc.  It has been pretty reliable and maintainable, 
but you still get caught periodically by the annoying C human engineering 
stupidities (gcc "-Wall" helps a little).

The AdaMagic run-time system is written in Ada 95, but run-time systems
generally need to be compiled by the associated compiler
anyway, so there isn't really a "bootstrapping" issue.  And as
mentioned above, our "own" backend is written in Ada 83, as is
our debugger.

Of course, if we could have delayed our start date a few years,
we would have written our front end in Ada 95, and we still have vague 
dreams of incrementally converting it to Ada 95.  On the other hand,
chasing bugs in ANSI C code does provides a nice regular reminder of 
why I prefer Ada ;-).

: -- 
: - Stephe

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Tucker said

<<The AdaMagic front end was written in ANSI C.  One reason was to avoid
the bootstrapping problem, which was profound for us since we
weren't building a general purpose backend, and we wanted to be the
first to validate an Ada 95 compiler (albeit for a 24-bit embedded
target).>>

I don't see your point here. if your compiler is an Ada compiler written
in C, it cannot be bootstrapped anyway. Furthermore, your first target
was clearly a cross compiler, so you could have chosen any host for which
an Ada 83 compiler was available.

I understand there may be other reasons, but I don't quite see this 
reason ...

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Stephe said

<<<<I guess I need to read up on the JVM. I've been assuming it was at the
  same level as the UCSD Pascal P-machine; basically a virtual 32 bit
  processor, with operations like a current-generation RISC chip. I guess
  this is wrong.>>

Completely wrong, JVM is nothing like a conventional machine language

<<Yeah, and I can deliver a Working System Real Soon Now. I hoped I would
  be able to take your new backend, and make it generate assembler for my
  chip, instead of "assembler" for the JVM.

No, that's completely inappropriate.

<<Even if you are not replacing gcc for real processors now, maybe you
  could try to make it possible to eventually use this backend as a
  replacement for part of gcc (talk about vague requirements!). We need to
  get away from K&R in the core of our compilers sometime!>>

It is obvious from this that you know very little about gcc, so while you
are reading up on JVM, read up on GCC too. The GCC backend has nothing to
do with C or K&R per se, it is a code generator that can take input from
multiple front ends (one is the GNU C compiler, one is GNAT, there are
several others), and generate output for a very large variety of
architectures.

Basically if you want GCC to generate code for a new target, you just write
a formal definition of the instruction set for that architecture, called
a machine configuration file, and everything else is automatic. Writing
these configuration files is quite a straightforward task once you are
familiar with the technical approach.

<<I guess this is what Intermetrics has; the AdaMagic front end
  accommodates several backends. Is that all written in Ada?>>

That's of interest to interface to existing foreign front ends, especially
if you want to keep them proprietary, but for generating code for a new
machine there is no advantage unless you have a code generator in your
pocket that for some reason you want to use instead of GCC. But it sounds
like in fact GCC is exactly what you are looking for, a code generator
that can generate code for a variety of machines using the GNAT front end.

There is no point in trying to make the Java system do what you want, as
you will see if you do your homework in both areas :-)

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Stephen Leake]

Robert Dewar wrote:
> 
> Stephe said
>
> <<Even if you are not replacing gcc for real processors now, maybe you
>   could try to make it possible to eventually use this backend as a
>   replacement for part of gcc (talk about vague requirements!). We need to
>   get away from K&R in the core of our compilers sometime!>>
> 
> It is obvious from this that you know very little about gcc, so while you
> are reading up on JVM, read up on GCC too. The GCC backend has nothing to
> do with C or K&R per se, it is a code generator that can take input from
> multiple front ends (one is the GNU C compiler, one is GNAT, there are
> several others), and generate output for a very large variety of
> architectures.

I guess I wasn't clear. I do understand that gcc meets my needs; in
fact, I am using it. I've ported the gcc backend to generate assembler
code for the UT69R000 microprocessor. What I meant by getting away from
K&R is that the gcc _source_ is _written_ in K&R style C; for example,
functions are often not declared before they are used (at least in the
user configuration files I was editing). This has bitten me several
times. I tried to include the headers that defined the functions that I
was using, but could not figure out an include order that worked; some
macro or other was always left undefined. I understand that this style
was necessary when gcc was started; K&R compilers were the only
compilers available. And it is precisely this style, together with a
liberal use of preprocessing, that makes gcc operate on so many hosts. 

I understand that there is a _HUGE_ amount of work in truly replacing
the current gcc with an equivalent Ada 95 implementation. I am sure ACT
cannot afford that on its own; that is why I was surprised to hear that
the JVM implementation was not using gcc. Now I have an inkling of why;
the JVM is not similar to a typical processor.

> 
> Basically if you want GCC to generate code for a new target, you just write
> a formal definition of the instruction set for that architecture, called
> a machine configuration file, and everything else is automatic. Writing
> these configuration files is quite a straightforward task once you are
> familiar with the technical approach.

Almost. You have to write some C glue to transform some RTL instructions
that are not directly available in the target architecture (in my case,
I had to simulate indirect addressing). There was enough C involved to
make me wish it was Ada. In addition, when I left stuff out, or just got
it wrong, the only way I could figure out what was missing was reading
the gcc source. It is well commented, and usually well structured, but
it is not Ada 95.

-- 
- Stephe

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Stephe says

<<I guess I wasn't clear. I do understand that gcc meets my needs; in
fact, I am using it. I've ported the gcc backend to generate assembler
code for the UT69R000 microprocessor. What I meant by getting away from
K&R is that the gcc _source_ is _written_ in K&R style C; for example,
functions are often not declared before they are used (at least in the
user configuration files I was editing). This has bitten me several
times. I tried to include the headers that defined the functions that I
was using, but could not figure out an include order that worked; some
macro or other was always left undefined. I understand that this style
was necessary when gcc was started; K&R compilers were the only
compilers available. And it is precisely this style, together with a
liberal use of preprocessing, that makes gcc operate on so many hosts.>>

  The people who know and maintain this code can read it FAR more easily
  than they could read Ada code. Familiarity is worth a big factor more
  than objective language differences. Yes, if you are an Ada programmer,
  you will have a hard time reading the code, just as the GCC folk have
  a hard time reading the GNAT front end (even though most people consider
  this to be very clearly written code).

<<I understand that there is a _HUGE_ amount of work in truly replacing
the current gcc with an equivalent Ada 95 implementation. I am sure ACT
cannot afford that on its own; that is why I was surprised to hear that
the JVM implementation was not using gcc. Now I have an inkling of why;
the JVM is not similar to a typical processor.>>

  ACT would not think of embarking on such a counter-productive task. Hundreds
  of people contribute to the development, improvement, and maintenance of
  the existing gcc backend, and even if one did waste resources translating
  the backend of gcc into Ada 95, you would just create a dead end branch, 
  that almost no one would pay any attention to. I cannot imagine a less
  worth while expenditure of time.

<<Almost. You have to write some C glue to transform some RTL instructions
that are not directly available in the target architecture (in my case,
I had to simulate indirect addressing). There was enough C involved to
make me wish it was Ada. In addition, when I left stuff out, or just got
it wrong, the only way I could figure out what was missing was reading
the gcc source. It is well commented, and usually well structured, but
it is not Ada 95.>>

  Well no doubt Eiffel programmers would prefer it in Eiffel, Smalltalk 
  programmers would prefer it in Smalltalk, etc, but that is not a reason
  to do any of these translations.

It never makes sense to me to translate code in language A to language B just
for the sake of having the code in language B. Some very silly projects in the
past have done just that where language B was Ada, and it is one of the things
that have unfortunately convinced some people that Ada does not make sense if
it causes such activities to be undertaken.

By the way, if you do a bit of homework and learn JVM, you will see that
the task of generating JVM is not even remotely like the job of generating
machine language. JVM is much closer to Java in semantic level than it is
to machine language. People often think that it would make sense to somehow
have JVM as a target for GCC, but if they think that then they have serious
misconceptions about the GCC backend, or JVM, or both!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[W. Wesley Groleau x4923]

> It never makes sense to me to translate code in language A to language B just
> for the sake of having the code in language B. 

Define "just for the sake".  If you (one person or company) is going 
to have to _maintain_ code (i.e., actual changes anticipated) for 
some length of time, then a translation to a more maintainable format 
_may_ be justified.

> ....  People often think that it would make sense to somehow
> have JVM as a target for GCC, but if they think that then they 
> have serious misconceptions about the GCC backend, or JVM, or both!

As one of those people, I would like to say that, from experience
with the UCSD p-System (including reverse assembling the Z-80
interpreter when support was not available), and having read the
JVM specs, I do not have the misconceptions you speak of.  I just had
the motivation that IF it could be done, one would automatically
get byte-code from several languages instead of just from Ada.
Even a new code generator that used the gcc tree instead of the GNAT
tree would do this.  I recognize that this is a bigger job than
the job ACT is undertaking.  And it's certainly out of reach of my
available time and talent.  But it would still be a Good Thing.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Wes says

<<As one of those people, I would like to say that, from experience
with the UCSD p-System (including reverse assembling the Z-80
interpreter when support was not available), and having read the
JVM specs, I do not have the misconceptions you speak of.  I just had
the motivation that IF it could be done, one would automatically
get byte-code from several languages instead of just from Ada.
Even a new code generator that used the gcc tree instead of the GNAT
tree would do this.  I recognize that this is a bigger job than
the job ACT is undertaking.  And it's certainly out of reach of my
available time and talent.  But it would still be a Good Thing.>>

No, it would not be a good thing at all. The translation would be at
entirely the wrong level. It would not be possible to interface with
Java, and various Java tools would be useless, since the semantic
level of the JVM generated would be completely wrong. OK, you know
the JVM specs, but perhaps you do not have a clear idea of the semantic
level of a GCC backend, which is a very simple machine model with a
limited number of registers.

If you really think that what you propose is useful (I am quite sure it
is not), then it is pretty trivial to do. Just make a GCC backend that
generates idiotic Java code that simulates a simple machine, and then
compile the Java. So far, no one even thought that was worth doing for
C, let alone Java, because of the semantic mis-match problem, but this
is an easy summer project for some student, and would be quite fun and
instructive (but not useful).

Incidentally the idea that generating JVM from the backend of GCC is
a bigger task than what ACT is undertaking is COMPLETELY wrong. Generaing
a high level translation of Ada semantics to Java semantics is indeed
tricky, especially if you are committed to a validated full-language
system as we are (it is no surprise to us that the Intermetrics system
is not yet validated, we are quite aware of the diffficulties).

By contrast generating silly JVM output from the backend of GCC is by
contrast trivial, and probably no more than a few weeks work. The fact
that you think it is a bigger task must mean you have some major
misconceptions, I can't quite guess what.

Robert

Re: multi-language to JVM compilers?

[W. Wesley Groleau x4923]

> Java, and various Java tools would be useless, since the semantic
> level of the JVM generated would be completely wrong. OK, you know
> the JVM specs, but perhaps you do not have a clear idea of the 
> semantic level of a GCC backend, which is a very simple machine model 
> with a limited number of registers.

The JVM and p-code models were very simple in most respects and had 
a limited number of registers.  Where they got complex was in the
frame-handling/subprogram calling instructions where the object code
format/class format was entangled with the instructions that performed
a procedure call/class loading.  (as I recall....)

> By contrast generating silly JVM output from the backend of GCC is by
> contrast trivial, and probably no more than a few weeks work. The fact
> that you think it is a bigger task must mean you have some major
> misconceptions, I can't quite guess what.

The "fact that I think it is a bigger task" is more accurately the 
fact that other people have claimed it is a bigger task.  First,
there were Usenet posts that said starting from the AST was
more feasible (which I may have misinterpreted as meaning easier)
because the byte code was at a higher level that was more similar to
the semantic level of the tree.  Then there was S. Tucker Taft's
paper explaining how Ada features and Java features were so 
straightforwardly mapped onto each other.  

Now you say that a byte-code generating back-end is trivial but 
mapping to the intermediate form is difficult, and that I am 
confused to think otherwise.  I'm not accusing anyone of changing
his/her tune, but I certainly haven't changed mine!

I also do not agree with the apparent suggestion that we can make
object files derived from several different languages compatible
with each other and and with symbolic debuggers, but we can't make
JVM byte-code class files from more than one language "interface
with Java, and the various Java tools."

But my main point is that being able to generate Java classes
from several different languages _would_ be a Good Thing, whether
difficult or not.  That is not to say I fault anyone from doing
whatever he/she/they believes his/her/their customers want/need.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

translating to Ada, was Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Tom Moran]

>It never makes sense to me to translate code in language A to
>language B just for the sake of having the code in language B.
  Clearly, if the code in A works, and no maintenance is expected,
leaving it as a black box is appropriate.  In many cases though,
the translation process, especially from an unchecked to a highly
checked language, exposes significant bugs, plus the resulting code
is more maintainable.  In that situation it is eminently practical
and reasonable to translate.

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Tarjei T. Jensen]

>Stephen Leake wrote:
> 
>>>Robert Dewar wrote:
>>> The final GNAT-to-Java system, to be implemented entirely in Ada 95,
> 
> This sounds like you are NOT planning on adapting the backend of gcc to
> write JVM byte codes, but are instead implementing a new backend in Ada.
> This is cool! Will this backend be as data-driven as gcc? What I really
> want to know is; will I be able to adapt the new backend to my flight
> processor, and abandon gcc? gcc is great, but adapting it means writing
> K&R level C; I'd much rather be writing Ada95!
> 

If there is a new backend will it lend itself to writing code generators
for other architectures? Eight and sixteen bit microcontrollers would be
obvious challenges.

On the other hand; after having done some reading on the 8 bit
controllers, I'm not so sure that any programming language is
particularly suitable for these devices.

At any rate it looks like tasking would be no good. There is not much
context switching that can be done in 128 bytes or less.

However devices like the Z-80 (HD-180) and 68xx should be feasible.

Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Tarjei said

<<If there is a new backend will it lend itself to writing code generators
for other architectures? Eight and sixteen bit microcontrollers would be
obvious challenges.

On the other hand; after having done some reading on the 8 bit
controllers, I'm not so sure that any programming language is
particularly suitable for these devices.

At any rate it looks like tasking would be no good. There is not much
context switching that can be done in 128 bytes or less.

However devices like the Z-80 (HD-180) and 68xx should be feasible.>>

No, it will not be at all useful for this purpose, since it is entirely
JVM oriented. On the contrary, gcc itself can most certainly be adapated
for geenerating code on 8 and 16 bit micro-controllers, and indeed there
already exist gcc ports for some 16-bit micro-controllers.

So gcc as it stands is by FAR the more appropriate path if you want to
work on getting GNAT onto small machines. Whether this effort is worth
while for 128 byte machines, you have to figure out. Seems dubious to me!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Tarjei T. Jensen]

Robert Dewar wrote:
> 
>So gcc as it stands is by FAR the more appropriate path if you want to
>work on getting GNAT onto small machines. Whether this effort is worth
>while for 128 byte machines, you have to figure out. Seems dubious to me!

The biggest problem with using Ada for this purpose is that most people
(at least those who are vocal) seems to want a complete language
environment for any device.

This does not make sense for a microcontroller market. Microcontoller
seems to work best in polling mode with some interrupt work. In other
words; not the standard Ada way of doing things. The Ada language sans
floating point and tasking is still a powerful and useful language.

Tasking is probably cost effective for some purposes when one uses CPUs
like the 6502, Z80, HD180, 68xx, etc. Floating point with those CPUs are
questionable, but doable. There is a number of floating point libraries
available. Or at least was available when I dabbled in 8 bit assembly
programming on 6502 and Z80s.

For 8 bit work it would be possible to be able to define a generic 8 bit
instruction set (procedures) which can be translated to something
practical for an individual CPU. I'm not sure that efficienciy is
needed,

Greetings and congratulations to ACT,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

<<The biggest problem with using Ada for this purpose is that most people
(at least those who are vocal) seems to want a complete language
environment for any device.

This does not make sense for a microcontroller market. Microcontoller
seems to work best in polling mode with some interrupt work. In other
words; not the standard Ada way of doing things. The Ada language sans
floating point and tasking is still a powerful and useful language.>>

There is nothing to stop you doing a GNAT port with no tasking (it has been
done a number of times!)

There is nothing to stop you doing a gcc port with no floating-point!

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Marc Wachowitz]

Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> Can anyone recommend a _good_ intro to the JVM? I go to Borders, and
> have a hard time choosing from all the books promising to teach me Java
> in 10 days :).

I suggest using the books from Sun's Java Series, both for Java itself (i.e.
the language and basic libraries) and for the JVM. These two are available
as html documents from http://java.sun.com, too. For dark corners of the
specifications, JDK bugs etc., see http://www2.vo.lu/homepages/gmid/java.htm
as well as the documentation which comes with the JDK.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Marc Wachowitz]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:
> Slim binaries are based on two ideas:
>     - source code compresses very well
>     - IO is slow.

To be practical, it's also important that compile time is reasonably small
for acceptably good code; a compiler must not use too much resources, as it's
part of the system. Some slim-binary-systems do also use post-optimization
at run time (possibly adapting to the empirical system behaviour), after
having generated relatively simple and slow code on loading. It surely helps
that Oberon(-2), the language for which slim binaries have been developed,
is extremely simple and straight-forward to compile, and as integrated part
of the Oberon operating system or a browser, it tends to stay around between
different programs. I'm not sure whether the same concept would work well for
stand-alone programs in much more complicated (for the compiler) languages.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Robert Dewar]

Marc says

<<To be practical, it's also important that compile time is reasonably small
for acceptably good code; a compiler must not use too much resources, as it's
part of the system. Some slim-binary-systems do also use post-optimization
at run time (possibly adapting to the empirical system behaviour), after
having generated relatively simple and slow code on loading. It surely helps
that Oberon(-2), the language for which slim binaries have been developed,
is extremely simple and straight-forward to compile, and as integrated part
of the Oberon operating system or a browser, it tends to stay around between
different programs. I'm not sure whether the same concept would work well for
stand-alone programs in much more complicated (for the compiler) languages.>>

No language is "simple and straight-forward to compile" if you want
efficient code. Especially with modern processors with speculative
execution, and super-scalar super-pipelined implementations, the
optimization phases of the compiler are by far the most complex, and
take the most effort to write, and the most execution time to run,
and this is true even with todays large languages (Fortran-90, OO COBOL,
C++, Ada 95 etc).

If you don't want efficient code, then depending on the extent to which
you really mean what you say (as another thread points out, people don't
always know what they areally want), then it is of course much easier
to provide complete portability with very fast compilers. I don't see
any particular merit in the "slim binary" approach over distribution of
source code except for the case where the distributor of the software
is concerned with deliberate obfuscation of proprietary sources. This is
a definite issue for some people, but not really a technical one!