From: sunset.sda.com!blakemor@uunet.uu.net (Alex Blakemore)
Subject: Re: Why Ada, Ada Success story?, Please read an comment
Date: 27 Mar 92 17:07:48 GMT [thread overview]
Message-ID: <138@sunset.sunset.sda.com.COM> (raw)
This posting replies to Matthew Jones Ada comments:
There is source code example at the end to counter
his claim that to write a hex dump in Ada is difficult:
-----------------
In article <1637@nic.cerf.net> jonesm@nic.cerf.net (Matthew Jones) writes:
> After a year I came to the following conclusions:
> 1. The Ada compiler after comming out of Beta has been pretty good.
> For some proposals we compared it against C. I think this unfair
> because it causes a lowest common denominator in term of design.
> C generally won out but Ada did run faster on some machines most notably
> Ada VAX/VMS.
there are many criteria for judging a compiler, speed of generated
code is only one: others are robustness, code size, usefulness or
error messages and warnings, speed, interfaces to other
tools/libraries, supporting tools, environment etc, cost etc
correctness of generated code (PRIMARY), support for optional Ada
features, and how it handles complex Ada features
> 2. TEXT_IO generally ran slower than C printf and has alot less
> functionallity. I am willing to show examples if someone cares to
> challange this. Like write a hex dump with text_io.
text_io is only one IO package, you are free to use any other,
Ada provides some very useful generic IO libraries sequential and
direct_io that work with the complex or simple data type of yor
choice, text_io is for TEXT. to write a hex dump, just
instantiate sequential_io and its easy, thats what sequential_io is
designed for, not text_io.
sample simple hex_dump is appended to this message.
> > 3. We had a debugger called a.db and it has problems, wierd things
> happened when I stepped through instantiations of a generic.
a.db could use improvement
> 4. The bad problems started here. It takes way to long to do a
> rendezvous. We have just a lot more bugs in this area.
how do you know, did you measure? did you buy a compiler that
claims to be designed for real time with efficient rendezvous
and user control over rts. or did you buy a a generic all
purpose Ada compiler? did you tasks poll each other or busy wait?
designing concurrent programs is hard in any language
rendezvous overhead is only part of the equation, it can be
very significant or irrelevant depending upon what you are doing.
> 5. Even today a year after we brought Ada still load balancing on
> parallel processors doesn't work.
the language doesnt solve every problem, does your vendor claim
to migrate tasks for load balancing using the run time system?
the Ada standard doesnt claim this. if the vendor claims to do
so, but doesnt complain to him - dont blame the language standard
> 6. Customer service sayes that for their products they have many more
> C customers and C is simpler therefore the product gets mature
> faster. This makes alot of sense. Consider, Microsoft I've heard
> had 50,000 beta customers for C/C++ Version7.0. How many do Alsys
> and Meridian have for their PC Ada compilers.
thats true, the complexity gets pushed onto the individual
projects, little projects are easy in C, its like a vicious
circle - I think Ada has been severely hurt by vendors who
thought they were done when they finished validation and
only spent money on ports and marketing. poor compilers gave
Ada a bad rep which reduced the market which gave vendors less
reason to invest which led to poor compilers getting better even
slower - which led back to square one.
> 7. I believe someone made the claim that C++'s dynamic memory was wierd.
> While this may be true I think a similar claim can be made for Ada.
> We did a lot of dynamic memory allocation in our Ada application
> and there were raised exception and handlers at various levels,
> we found it amazingly easy to cause very hard to find problems,
> by mixing these two features.
that's not Ada's fault, dynamic memory can lead to complex
programs. Ada's rules about dynamic memory allocation and
exceptions are pretty straightforward - with the exception of
finalization which is in Ada9X. its certainly better than dealing
with malloc and free of untyped storage.
> 1. Can anyone really claim that there exists a machine that load balances
> Ada tasks over multiple processors?
I thought Sequent, Encore, Alliant did
> 2. Do or did the Ada designers have even a clue as to how parallel
> processors work? If so, why do multiprocessor venders have so much t
> rouble with Ada?
be more specific, what target are you talking about?
multiprocessing is fairly recent, Ada certainly doesnt provide
any more barriers than C, what C or C++ features support this ?
NONE, but vendors provide library routines, well why cant you
call those routines from Ada? if you want the Ada task semantics
on a multiprocessor, then you do need the vendor's support
if they dont help, you can at least do what they do in C, just
dont use the tasking portion of the language.
> 2. Does anyone NOT find Ada tasks to be too slow for realtime use?
there were just several postings of positive real time
experiences - I dont know whether they used tasks
YOU DONT HAVE TO USE ADA TASKS TO WRITE CONCURRENT ADA PROGRAMS
do you read this group?
> 3. Do people generally find all the advertised features to work as
> advertised?
not always
> 4. Does anyone like text_io?
aint perfect but yes I like it
> 5. Is Verdix considered a good Ada company?
there are several others, DEC and Rational are claimed to be
exceptional. There are also Telsoft, Alsys, Meridian, Tartan
and others. some focus on real time market - others on
educational or PC market, they differ - shop around
> 6. I thought I've read read that Ada is more consistant than other languages.
> If so, then please explain how "a: array (1..5) of integer" is okay
> as a variable definition and not for parameter passing?
RTFM, as a variable def it defines an anonymous type,
if you did the same thing as a parameter def, no one could
pass anything of that anonymous type - name your types - its not hard.
------------------- hex dump source ----------------------------------
with sequential_io,
text_io;
procedure hex_dump is
-- simple little hex dump to show sequential_io
-- little formatting or efficiency changes
-- prompt for file name because command line
-- accessing in Ada is not terribly portable
-- adding other options like od's -c etc aren't hard
-- to do more formatting, you can use the 'to_string' version
-- of text_io's put routines or 'value and then polish before output
max_filename : constant := 200; -- this hard coded limit can go away in
-- Ada9X, mail to ada9x-mrt@inmet.inmet.com
units_per_line : constant := 4; -- you choose
output_base : constant := 16; -- you choose again
file_name : string (1 .. max_filename);
name_length : natural;
subtype raw_data is integer;
-- I would prefer 'type raw_data is range 16#00# .. 16#FF#;'
-- but the Ada compiler I have access to currently has a problem with it :(
package raw_io is new sequential_io (raw_data); -- powerful Ada feature
:)
package hex_io is new text_io.integer_io (raw_data); -- convenient
input_file : raw_io.file_type;
current_data : raw_data;
units_on_this_line : natural := 0;
begin -- hex_dump
text_io.new_line;
text_io.put_line ("Simple Ada hex dump");
text_io.new_line;
text_io.put ("File to dump => ");
text_io.get_line (file_name, name_length);
raw_io.open (input_file, raw_io.in_file, file_name (1 .. name_length));
-- read some raw bits in, write some formatted ASCII out
text_io.new_line;
while not raw_io.end_of_file (input_file) loop
raw_io.read (input_file, current_data); -- simple
hex_io.put (current_data, width => 14, base => 16); -- solution here
units_on_this_line := units_on_this_line + 1;
if units_on_this_line = units_per_line then
text_io.new_line;
units_on_this_line := 0;
end if;
end loop;
text_io.new_line;
raw_io.close (input_file);
end hex_dump;
--
Alex Blakemore
alex@cs.umd.edu blakemor@marlstone.com
NeXT mail accepted
next reply other threads:[~1992-03-27 17:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1992-03-27 17:07 Alex Blakemore [this message]
-- strict thread matches above, loose matches on Subject: below --
1992-03-26 20:01 Why Ada, Ada Success story?, Please read an comment Matthew Jones
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox