Re: Why should hackers love Ada. (Re: Ada 95 based RTOS)

[Gary Scott <scottg@flash.net>]

Mike Silva wrote:

> Gary Scott wrote in message <38B5C9E6.143A32D6@flash.net>...
> >Larry Kilgallen wrote:
> >
> >> In article <38B55928.8A0EAB06@quadruscorp.com>, "Marin D. Condic"
> <mcondic-nospam@quadruscorp.com> writes:
> >> > Gary wrote:
> >> >> I see this reference to ADA being good at bit twiddling, periodically.
> >> >> Virtually all high-level languages provide facilities for bit
> twiddling.  Is
> >> >> there something unique about ADA (I'm a non-ADA programmers, sorry).
> Is this
> >> >> a reference to a transfer function (other languages have this) or
> memory
> >> >> aliasing tricks?
> >> >
> >> > Well, I don't know what the rest of the world means by "bit twiddling"
> >> > but I know what *I* mean when I say that. ;-)
> >> >
> >> > You have all the facilities you need in Ada (Ada95 - Ada83 didn't do
> >> > this well) to do shifting, masking & other manipulations of individual
> >> > bits within words. If you've ever had to do interfacing to low level
> >> > devices, hardware registers, I/O ports, etc., then you know that you
> >> > can't always deal with data as an "abstraction" where you can allow the
> >> > compiler to pick whatever representations it wants and manipulate
> things
> >> > any way it likes. Often I have been up against time constraints where
> >> > even if a high level method of solving the problem may work fine, we
> >> > dipped into bit masks and logical operators because they degenerated to
> >> > much more efficient code.
> >> >
> >> > Ada95 lets you get at things like this when you need to. The difference
> >> > between Ada and C on this issue is that with Ada it is a "last resort"
> >> > whereas with C it is a "way of life". (Look at how lots of bindings to
> C
> >> > stuff includes numeric constants for specifying options by or'ing
> >> > together the constants. While Ada can do that, it isn't the usual
> >> > idiom.)
> >>
> >> I think a major advantage of Ada is that it lets the programmer deal
> >> at a higher level for the main body of the program, while only the
> >> interface description contains the specification that bits 2-4 are
> >> treated as a numeric field for the unit number.  The compiler aids
> >> and enforces adherence to that specification without requiring the
> >> programmer to be constantly thinking about it and getting it right.
> >
> >This is a good feature, but many other languages have similar features
> (some very old like Jovial and PL/1).
> >In other languages, my experience is that you simply define
> pack/unpack/scale routines and write the main
> >executive and high-level functionality in a high-level fashion (possibly
> OO) and simply invoke these low-level
> >"reformat" routines at the top and bottom of the frame (or as-required).
> Then again, I'm also used to being
> >able to embed assembly to gain access to an interval timer or generate an
> interrupt right into the high-level
> >language code.
>
> It seems that you are challenging the group to prove that Ada is somehow
> "the best" at "bit-twiddling".  I suspect that the only claim that can be
> made is that Ada has very good support for such things -- not only
> bit-twiddling but also e.g. specification of data representations, tasking
> and interrupt handling.  Ada is simply a very nice general purpose language
> that has everything you need for cuddling up to the hardware.

:-) I wasn't really challenging the group to prove Ada's worth, I'm just an
interested non-ADA programmer.  My company uses Ada 83 extensively and has had
significant difficulty meeting memory footprint and code execution performance
criteria.  I believe this to be mostly the result of poor management decisions
regarding forced use of OO in inappropriate ways (yes I know its Ada 83, not Ada
95).  I'm really just interested in understanding better the reasons for these
difficulties.

>
>
> Mike




--

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com