Ada version of C's 'static'

Ada version of C's 'static'

[Craig Allen]

I've written some code in a procedure that operates on a table of
constants.  The table is used only by that procedure.  Right now, I have
that table defined locally to that procedure.  I believe the table is
regenerated every time the procedure is called.

In C, I'd declare this table static in that function.  This would give
me static duration and block scope for that function.

I don't want to define this table at 'package scope', as only 1
procedure uses this table (and the values would be removed from the
code that uses them).  I would prefer not to build the table at
elaboration time, because I'd like the definition to be close to the
code that's using it, not at the bottom of the package.

In short, this is exactly what I want, except in Ada.

void foo(void)
{
   static const int bar[] = {1, 2, 3, 4, 5};
   ...
}

Or is there a 'more Ada' way of doing this?

Thanks for any help.
-Craig




Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada version of C's 'static'

[David Botton]

See on AdaPower.com :

Static Variables in Ada (Lundquist)
http://www.adapower.com/lang/static.html

David Botton


Craig Allen wrote in message <7n03us$862$1@nnrp1.deja.com>...
>I've written some code in a procedure that operates on a table of
>In short, this is exactly what I want, except in Ada.
>
>void foo(void)
>{
>   static const int bar[] = {1, 2, 3, 4, 5};
>   ...
>}
>
>Or is there a 'more Ada' way of doing this?

Re: Ada version of C's 'static'

[Simon Wright]

Craig Allen <cpallen@my-deja.com> writes:

> I've written some code in a procedure that operates on a table of
> constants.  The table is used only by that procedure.  Right now, I have
> that table defined locally to that procedure.  I believe the table is
> regenerated every time the procedure is called.
> 
> In C, I'd declare this table static in that function.  This would give
> me static duration and block scope for that function.
> 
> I don't want to define this table at 'package scope', as only 1
> procedure uses this table (and the values would be removed from the
> code that uses them).  I would prefer not to build the table at
> elaboration time, because I'd like the definition to be close to the
> code that's using it, not at the bottom of the package.
> 
> In short, this is exactly what I want, except in Ada.
> 
> void foo(void)
> {
>    static const int bar[] = {1, 2, 3, 4, 5};
>    ...
> }
> 
> Or is there a 'more Ada' way of doing this?

You can do pretty much exactly that in Ada. I've made it into a
function and filled in the content so that optimisation won't remove
the entire contents ..

  function Foo (Input : Integer) return Integer is
    type Integer_Array is array (Natural range <>) of Integer;
    Bar : constant Integer_Array := (1, 2, 3, 4, 5);
  begin
    if Input in Bar'Range then
      return Bar (Input);
    else
      return -1;
    end if;
  end Foo;

cf

  int foo(int input)
  {
     static const int bar[] = {1, 2, 3, 4, 5};
     if (input >= 0 && input < sizeof(bar) / sizeof(bar[0]))
       return bar[input];
     else
       return -1;
  }

Using gcc -O3 -S gives (Ada on the left, C on the right)
[i486-pc-linux-gnulibc1, gnat 3.11p, gcc 2.8.1]

	.file	"foo.adb"                         .file   "foo.c"             
	.version	"01.01"		          .version        "01.01"     
gcc2_compiled.:				  gcc2_compiled.:                     
.section	.rodata			  .section        .rodata             
	.align 4			          .align 4                    
	.type	 bar.0,@object		          .type    bar.2,@object      
	.size	 bar.0,20		  bar.2:                              
bar.0:					          .long 1                     
	.long 1				          .long 2                     
	.long 2				          .long 3                     
	.long 3				          .long 4                     
	.long 4				          .long 5                     
	.long 5				  .text                               
.text					          .align 16                   
	.align 16			  .globl foo                          
.globl _ada_foo				          .type    foo,@function      
	.type	 _ada_foo,@function	  foo:                                
_ada_foo:				          pushl %ebp                  
	pushl %ebp			          movl %esp,%ebp              
	movl %esp,%ebp			          movl 8(%ebp),%eax           
	movl 8(%ebp),%eax		          cmpl $4,%eax                
	cmpl $4,%eax			          jbe .L2                     
	ja .L2				          movl $-1,%eax               
	movl bar.0(,%eax,4),%eax	          jmp .L4                     
	jmp .L6				          .align 16                   
	.align 16			  .L2:                                
.L2:					          movl bar.2(,%eax,4),%eax    
	movl $-1,%eax			  .L4:                                
.L6:					          movl %ebp,%esp              
	movl %ebp,%esp			          popl %ebp                   
	popl %ebp			          ret                         
	ret				  .Lfe1:                              
.Lfe1:					          .size    foo,.Lfe1-foo      
	.size	 _ada_foo,.Lfe1-_ada_foo          .ident  "GCC: (GNU) 2.8.1"  
	.ident	"GCC: (GNU) 2.8.1"

which is pretty close!

-Simon

Re: Ada version of C's 'static'

[Tucker Taft]

Craig Allen wrote:
> 
> I've written some code in a procedure that operates on a table of
> constants.  The table is used only by that procedure.  Right now, I have
> that table defined locally to that procedure.  I believe the table is
> regenerated every time the procedure is called.

Why do you believe it is regenerated?  It shouldn't be if the
table is of compile-time known size with compile-time known values.

> In C, I'd declare this table static in that function.  This would give
> me static duration and block scope for that function.
> 
> I don't want to define this table at 'package scope', as only 1
> procedure uses this table (and the values would be removed from the
> code that uses them).  I would prefer not to build the table at
> elaboration time, because I'd like the definition to be close to the
> code that's using it, not at the bottom of the package.
> 
> In short, this is exactly what I want, except in Ada.
> 
> void foo(void)
> {
>    static const int bar[] = {1, 2, 3, 4, 5};
>    ...
> }
> 
> Or is there a 'more Ada' way of doing this?

If the values are known at compile-time, then any Ada compiler
worth its salt will allocate and initialize the table statically,
no matter where it is declared.  If the compiler is not worth
its salt, then you probably have bigger problems anyway, so I wouldn't
worry about that contingency.  Either that, or complain to/threaten
your compiler vendor ;-).

If the values are *not* known at compile-time, then C wouldn't
allow it to be static anyway (though C++ would, and boy is the
initialization "funky" in that case).

> Thanks for any help.
> -Craig
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada version of C's 'static'

[Craig Allen]

In article <3798EDE9.90B9623B@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Craig Allen wrote:
> >
> > I've written some code in a procedure that operates on a table of
> > constants.  The table is used only by that procedure.  Right now, I
have
> > that table defined locally to that procedure.  I believe the table
is
> > regenerated every time the procedure is called.
>
> Why do you believe it is regenerated?  It shouldn't be if the
> table is of compile-time known size with compile-time known values.
>

I was worried about this and I looked at the assembly created by the
compiler.  I believe that upon entry to the function, the table was
regenerated every time even after making sure the data was constant.
After implementing the inner package suggestion (thanks Dave) I again
looked at the assembly output and this time it looked as if the table
was not being generated upon entry.


> If the values are known at compile-time, then any Ada compiler
> worth its salt will allocate and initialize the table statically,
> no matter where it is declared.  If the compiler is not worth
> its salt, then you probably have bigger problems anyway, so I wouldn't
> worry about that contingency.  Either that, or complain to/threaten
> your compiler vendor ;-).

I couldn't run my water softener off this compiler.  Seriously, I'm
using a VAX hosted Tartan 83 Ada compiler and do not enjoy it.  Learning
Ada is not easy when you must also question the compiler (cases of
experienced people saying 'oh, we've had problems with that with the
compiler, and so we just avoid doing it.')

-Craig



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Erdelyi Gaspar]

In article <7nsuf3$tm9$1@nnrp1.deja.com>, Craig Allen <cpallen@my-deja.com> writes:
> I couldn't run my water softener off this compiler.  Seriously, I'm
> using a VAX hosted Tartan 83 Ada compiler and do not enjoy it.  Learning
> Ada is not easy when you must also question the compiler (cases of
> experienced people saying 'oh, we've had problems with that with the
> compiler, and so we just avoid doing it.')
> 
I learnt Ada here at the university on UNIXes with gnat compiler and
VAX/VMS with DEC ADA 83 compiler. I've tried Aonix compilers (95&NT,
Sparc/Solaris). I enjoyed the DEC ADA compiler, and it's my favourite.
(ADA license is needed)
We had only one problem: as I know, DEC Ada95 is available only for AXP/VMS.

> -Craig

Regards,

Gaspar 
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Larry Kilgallen]

In article <1999Aug3.155033.62042@ludens>, gazso@ludens.elte.hu (Erdelyi Gaspar) writes:

> I learnt Ada here at the university on UNIXes with gnat compiler and
> VAX/VMS with DEC ADA 83 compiler. I've tried Aonix compilers (95&NT,
> Sparc/Solaris). I enjoyed the DEC ADA compiler, and it's my favourite.
> (ADA license is needed)

Your university should have been able to get a particularly good price
for that DEC Ada license, but home hobbyists can now get it for free.

> We had only one problem: as I know, DEC Ada95 is available only for AXP/VMS.

But no version of DEC Ada provides Ada95.  GNAT provides Ada95, but not
on VAX.  Since they aimed it particularly at those who had been using
DEC Ada, they support the same set of pragmas for accessing VMS features.

Larry Kilgallen

Re: Compilers for VAX Was: Ada version of C's 'static'

[Larry Kilgallen]

In article <37A7EEF4.160F1A55@praxis-cs.co.uk>, Rod Chapman <rod@praxis-cs.co.uk> writes:
>> 
>> I do not know of any validated Ada 95 compilers for the VAX
> 
> Anyone know how difficult it would be to construct a GNAT
> targetting VAX/VMS?  Has anyone ever tried such a port?

Robert in the past has said the issue was not difficulty but demand.
DEC funded the Alpha port, and that certainly constituted demand on
the Alpha side.

> Oddly, we'd really like such a thing, so we could move our
> source base away from Ada83, while still supporting
> our VAX/VMS customers...

In a similar position, I am less attracted to that path because a
straightforward GNAT port would only work on the more recent versions
of VMS where DECthreads are more mature.  There are a lot of VAX sites
at V5.5-2, in situations where stability is more important than new
features.  Be sure to characterize your customer base according to the
version of VMS they run on VAX.

Sticking with DEC Ada (83) allows operation back as far as VMS V4.2,
which is much further back than any customer will need.

Larry Kilgallen

Re: Compilers for VAX Was: Ada version of C's 'static'

[Marin David Condic]

Larry Kilgallen wrote:

> > Oddly, we'd really like such a thing, so we could move our
> > source base away from Ada83, while still supporting
> > our VAX/VMS customers...
>
> In a similar position, I am less attracted to that path because a
> straightforward GNAT port would only work on the more recent versions
> of VMS where DECthreads are more mature.  There are a lot of VAX sites
> at V5.5-2, in situations where stability is more important than new
> features.  Be sure to characterize your customer base according to the
> version of VMS they run on VAX.

So it would seem that if you could find a handful of interested parties who would have use
for a VAX/VMS version, it would be possible to share the cost and it might actually get done.
Putting together such a consortium might be a useful way of getting GNAT (or any other
product for that matter) ported to more obscure platforms.

Of course, I'm not sure how that would play with anti-trust laws.... :-)

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <37A7EEF4.160F1A55@praxis-cs.co.uk>,
  Rod Chapman <rod@praxis-cs.co.uk> wrote:
> >
> > I do not know of any validated Ada 95 compilers for the VAX
>
> Anyone know how difficult it would be to construct a GNAT
> targetting VAX/VMS?  Has anyone ever tried such a port?


The elements of it are there, there is a gcc port for VAX/VMS
(I am not sure it is up to date), and there is the GNAT port
of VMS/AXP.

However, it would likely still be quite a large project, even
for someone who was fully familiar with the GNAT technology.
If you are not fully familiar, you would probably be facing
a pretty difficult task.

We have not done the port at ACT, because so far there has been
no serious commercial interest (Digital in particular had no
interest in this port).

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <1999Aug4.072111.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In a similar position, I am less attracted to that path
> because a straightforward GNAT port would only work on the
> more recent versions of VMS where DECthreads are more mature.

Actually I don't think this is correct. I am sure that in this
case there is no such thing as a "straightforward GNAT port".
It would likely take a LOT of work anyway, and porting FSU
threads to VMS is certainly possible (yes it would be extra
work, but in the overall picture of the work to be done would
only be a relatively small (and straightforward) part of the
job).

Note that if someone other than Digital or ACT tries this, they
are lacking a pretty vital component which is the DEC test suite
(this is of course proprietary to Digital). I think it would be
VERY hard to get this port right without access to that suite.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <37A85405.D4754286@pwfl.com>,
  e108678@pwflcom wrote:
> So it would seem that if you could find a handful of
> interested parties who would have use
> for a VAX/VMS version, it would be possible to share the cost
> and it might actually get done.
> Putting together such a consortium might be a useful way of
> getting GNAT (or any other
> product for that matter) ported to more obscure platforms.
>
> Of course, I'm not sure how that would play with anti-trust
> laws.... :-)

Of course it would get done (by ACT) if several people were
seriously interested in commercial support. So far we have not
had even ONE potential customer contact our sales department
regarding a VAX VMS port as far as I know. Yes, I know of some
expressions of vague interest on CLA, but there is a big
distance between such vague expressions of interest and real
commercial interest that can be backed up with a check :-)

If anyone is seriously interested in a VAX port, they should
contact sales@gnat.com expressing this interest.

Obviously ACT is quite willing to do the port if it is paid for,
and if lots of people are interested, of course that reduces the
individual cost. Indeed if enough people are interested, we may
even decide to invest ACT funds in such a port (as we have for
several other ports in the past). But zero people expressing
interest so far is not a good start :-(

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Larry Kilgallen]

In article <37A85405.D4754286@pwfl.com>, Marin David Condic <condicma@bogon.pwfl.com> writes:

> So it would seem that if you could find a handful of interested parties who would have use
> for a VAX/VMS version, it would be possible to share the cost and it might actually get done.
> Putting together such a consortium might be a useful way of getting GNAT (or any other
> product for that matter) ported to more obscure platforms.
> 
> Of course, I'm not sure how that would play with anti-trust laws.... :-)

Perhaps one would have to consider anti-trust laws if the conspirators
were all in the aircraft business, but with diverse participation there
should be no issue.

Larry Kilgallen
who flew on an airliner last weekend :-)

Re: Compilers for VAX Was: Ada version of C's 'static'

[Steve Doiel]

>We had only one problem: as I know, DEC Ada95 is available only for
AXP/VMS.
>
>> -Craig
>
>Regards,
>
>Gaspar
>>

Check out:
  http://www.irvine.com/native.html

I'm not sure if it qualifies as "DEC Ada95" but it does sound like a native
compiler for VAX/VMS.

SteveD

Re: Compilers for VAX Was: Ada version of C's 'static'

[Chris Miller]

> Sorry, there is no DEC Ada95 implementation for *any* machine.
> DEC elected not to update their compiler technology to Ada 95.
> Robert Dewar
> Ada Core Technologies

It's probably history now, but I think DEC's decision not to upgrade their
Ada 83 compiler / debugger / linker / editor and library mgmt tools to Ada
95 was one of the dummest decisions ever made by DEC (and they made a few).

Everyone liked and respected the DEC Ada products. The smart recompilation
was ahead of it's time.

I would suggest many users would have bought an Ada 95 version running on
Alpha & VMS. Instead DEC just went into (terminal !) hibernation.

It's a bit late now I suppose ...

Chris Miller
chrismil@ozemail.com.au
4/8/99.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <1999Aug3.155033.62042@ludens>,
  gazso@ludens.elte.hu (Erdelyi Gaspar) wrote:
> I learnt Ada here at the university on UNIXes with gnat
> compiler and VAX/VMS with DEC ADA 83 compiler. I've tried
> Aonix compilers (95&NT, Sparc/Solaris). I enjoyed the DEC ADA
> compiler, and it's my favourite. (ADA license is needed)
> We had only one problem: as I know, DEC Ada95 is available
> only for AXP/VMS.

Sorry, there is no DEC Ada95 implementation for *any* machine.
DEC elected not to update their compiler technology to Ada 95.
Several vendors (including ACT and Rational) have validated Ada
95 compilers for DEC Unix on the alpha, and there is a DEC
funded port of GNAT from ACT for AXP/VMS, which is designed to
be highly compatible with DEC Ada 83 (that was probably what
you were getting confused by in the above paragraph). The VMS
version of GNAT is also fully validated.

I do not know of any validated Ada 95 compilers for the VAX
currently if that is what you were looking for (I have to
mention this, or Larry will complain again -- maybe he will
anyway :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Rod Chapman]

> 
> I do not know of any validated Ada 95 compilers for the VAX

Anyone know how difficult it would be to construct a GNAT
targetting VAX/VMS?  Has anyone ever tried such a port?

Oddly, we'd really like such a thing, so we could move our
source base away from Ada83, while still supporting
our VAX/VMS customers...
 - Rod

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <3dbq3.4993$_Q2.43341@ozemail.com.au>,
  "Chris Miller" <chrismil@ozemail.com.au> wrote:
> It's probably history now, but I think DEC's decision not to
upgrade their
> Ada 83 compiler / debugger / linker / editor and library mgmt
tools to Ada
> 95 was one of the dummest decisions ever made by DEC (and they
made a few).


Digital felt that it was an infeasible amount of work to
upgrade their Ada 83 technology to Ada 95. Since you are
not in a position to judge the amount of work involved, it
is not clear that you are in a position to lable this as a
"dummest decision" :-)

In fact this decision was made in a much larger context of
general reorganization of Digital in any case, you have to
be aware of the context here.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <37a91f97.0@news.pacifier.com>,
  "Steve Doiel" <nospam_steved@pacifier.com> wrote:
> Check out:
>   http://www.irvine.com/native.html
>
> I'm not sure if it qualifies as "DEC Ada95" but it does sound
like a native
> compiler for VAX/VMS.


I do not believe that this compiler is validated, and it is not
full language, but indeed it may satisfy some requirements for
Ada 95 on VAX/VMS, and is as far as I know the ONLY possible
follow on technology for VMS at the moment, so if you really
need Ada 95 on VMS, that's a place to look!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Larry Kilgallen]

In article <7octd2$top$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <37a91f97.0@news.pacifier.com>,
>   "Steve Doiel" <nospam_steved@pacifier.com> wrote:
>> Check out:
>>   http://www.irvine.com/native.html
>>
>> I'm not sure if it qualifies as "DEC Ada95" but it does sound
> like a native
>> compiler for VAX/VMS.
> 
> 
> I do not believe that this compiler is validated, and it is not
> full language, but indeed it may satisfy some requirements for
> Ada 95 on VAX/VMS, and is as far as I know the ONLY possible
> follow on technology for VMS at the moment, so if you really
> need Ada 95 on VMS, that's a place to look!

If there is no requirement that the compiler be validated for the
platform, Averstar's Ada-to-C AdaMagic compiler might work.

Larry Kilgallen

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert A Duff]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> If there is no requirement that the compiler be validated for the
> platform, Averstar's Ada-to-C AdaMagic compiler might work.

AverStar's Ada-to-C compiler is validated.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Larry Kilgallen]

In article <wccr9lhnh8b.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>> If there is no requirement that the compiler be validated for the
>> platform, Averstar's Ada-to-C AdaMagic compiler might work.
> 
> AverStar's Ada-to-C compiler is validated.

I was under the impression that validation was always for a specific
development machine and target machine.

Was I incorrect in that impression, or are you saying the machine on
which it was validated was VAX/VMS ?

Larry Kilgallen

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert Dewar]

In article <wccr9lhnh8b.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>
> > If there is no requirement that the compiler be validated
for the
> > platform, Averstar's Ada-to-C AdaMagic compiler might work.
>
> AverStar's Ada-to-C compiler is validated.


But not on the VAX. It would be a real reach to claim that it
was validated on all possible targets that have a C compiler :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Tucker Taft]

Richard D Riehle wrote:
> 
> In article <wcc672p6pqt.fsf@world.std.com>,
>         Robert A Duff <bobduff@world.std.com> wrote:
> 
>  ... deleted a bunch of stuff ...
> 
> > ... The main point of having a C-generating Ada
> >compiler is to make it easy to port -- but it's not zero work.
> 
> Not easy.  Not necessarily safe.  I just discovered that another
> favorite language that emits intermediate C code fails to detect
> the famous C "integer overflow" problem at run-time. 

Our compiler correctly handles integer overflow, despite the
fact that it is generating ANSI-C.  And Richard is correct
that this is not trivial to get right and/or efficient.  We added
optimizations into our front end to minimize the amount of extra
code generated to handle overflow properly.

> ... Even though
> C is sometimes thought of as a "universal assembler" suitable for
> "C Pass" compilers, one needs to ensure that the rigorous demands
> of Ada are still satisfied.  I guess conformance (ACVC) tests are
> still useful.  Yes, Dr. Dewar, I realize that conformance testing
> is not completely reliable, but it is better than a ... (fill in
> your favorite metaphor).
> 
> Richard Riehle
> richard@adaworks.com
> http://www.adaworks.com
> 

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert A Duff]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> Was I incorrect in that impression, or are you saying the machine on
> which it was validated was VAX/VMS ?

No, it's not validated on the VAX -- sorry if I said something
misleading.  It's validated on sun/sparc using the gcc C compiler as the
back end, and on the ADI SHARC dsp chip (cross compiler from Windows
95/NT).  If you want it ported to VAX/VMS, talk to Tucker at AverStar
(stt@averstar.com).  The main point of having a C-generating Ada
compiler is to make it easy to port -- but it's not zero work.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Compilers for VAX Was: Ada version of C's 'static'

[Richard D Riehle]

In article <wcc672p6pqt.fsf@world.std.com>,
	Robert A Duff <bobduff@world.std.com> wrote:

 ... deleted a bunch of stuff ... 

> ... The main point of having a C-generating Ada
>compiler is to make it easy to port -- but it's not zero work.

Not easy.  Not necessarily safe.  I just discovered that another
favorite language that emits intermediate C code fails to detect
the famous C "integer overflow" problem at run-time.  Even though
C is sometimes thought of as a "universal assembler" suitable for
"C Pass" compilers, one needs to ensure that the rigorous demands
of Ada are still satisfied.  I guess conformance (ACVC) tests are 
still useful.  Yes, Dr. Dewar, I realize that conformance testing
is not completely reliable, but it is better than a ... (fill in
your favorite metaphor).  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com
 

Re: Compilers for VAX Was: Ada version of C's 'static'

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> Not easy.  Not necessarily safe.  I just discovered that another
> favorite language that emits intermediate C code fails to detect
> the famous C "integer overflow" problem at run-time.

The AdaMagic compiler correctly handles integer overflow.

For efficiency, we need to tailor this part of the compiler to the
specific target.  We also have a completely portable (but less
efficient) mechanism.  And we also have a high-level optimizer that's
pretty good at removing overflow checks entirely (which is of course
most efficient).

This is part of what I meant by "non-zero work".  But it's still
substantially faster to port this compiler than to a new C compiler than
to write a completely new code generator.  (Our front end also has
targets supported in that more traditional way.)

>...  Even though
> C is sometimes thought of as a "universal assembler" suitable for
> "C Pass" compilers, ...

It's kind of annoying to hear C called a "universal assembler" when it
can't deal with integer overflow nearly as well as any real assembly
language I've used.

>... one needs to ensure that the rigorous demands
> of Ada are still satisfied.  I guess conformance (ACVC) tests are 
> still useful.

Indeed.  There's no way we could get away without properly implementing
overflow -- there are dozens of ACVC tests that would fail.  Er, I mean,
ACATS tests.

Another "interesting" issue is stack overflow detection.  The SHARC chip
has a zero-overhead mechanism built into the hardware, but of course
standard C doesn't give us any direct access to that -- we had to write
a little bit of assembly code.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.