From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c78177ec2e61f4ac
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: ada and robots
Date: 1997/06/11
Message-ID: <dewar.866044235@merv>#1/1
X-Deja-AN: 247684241
References: <97060510114032@psavax.pwfl.com>
 <339C1ECF.431B@mlb.cca.rockwell.com> <339E143A.349D@dynamite.com.au>
 <gwinn-1006971856380001@dh5055139.res.ray.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-11T00:00:00+00:00
List-Id: <comp.lang.ada>


<<There were some Ada compilers that did direct hardware OK, but the code
wasn't portable between Ada compilers.  One could have made many of them
work anyway, but why would you?  Portability was one of the major reasons
for use of Ada.  It was simpler to use assembly for those few bits that
touched I/O registers.
>>


If you are willing to speak specifics rather than generalities it would be
useful. The generalizations you make are quite incorrect, but it is hard
to argue against vague stuff.

Please demonstrate with VERY SPECIFIC CODE (not some vague reference to
libraries of device drivers) an example of the kind of portable C code
that you are talking about -- hopefully you are talking about ANSI C
code, or at least C code that is well defined in traditional C.

People often make these vague claims, often they come from people who
know very little about the technical details of Ada, but when we see
actual code, we almost always find that the situation in C and
Ada with respect to such support is essentially identical.