C to JVM, time to revive JGNAT?

C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

AMPC (Axiomatic Multi-Platform C):

http://www.axiomsol.com/

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: C to JVM, time to revive JGNAT?

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> AMPC (Axiomatic Multi-Platform C):
> 
> http://www.axiomsol.com/
> 
If you are interested in non-Java languages for the JVM, have a look at 
http://www.robert-tolksdorf.de/vmlanguages.html

That's really impressive...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: C to JVM, time to revive JGNAT?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> AMPC (Axiomatic Multi-Platform C):
> 
> http://www.axiomsol.com/
> 

I find the idea more than obvious. Zillions of mobile
computers and the like are driven by JVMs. Major web sites,
too.
Ada, as has been explained and also proven as early as 1996
by Tucker Taft and collegues, is a language well suited for
targeting the JVM.

I'm using an Ada->J-code compiler, and I must say that in spite
of some rough edges (it's not full Ada 95, older byte codes
just like JGNAT), it's fun, it's quick, and it works.
The Java-Ada integration is very smooth, quite unlike your
usual binding. Tons of libraries at your finger tips.

Is it that Ada programmers feel bad about virtual
machines? Do they feel more powerful when they can
pretend to themselves to be controlling "the metal"?


According to Robert Dewar at FOSDEM, GNAT is going the JNI
and/or "OO-ABI" path, which I interpret to also mean that
Redhat is funding GCC development for compiling the Java
language directly to machine code. GCC C++ ways can
be integrated with GCC Ada ways.

But how can Java, compiled to processor instructions, be
so helpful where the OS is really a specialized JVM?

Sometimes research going into Real Time Java, Java memory
management, object lifetime etc, is really reapeating Ada
stories, AFAICT from my limited view.
What if the two efforts can be readily integrated, taking
advantage of Ada features, JVM libraries, portability,
etc etc?


 --  Georg 

Re: C to JVM, time to revive JGNAT?

[Colin Paul Gloster]

On Wed, 9 Aug 2006, Dmitry A. Kazakov wrote:

"AMPC (Axiomatic Multi-Platform C):

http://www.axiomsol.com/
"

From the homepage of Axiomatic Solutions:

"If you write Java code, you can write once and run anywhere!"

and

"I write C code, and with AMPC I can write once and run anywhere!"

and

"The best and easiest way to convert C programs to standard Java 
bytecodes (classes) is AMPC from Axiomatic Solutions"

yet AMPC is released only as versions depending on a specific platform, so 
will not even run on all Java platforms. If platform independence is not 
good enough to distribute AMPC, why is it good enough for AMPC's users?

Also, from WWW.AxiomSol.com/pro_serv/compiler.php :

"[..]

AMPC allows users to develop software using the standard C programming 
language [..]

[..]

AMPC covers a very large subset of ANSI C (1989). A notable difference is 
that "double" in AMPC is 32 bits long. In order to utilize 64-bit 
floating point you can use "DOUBLE".

[..]"

So though AMPC is described as standard in one part of the documentation, 
it is not standard and someone's interpretation of what the C standard
even is seems to be amiss.

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 09.08.2006, 13:59 Uhr, schrieb Colin Paul Gloster  
<Colin_Paul_Gloster@ACM.org>:

> So though AMPC is described as standard in one part of the documentation,
> it is not standard and someone's interpretation of what the C standard
> even is seems to be amiss.

Nothing new here. C compiler are notorious for not complying with the  
standard. Microsoft would not even implement a keyword when the minimum  
support needed by the standart is "no-op" (restricted).

Martin
-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Maciej Sobczak]

Martin Krischik wrote:

> C compiler are notorious for not complying with the 
> standard. Microsoft would not even implement a keyword when the minimum 
> support needed by the standart is "no-op" (restricted).

restricted is part of C99.
Does Microsoft claim that their compiler is C99?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 10.08.2006, 10:18 Uhr, schrieb Maciej Sobczak <no.spam@no.spam.com>:

> Martin Krischik wrote:
>
>> C compiler are notorious for not complying with the standard. Microsoft  
>> would not even implement a keyword when the minimum support needed by  
>> the standart is "no-op" (restricted).
>
> restricted is part of C99.
> Does Microsoft claim that their compiler is C99?

Of corse not! They don't bother - like most C verndors. And that is the  
dissapointing part. They don't even try to follow the standart. One more  
reason to love Ada.

Martin
-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Björn Persson]

Colin Paul Gloster wrote:
> From the homepage of Axiomatic Solutions:
> 
> "If you write Java code, you can write once and run anywhere!"

And if you write standard Ada code you can also write once and run 
anywhere. (At least anywhere in the USA.) Sure you need to compile for 
each platform, but that's no big problem as long as the same source code 
works on all platforms.

"Write once, run anywhere" is new only if Java replaces C or Visual 
Basic or some other vendor-specific language. I think that may be one 
reason why the market for Ada to JVM compilers is so small.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: C to JVM, time to revive JGNAT?

[Georg Bauhaus]

On Wed, 2006-08-09 at 22:39 +0000, Björn Persson wrote:


> "Write once, run anywhere" is new only if Java replaces C or Visual 
> Basic or some other vendor-specific language. I think that may be one 
> reason why the market for Ada to JVM compilers is so small.

I wonder what programs you have in mind. Certainly C and Ada
are both not the language of choice for smart phone user
programs?

What kind of Java style programs can you write with just LRM Ada?

What kind of Java style programs can you write with LRM Ada +
the J2EE collection of classes? Can you do that with any of the
Ada offerings (I don't know).


-- Georg 

Re: C to JVM, time to revive JGNAT?

[Björn Persson]

Georg Bauhaus wrote:
> I wonder what programs you have in mind. Certainly C and Ada
> are both not the language of choice for smart phone user
> programs?

Are you trying to demonstrate that Java runs on more platforms than Ada? 
Otherwise I don't understand what you're after.

> What kind of Java style programs can you write with just LRM Ada?

What do you mean with "Java style"?

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: C to JVM, time to revive JGNAT?

[Georg Bauhaus]

Björn Persson wrote:
> Georg Bauhaus wrote:
>> I wonder what programs you have in mind. Certainly C and Ada
>> are both not the language of choice for smart phone user
>> programs?
> 
> Are you trying to demonstrate that Java runs on more platforms than Ada? 
> Otherwise I don't understand what you're after.

I'm not after the number of platforms. There aren't that
many JVMs.
I'm after the programs that I can write by combining the powers
of Ada and everything readily available with a JVM target. 


>> What kind of Java style programs can you write with just LRM Ada?
> 
> What do you mean with "Java style"?

I mean the kind of programs I had hoped to imply by
mentioning smart phones, that is, mass products,
perhaps GPS receivers etc..
And for example enterprise services software.
The JVM is an industry standard in some industries.
The cross language inheritance of "Ada classes" and
"Java classes" is spectacularly transparent.

Translators for some other language also produce J-code,
but they just ignore the OO-module property of .class
files (note the word "class"). They use wrappers and
produce classes at random that cannot be used by other
programs.  Even though the source language is an OO
language.

What good is it neglecting the standards of some industries
by saying, mine could better, when in fact it is really time
consuming if at all possible to knit together similar
solutions?  And when you could just hook into this part
of software production by having your Ada compiler produce
class files?  (Is anyone questioning the MGNAT effort btw?
It's almost the same thing, even when Microsoft's VM has
a number of additional facilities when compared to Sun's
older VM.)

I also mean the programs written in Java now that use all kinds of
Java language restrictions and annotations. Some of these
"Java enhancements" might be plain unnecessary when Ada is the
source language for the JVM platform. Ada might already
have the needed features.

As another example, writing an Eclipse plugin using Ada is
probably easier when the compiler produces .class files
that are of the kind expected in a Java environment.

Re: C to JVM, time to revive JGNAT?

[Maciej Sobczak]

Bj�rn Persson wrote:

>> "If you write Java code, you can write once and run anywhere!"
> 
> And if you write standard Ada code you can also write once and run 
> anywhere.

Which is true also about standard C:

#include <stdio.h>
int main()
{
     puts("Hello");
     return 0;
}

I think you can write it once and run anywhere.
The problems appear when you start calling system-specific routines or 
external non-standard libraries - which is the case for Ada as well.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: C to JVM, time to revive JGNAT?

[Simon Wright]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Which is true also about standard C:
>
> #include <stdio.h>
> int main()
> {
>     puts("Hello");
>     return 0;
> }
> I think you can write it once and run anywhere.

Almost anywhere. Pretty sure this won't work on VxWorks (5.5)!

Re: C to JVM, time to revive JGNAT?

[Björn Persson]

Maciej Sobczak wrote:
> Bj�rn Persson wrote:
>> And if you write standard Ada code you can also write once and run 
>> anywhere.
> 
> Which is true also about standard C:
> 
> #include <stdio.h>
> int main()
> {
>     puts("Hello");
>     return 0;
> }

Is that the most interesting program you can write in standard C? ;-)

As a quick example of a non-portable aspect of standard C, let's say I 
need to represent natural numbers from 1 to 1000000. Which data type 
should I use to ensure that the program will be portable to all 
platforms that can handle these numbers? In C 99 there is *finally* a 
set of portable integer types. Can I count on those being available in 
all compilers?

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 11.08.2006, 00:55 Uhr, schrieb Björn Persson <spam-away@nowhere.nil>:

> Maciej Sobczak wrote:
>> Björn Persson wrote:
>>> And if you write standard Ada code you can also write once and run  
>>> anywhere.
>>  Which is true also about standard C:
>>  #include <stdio.h>
>> int main()
>> {
>>     puts("Hello");
>>     return 0;
>> }
>
> Is that the most interesting program you can write in standard C? ;-)
>
> As a quick example of a non-portable aspect of standard C, let's say I  
> need to represent natural numbers from 1 to 1000000. Which data type  
> should I use to ensure that the program will be portable to all  
> platforms that can handle these numbers? In C 99 there is *finally* a  
> set of portable integer types. Can I count on those being available in  
> all compilers?

No. It took me just a quarter of an hour to create a stdtype.h for MSC yet  
Microsoft programmers se no need to create one. Ok the MS programmers  
can't just copy the version from GCC but I don't think writing from  
scratch would take more then an hour. Still no avail.

Martin

-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Maciej Sobczak]

Bj�rn Persson wrote:

>> Which is true also about standard C:
>>
>> #include <stdio.h>
>> int main()
>> {
>>     puts("Hello");
>>     return 0;
>> }
> 
> Is that the most interesting program you can write in standard C? ;-)

No, but the biggest challenge in portability is the relatively small 
(when compared to, say, Java) standard library.
For example, write a web browser in Ada (net+gui+crypto+...) and let me 
know how much portable it is.

> As a quick example of a non-portable aspect of standard C, let's say I 
> need to represent natural numbers from 1 to 1000000.

Then you use long and you're done. The standard says so.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

On Fri, 11 Aug 2006 10:04:11 +0200, Maciej Sobczak wrote:

> No, but the biggest challenge in portability is the relatively small 
> (when compared to, say, Java) standard library.
> For example, write a web browser in Ada (net+gui+crypto+...) and let me 
> know how much portable it is.

It is a difficult question. You cannot pack everything into libraries for
obvious reasons. I can imagine a system without GUI, but it is difficult to
do for numeric things. Then, when you say NET, I'd ask which one? Can I
have field buses, multicast protocols, time-triggered protocols in Java?
The next question about non-functional requirements. What can be said about
rendering performance of that portable browser, how many numeric operations
will be required for encrypting 1MB, etc?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: C to JVM, time to revive JGNAT?

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

>> No, but the biggest challenge in portability is the relatively small 
>> (when compared to, say, Java) standard library.
>> For example, write a web browser in Ada (net+gui+crypto+...) and let me 
>> know how much portable it is.
> 
> It is a difficult question. You cannot pack everything into libraries for
> obvious reasons. I can imagine a system without GUI, but it is difficult to
> do for numeric things. Then, when you say NET, I'd ask which one? Can I
> have field buses, multicast protocols, time-triggered protocols in Java?
> The next question about non-functional requirements. What can be said about
> rendering performance of that portable browser, how many numeric operations
> will be required for encrypting 1MB, etc?

These are all valid point, but the logic is fuzzy anyway.
For example, C, C++ and Ada support the concept of std{in|out|err} 
channels and their standard libraries contain appropriate stuff for 
this. But if we think about it, there are many platforms where the 
standard IO channels do not exist at all (most embedded boxes, I guess, 
and even "some" GUI environments as well), but the support for stdio is 
in the standard anyway. What's even more intersting is that there are 
probably more environments which support TCP/IP than those which support 
stdio (think "embedded boxes") - still, it's stdio which gets attention 
of standard committees, not TCP/IP.

There are obviously many factors that shaped this, but the final result 
is that most interesting applications are not portable. Java may not 
have standard support for field buses or time-triggered protocols, but 
neither has C, C++ nor Ada. The point is not in what nobody has, but in 
what they do have - with increased portability of final software - and 
we don't.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

On Mon, 14 Aug 2006 09:09:24 +0200, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>>> No, but the biggest challenge in portability is the relatively small 
>>> (when compared to, say, Java) standard library.
>>> For example, write a web browser in Ada (net+gui+crypto+...) and let me 
>>> know how much portable it is.
>> 
>> It is a difficult question. You cannot pack everything into libraries for
>> obvious reasons. I can imagine a system without GUI, but it is difficult to
>> do for numeric things. Then, when you say NET, I'd ask which one? Can I
>> have field buses, multicast protocols, time-triggered protocols in Java?
>> The next question about non-functional requirements. What can be said about
>> rendering performance of that portable browser, how many numeric operations
>> will be required for encrypting 1MB, etc?
> 
> These are all valid point, but the logic is fuzzy anyway.
> For example, C, C++ and Ada support the concept of std{in|out|err} 
> channels and their standard libraries contain appropriate stuff for 
> this. But if we think about it, there are many platforms where the 
> standard IO channels do not exist at all (most embedded boxes, I guess, 
> and even "some" GUI environments as well), but the support for stdio is 
> in the standard anyway. What's even more intersting is that there are 
> probably more environments which support TCP/IP than those which support 
> stdio (think "embedded boxes") - still, it's stdio which gets attention 
> of standard committees, not TCP/IP.

Yes, in XXI century TCP/IP is much more important than Text_IO.

> There are obviously many factors that shaped this, but the final result 
> is that most interesting applications are not portable.

Yes. Because the platform is quite often a sufficient part of interest.

> Java may not 
> have standard support for field buses or time-triggered protocols, but 
> neither has C, C++ nor Ada. The point is not in what nobody has, but in 
> what they do have - with increased portability of final software - and 
> we don't.

I agree, but it is rather a problem of Ada's image. I doubt that Java is
more portable in strict sense [=man years required to fulfill the
requirements on some new platform], but it definitely *appears* more
portable. Which, as experience shows, is far more important than whether it
really is.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: C to JVM, time to revive JGNAT?

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

> I agree, but it is rather a problem of Ada's image.

You meant - Ada'Image? ;-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

On Mon, 14 Aug 2006 11:33:23 +0200, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>> I agree, but it is rather a problem of Ada's image.
> 
> You meant - Ada'Image? ;-)

Ada is a package. Packages don't have 'Image attribute. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: C to JVM, time to revive JGNAT?

[Dave Thompson]

On Thu, 10 Aug 2006 21:55:26 GMT, Bj�rn Persson
<spam-away@nowhere.nil> wrote:

> As a quick example of a non-portable aspect of standard C, let's say I 
> need to represent natural numbers from 1 to 1000000. Which data type 
> should I use to ensure that the program will be portable to all 
> platforms that can handle these numbers? In C 99 there is *finally* a 

unsigned long. Guaranteed since C89 to be _at least_ 32 bits hence 0
to 4G-1. (It may be more.) As usual for C, doesn't check that your
values are in the given (or any other) subrange. The harder question
is for anything over unsigned 4G or signed 2G.

> set of portable integer types. Can I count on those being available in 
> all compilers?

[u]int_{least,fast}{8,16,32,64}_t must be present in any conforming
C99 implementation. Of which there are not many currently. Although
it's easy enough to patch any C89 implementation that has some 64-bit
(at least) integers, which most do, and your standard code works.

[u]int{8,16,32,64}_t must be present _if_ the implementation has (2sC)
integer types of the given exact sizes, as practically all machines do
nowadays. However, on an oddball machine with S&M or 18-bit word or
32-bit word and no halfword instructions, they can be left out. You
can portably _detect_ this by #ifdef INT64_MAX etc.

Other N's are up to the implementation, and probably quite rare.

- David.Thompson1 at worldnet.att.net

Re: C to JVM, time to revive JGNAT?

[napi]

Hi:

Colin Paul Gloster wrote:
> On Wed, 9 Aug 2006, Dmitry A. Kazakov wrote:
>
> "AMPC (Axiomatic Multi-Platform C):
>
> http://www.axiomsol.com/
> "
>
> From the homepage of Axiomatic Solutions:
>
> "If you write Java code, you can write once and run anywhere!"
>
> and
>
> "I write C code, and with AMPC I can write once and run anywhere!"
>
> and
>
> "The best and easiest way to convert C programs to standard Java
> bytecodes (classes) is AMPC from Axiomatic Solutions"
>
> yet AMPC is released only as versions depending on a specific platform, so
> will not even run on all Java platforms. If platform independence is not
> good enough to distribute AMPC, why is it good enough for AMPC's users?

The compiler/IDE itself comes in three versions (Linux, Mac OSX, and MS
Windows), but the generated code (.class files) should be able to run
on any properly installed JVM/JRE.  In other words, AMPC is a
cross-compiler suite whose development platforms are Linux, Mac OSX,
and MS Windows, all targeting the platform-independent JVM.

> Also, from WWW.AxiomSol.com/pro_serv/compiler.php :
>
> "[..]
>
> AMPC allows users to develop software using the standard C programming
> language [..]
>
> [..]
>
> AMPC covers a very large subset of ANSI C (1989). A notable difference is
> that "double" in AMPC is 32 bits long. In order to utilize 64-bit
> floating point you can use "DOUBLE".
>
> [..]"
>
> So though AMPC is described as standard in one part of the documentation,
> it is not standard and someone's interpretation of what the C standard
> even is seems to be amiss.

The ANSI C standard does not specify the size of scalar variables since
there are various CPU architectures out there from 8 bits to 64 bits,
etc.  So, making "double" to be 32 bits or even 16 bits is still
conformant to the ANSI C standard, although abnormal.  AMPC actually
supports 64 bit floating point by means of the type DOUBLE.

Regards.

Napi

Re: C to JVM, time to revive JGNAT?

[Colin Paul Gloster]

On Thu, 9 Aug 2006 Napi wrote:

"Colin Paul Gloster wrote:
[..]
> yet AMPC is released only as versions depending on a specific platform, so
> will not even run on all Java platforms. If platform independence is not
> good enough to distribute AMPC, why is it good enough for AMPC's users?

The compiler/IDE itself comes in three versions (Linux, Mac OSX, and MS
Windows), but the generated code (.class files) should be able to run
on any properly installed JVM/JRE.  In other words, AMPC is a
cross-compiler suite whose development platforms are Linux, Mac OSX,
and MS Windows, all targeting the platform-independent JVM."

Hello,

I had understood that.

"> Also, from WWW.AxiomSol.com/pro_serv/compiler.php :
>
> "[..]
>
> AMPC allows users to develop software using the standard C programming
> language [..]
>
> [..]
>
> AMPC covers a very large subset of ANSI C (1989). A notable difference is
> that "double" in AMPC is 32 bits long. In order to utilize 64-bit
> floating point you can use "DOUBLE".
>
> [..]"
>
> So though AMPC is described as standard in one part of the documentation,
> it is not standard and someone's interpretation of what the C standard
> even is seems to be amiss.

The ANSI C standard [..]"

ANSI C is not from 1989 as ANSI has a policy of replacing a standard 
after approximately ten years. ANSI C is dated 1999.

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 10.08.2006, 13:43 Uhr, schrieb Colin Paul Gloster  
<Colin_Paul_Gloster@ACM.org>:

> The ANSI C standard [..]"
> ANSI C is not from 1989 as ANSI has a policy of replacing a standard
> after approximately ten years. ANSI C is dated 1999.

You must have noticed my compiler vendor ranting. To my knowlege there is  
only one C compiler which fullfills C99 [1] and one which tries [2]. All  
other C compiler verndors either ignore c99 completely or produce  
vaporware only.

Sincewe have 2006 now I begin to think that C99 is effectivly dead. For  
those who can reead german:

http://www.schellong.de/better_c99.htm

Martin

[1] http://www.comeaucomputing.com/features.html#c99
[2] http://gcc.gnu.org/c99status.html

-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Dave Thompson]

On 9 Aug 2006 19:53:32 -0700, napi@axiomsol.com wrote:

> Hi:
> 
> Colin Paul Gloster wrote:

> > AMPC covers a very large subset of ANSI C (1989). A notable difference is
> > that "double" in AMPC is 32 bits long. In order to utilize 64-bit
> > floating point you can use "DOUBLE".
> >
> > [..]"
> >
> > So though AMPC is described as standard in one part of the documentation,
> > it is not standard and someone's interpretation of what the C standard
> > even is seems to be amiss.
> 
> The ANSI C standard does not specify the size of scalar variables since
> there are various CPU architectures out there from 8 bits to 64 bits,

Doesn't specify size, except that all objects (other than bitfields in
structs) are an integral number of bytes (where byte is the smallest
addressing unit supported by the C implementation, possibly larger
than the actual machine byte in rare cases) and all flavors of char
types are exactly one byte (ditto).

But DOES specify required minimum range and for floating point
precision, which imply requirements on representation.

> etc.  So, making "double" to be 32 bits or even 16 bits is still
> conformant to the ANSI C standard, although abnormal.  AMPC actually
> supports 64 bit floating point by means of the type DOUBLE.
> 
With base 2 as is now essentially universal it isn't possible to meet
the requirements for 'float' with with less than 1+14 'mantissa' bits
and 8 exponent bits = 23, and 'double' (and 'long double') with less
than 1+30+8 = 39. Even with base 256 (and variation in precision much
worse than S/360's base 16) you need 5 exponent bits = 20 and 36.
(Yes, mathematically this isn't the correct meaning of 'mantissa' but
that's now the common usage.)

Re the other reply:
ANSI does not require standards to be replaced after 10 years, only to
be reviewed for _possible_ revision. Looking through their catalog, I
have noted standards 15 or 20 or more years old still 'reaffirmed'.
Actually since 1990 their C standard has just been an adoption of the
ISO (actually JTC1) standard, which was indeed revised late in 1999,
although due to procedural delays the ANSI date on it is May 2000.

- David.Thompson1 at worldnet.att.net

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 09.08.2006, 11:11 Uhr, schrieb Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de>:

> AMPC (Axiomatic Multi-Platform C):
>
> http://www.axiomsol.com/

I think JGNAT, MGNAT and Interfaces.CPP are interesting technologies but  
somehow undermaintained.

While MGNAT seem to come along nicely both JGNAT and Interfaces.CPP are  
stalled on a misseing code analyzer/generator for the needed thin  
bindings. It is just to much work to create them by hand.

And a last point: the gcj (GNU Compiler for Java) is coming along nicely  
as well Interfaces.Java (interface to gcj) might be an alternative to  
JGNAT.

Sadly we don't have the man power for any of theese projects. Apart from  
MGNAT which is sponsored by teh US Air force.

Martin
-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

On Wed, 09 Aug 2006 19:01:27 +0300, Martin Krischik wrote:

> I think JGNAT, MGNAT and Interfaces.CPP are interesting technologies but  
> somehow undermaintained.
> 
> While MGNAT seem to come along nicely both JGNAT and Interfaces.CPP are  
> stalled on a misseing code analyzer/generator for the needed thin  
> bindings. It is just to much work to create them by hand.
> 
> And a last point: the gcj (GNU Compiler for Java) is coming along nicely  
> as well Interfaces.Java (interface to gcj) might be an alternative to  
> JGNAT.

Well, that wouldn't give us JVM target, or? Having a naked Ada compiler
into anything isn't much useful. Ada's run-time library is the thing that
makes it useful.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 09.08.2006, 21:13 Uhr, schrieb Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de>:

> On Wed, 09 Aug 2006 19:01:27 +0300, Martin Krischik wrote:
>
>> I think JGNAT, MGNAT and Interfaces.CPP are interesting technologies but
>> somehow undermaintained.
>>
>> While MGNAT seem to come along nicely both JGNAT and Interfaces.CPP are
>> stalled on a misseing code analyzer/generator for the needed thin
>> bindings. It is just to much work to create them by hand.
>>
>> And a last point: the gcj (GNU Compiler for Java) is coming along nicely
>> as well Interfaces.Java (interface to gcj) might be an alternative to
>> JGNAT.
>
> Well, that wouldn't give us JVM target, or?

gcj is dual target - binary and jvm.

> Having a naked Ada compiler
> into anything isn't much useful. Ada's run-time library is the thing that
> makes it useful.

Let's be honest here: the Java's runtime lib is a lot more powerfull then  
Ada's.

Martin
-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

On Thu, 10 Aug 2006 13:11:02 +0300, Martin Krischik wrote:

> Am 09.08.2006, 21:13 Uhr, schrieb Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de>:

>> Having a naked Ada compiler
>> into anything isn't much useful. Ada's run-time library is the thing that
>> makes it useful.
> 
> Let's be honest here: the Java's runtime lib is a lot more powerfull then  
> Ada's.

I didn't mean GUI stuff or other things you can express in the language
terms. I did ones you need to make, say, protected objects working.

For example, there is a GCC backend for Tricore. Does it imply that GNAT
can Tricore?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: C to JVM, time to revive JGNAT?

[Martin Krischik]

Am 10.08.2006, 16:26 Uhr, schrieb Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de>:

> On Thu, 10 Aug 2006 13:11:02 +0300, Martin Krischik wrote:
>
>> Am 09.08.2006, 21:13 Uhr, schrieb Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de>:
>
>>> Having a naked Ada compiler
>>> into anything isn't much useful. Ada's run-time library is the thing  
>>> that
>>> makes it useful.
>>
>> Let's be honest here: the Java's runtime lib is a lot more powerfull  
>> then
>> Ada's.
>
> I didn't mean GUI stuff or other things you can express in the language
> terms. I did ones you need to make, say, protected objects working.

Shure, yes, you want it both: all the Ada stuff and all the Java stuff.  
Which indeed would be cool. I too would love that.

> For example, there is a GCC backend for Tricore. Does it imply that GNAT
> can Tricore?

Tricore?!? I wikipedia it when I am home - my parents in law internet  
connection is so slooow - yawnnn.

Martin

-- 
Martin Krischik
krischik@users.sourceforge.net

Re: C to JVM, time to revive JGNAT?

[Dmitry A. Kazakov]

On Thu, 10 Aug 2006 20:07:19 +0300, Martin Krischik wrote:

>> For example, there is a GCC backend for Tricore. Does it imply that GNAT
>> can Tricore?
> 
> Tricore?!? I wikipedia it when I am home - my parents in law internet  
> connection is so slooow - yawnnn.

It is just a processor's name, the name is no matter, take Siemens C166
instead.

(I believe Green Hills has Ada for Tricore, though I am not sure)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de