Re: Why Ada is not the Commercial Lang of Choice

[ohk@edeber.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB)]

Ken Garlington <Kennie.E.Garlington@lmco.com> writes:

> 
> Paul Van Bellinghen writes:
> > 
> > Claim:
> > It is much easier in C, for example, to output a data word to
> > an I/O device that is memory mapped.
> > 
> > Supporting Evidence:
> > 1       One need only define a pointer
> > 2       and assign it the memory mapped address
> > 3       then store the desired data value to the contents of the pointer.
> 
> In Ada, something like:
> 
>    Memory_Mapped_Address : constant := 16#0100040#;
> 
>    Memory_Mapped_Value : Interfaces.C.unsigned; -- just to keep type
> compatibility
>    for Memory_Mapped_Value'Address use Memory_Mapped_Address;
> 
>    Memory_Mapped_Value := 16#00344556#;
> 
> And the neat thing is, Memory_Mapped_Value will always be mapped to the
> area of memory you want! No worries about your pointer being corrupted
> --
> because there isn't a pointer! Who knows, now that the compiler knows
> that the address is fixed, you might even get more efficient code!


You don't need the pointer in C either. Just 

#define Memory_Mapped_Value (*(int *) 0x0100040)

Memory_Mapped_Value = 0x00344556;

has the same effect, except for the scope of Memory_Mapped_Value.


> 
> > 
> > Example:
> >  #define mem_map_addr B0100040
> >  unsigned int *p;
> > 
> >  p = (unsigned int *) mem_map_addr;
> > 
> >  *p = 0x00344556;
> 
> Claim: The Ada does the same thing, in the same number of lines, and it
> does it
> more safety, more clearly, and (gasp) possibly more efficiently!
> 
> --
> LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
> Who uses Ada? See http://www.lmasc.lmco.com/f22
> For job listings, other info: http://www.lmtas.com or
> http://www.lmco.com

Btw., I have been thinking about not being able to assign an explicit
value to the tag of a discriminant union. It will certainly be a
problem, if you intend to store your unions in a file, and read this
file with another Ada program compiled with another compiler.
This would work well in C, because you would typically use an enum
with explicit assignment of values. Now, I am aware that in C, the tag
field is not mandatory, so it's not really a fair comparison, but it
means that you cannot output the union directly. 

Yes, I am aware that it will not be portable from one kind of CPU to
another anyway, and that you can circumvent the problem by converting
to an external data representation, but there are instances where you
want to reduce the overhead as much as possible, for instance when
working in the lower layers of a DBMS.

It seems to me that in Ada, (almost) all problems can be solved,
according to the standard, but in practice, the implementations are
different enough that it does not work in some cases. In C, the
standard does not guarantee that it works, but it will, in all but a
few cases. The actual difference in terms of what is portable isn't
all that great.

That said, from my former experience with Ada, I would personally
rather build a system in Ada than in C/C++ if compilers and
development systems are available at a reasonable price. 
The project I'm working on, originally intended to use Ada (about 7
years ago), but reverted to C++ after seeing the following
difficulties:

1. EVERY potential customer asked why it was written Ada, and not in C++, and
it was clearly seen as a serious drawback.
2. Compilers very very expensive, even compared to C++.
3. Compilers were not available for all the target operating
systems. (it turned out that we now use only Unix anyway, but that's
another story)

I am still convinced that it would have been better to use Ada. We
have had a fair share of bugs which would typically not have occured
if we were using Ada, especially in the homegrown multi-tasking
system. However, from measurements I have been doing, the homegrown
multitasking is also very much faster than using Ada tasks. Of course,
we could avoid using Ada tasks, but then much (not all) of the benefit
of Ada would disappear as well.  And in case you wonder, the task
switching time becomes very significant when you are running 100 -
1000 transactions per second.  But I would rather get it right first,
then optimize.