TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"David J.A. Koogler" <[log in to unmask]>
Date:
Tue, 19 Nov 1996 15:07:50 -0800
Organization:
Boolean Solutions, Ltd.
Reply-To:
Parts/Attachments:
text/plain (121 lines)
Message-ID: <[log in to unmask]>
Date: Tue, 19 Nov 1996 12:17:08 -0800
From: "David J.A. Koogler" <[log in to unmask]>
Reply-To: [log in to unmask]
Organization: Boolean Solutions, Ltd.
X-Mailer: Mozilla 3.0 (Win16; I)
MIME-Version: 1.0
To: "W. Wesley Groleau (Wes)" <[log in to unmask]>
Subject: Re: Ada Subset for micro-controller?
References: <9611191458.AA05543@most>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

W. Wesley Groleau (Wes) wrote:

> Why a subset?
>
> Some believe that the full language can not possibly be implemented in a
> cross-compiler for such (a) chip(s).  Well, why not port gnat/gcc to the
> chip first, and find out if compiled code can "fit" and run?  THEN if it
> doesn't, think about what to leave out.

The first thing to examine are the machines upon which GCC runs, since
GNAT
and GCC use the same code generator.  I have seen various discussions on
comp.robotics about using GCC for 6800 series of machines (Motorola
8-bit
microcontrollers) and there are ports to other microcontrollers. What
limits
do these machines impose upon GCC?  From this information one can get a
good
idea of the limits on a GNAT port to these machines.

> In the case of gnat, isn't it true that most of the run-time is in Ada
> and only linked if needed?  So the documentation MIGHT end up saying
> "Can compile full Ada, but if you use features A, B, C, ... then your
> program won't fit in ..."

Indeed almost all of the runtime is in Ada except for a dozen small glue
modules written in C.  In some of my experiments with GNAT, I replaced
several of these C modules (exception handling, and heap management)
with
Ada packages. The translation from C is quite easy, but the Ada versions
are usually much easier to understand especially if you take the time to
use proper type definitions and avoid the cute C coding tricks. It does
not seem to be difficult to rewrite any aspect of the environment to
work
in a limited memory environment.

Tasking is difficult, but not insurmountable. For example, the mapping
to
Windows NT as provided in the LabTek GNAT compiler is quite clean and
simple. The underlying operating system provided most if not all of the
features needed to support Ada tasking. Many of the microcontrollers
operating systems have tasking models similar to Windows NT, and
therefore
it should not be too difficult to make map Ada tasking onto the
underlying
tasking model (just use the LabTek tasking package as a model).

The only problem I see is with interrupt driven tasks. So far GNAT
(version
3.05) has only implemented the Ada interrupt mechansim for a few
architectures
and I have not tried mapping this mechanism to a microcontroller.

> Why _assume_ something is impossible when you have the opportunity to
> _prove_ it? (With the possibility of being pleasantly surprised along the
> way.)

>From all that I have seen with GNAT, the only limits on the compiler are
the same limits that any C compiler faces:

   * Limited memory means most runtime library routines can not be used.
     For example, printf or regexp require lots of code and potentially
     lots of data space.

   * Floating point is not available, except through emulation packages.
     Even here one tends to use the minimum number of FP functions
('add'
     for instance, but not 'sin').

   * Stack depth is very limited, so you tend to write very small
numbers
     of subroutines and severely limit the calling depth.  Recursive
     routines are generally not recommended.

In summary, even though you can use C to write microcontroller software,
your style and approach must be quite different from your style for
writing software on more capable architectures. You must use a subset of
C, but what that subset is depends upon both the machine and the
application.  The subset is purely a mental framework; nothing in the C
compiler forces
you to adopt any particular subset nor are there any facilities to
define
the subset.

Likewise, using Ada on such a machine requires restriction on your
programming technique.  Just as the machine forces you to avoid certain
capabilities in C, you have to avoid certain capabilities in Ada. From
my
experiments, I don't see any fundemental difference in using Ada or C on
such machines.  The restrictions for both languages are similar.

Aside: During the the early 1980's there was an Ada compiler which ran
upon
the Data General Eclipse series machines. These were 16-bit processors
with
a maximum 64-Kb address space. All Data General operating systems
supported
multi-tasking, as did their languages. The Ada runtime enviroment
supported
all of the language within this restrictive environment. I know of at
least
on Ada written application that ran in 16Kb on this machine. Today's
microcontrollers are not that much smaller than yesterday's
minicomputers.

Dave Koogler
Boolean Solutions, Ltd.

ATOM RSS1 RSS2