TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Philip Johnson <[log in to unmask]>
Date: Thu, 14 Nov 1996 11:02:46 -0600
X-To: Ken Garlington <[log in to unmask]>
Parts/Attachments: text/plain (88 lines)
Ken Garlington wrote:
>> Philip Johnson wrote:
> Strong type checking ("data types") would not generally be an issue, I
> suspect. I am more concerned with maintaining task control blocks for
> tasks/protected records and their associated queues. Although I haven't
> received my copy of GNAT yet (I can't use the Internet to download it,
> for reasons too perverse to explain), it's my understanding that the
> implementation of tasks, etc. typically rely on the existence of an OS
> that supports threads. For a bare-machine 8-bit microcontroller, you'll
> have to roll your own. If you have to allocate dynamic memory for such
> things as maintaining queue entries, etc. a general-purpose solution
> might quickly overflow 256 bytes. On the other hand, if you're just
> using tasks to connect to interrupts, then the resulting restrictions
> should allow for very small (possibly no) TCBs.
> Heap allocation is a little more uncertain. It can probably be done,
> but on a machine with almost no dynamic memory, is it worth the effort?
> Just maintaining a stack is probably going to be interesting...
> Ada.Text_IO is kinda in the same boat. Why bother implementing a file
> system on such a machine? It may not even have a port to connect to
> a conventional I/O device like a terminal or a printer...
> The short answer is: If it's easy to implement full Ada on an 8-bit
> microcontroller, that's what I'll do. However, I suspect that when
> converting all those OS calls, I'm going to hit some problems.

This is what I was trying to point out.  Rather than produce an Ada
subset for embedded controller systems why not just add the packages
to support the architecture.  I have some embedded systems that have
a limited control domain (raise/lower, open/close) that is very small
and runs in 256 bytes of memory located on the processor.  I mostly
have embedded control systems that has a real-time executive in EEROM
that provides the OS functions with limited multitasking (8-16 tasks).
The RT OS calls can be implemented in the system package, etc.

> > The implementation of Ada tasking should meet the system
> > architecture. I have used Ada tasking on Unix that is implemented
> > as child processes. The ObjectAda that I am using on WindowsNT
> > implements tasks as treaded processes.
> "Unix"? "WindowsNT"? I think I could fit these strings in 256 bytes,
> but that's about it... :)

I used this to only to demonstrate that tasking should be implemented
to match the specific architecture on different system.

[deleted stuff]

> Most of the current implementations are in assembly, so I don't think
> I'm going to harm portability much :) However, certainly it would be
> useful if the ARA or some other group defined a standard. Sy Wong
> argued for this at the last TRI-Ada, and the vendor community said
> "no way".

Embedded control systems are rather unique in that they can range from
a single processor (square inch controller) to a fairly large
configuration.  I do agree that there should be a concerted effort to
define system packages that address this, but I do not believe in
producing an Ada language subset as a solution.

The good thing about Team-Ada is that diverse opinions are discussed and
usually produce a better solution.  8^{)

|                Ada, Perl, and Java! It can't get any better.
|Philip Johnson                             Telco: (205) 890-1178
|Sr. Software Engineer                      Fax  : (205) 890-1174
|International Space Systems Inc.           email: [log in to unmask]
|Huntsville, AL