From: smize@news.imagin.net (Samuel Mize)
Subject: Re: Ada --> C Translation, was: Win CE target
Date: 1998/10/14
Date: 1998-10-14T00:00:00+00:00 [thread overview]
Message-ID: <702jg1$gst$1@prime.imagin.net> (raw)
In-Reply-To: EACHUS.98Oct13164304@spectre.mitre.org
In article <6vobnk$vt9$1@jupiter.cs.uml.edu> dramirez@cs.uml.edu
(Dr Amirez) writes:
> ... If you consider a feature rich language a better language
> then let me tell you this. I remember seeing a question on this forum
> that goes like this: "If a task blocks on I/O, do other tasks get a chance
> to run or the *process* will suspend itself, and no task will run
> until the process get scheduled again? "
> Someone responded that it's undefined. Well, I would think such
> an important feature should be very well defined instead of being
> left as an excercise for the user to find out how that is implemented
> on their systems.
By golly, he's right. we should pick one way and stick to it. If
somebody needs a different one later, he can make up his own darn
language.
Seriously, I/O blocking is only ambiguous for the predefined I/O
packages, which are convenience packages. Ada was originally defined
for embedded systems. If I'm building a real-time simulator, or an
embedded radio system, or a crypto module, I really don't care whether
Text_IO blocks the process or not. I'm never going to use it anyway,
I'm going to be watching I/O ports with machine-specific code.
Also, if I recall correctly, this WAS defined for Ada 83, by
implication at least[1]. In Ada 95 the situation was improved by
making it LESS defined. This lets vendors offer more options,
and makes it cheaper to put Ada on new targets.
Your discussion seems to assume this model for development:
1. Get compiler
2. Write program
3. Find out how compiler implements critical features
The Ada community tends to put step 3 before step 1.
Actually, though, much of the commercial C community uses your
model. They buy a box, and they use whatever compiler came
with the box. Why, of course you use the vendor's C compiler --
how else do you get all their system-specific libraries? But,
of course, those aren't actually part of the language, so it's
OK for their definitions to wander all over the map.
> You can't program systems using features that are system dependant
> themselves.
I see. That must be why most of the system code I've seen is shot
through with IFDEFs like cancer. You tell the compiler or make
utility which versions of all the system calls you have available, and
it tries to assemble a version of the program that will work.
The Ada approach is to start by selecting a compiler that does what
you need.
Both approaches work. Neither works with the other technology.
> The more features a language has, the more flaws it has. You, as an
> Ada programmer, probably know better than I.
I assume you're saying that a more complex system has more
opportunities for bugs[2]. However, that argument ignores the fact
that these language features replace user-written code. Ada was
designed to provide features that most embedded systems already
had, but which were hand-built in system after system.
Most of the embedded community's programs need some form of
multi-tasking, for example. It's a LOT less error-prone to have
one implementation of tasking, that gets exercised by hundreds of
projects, and that everyone tests the BLEEP out of. You wind up
with a very solid tasking implementation. The alternative gives
you a very simple language, everybody implements tasking separately
(costing a small fortune), and lots of bugs wind up in delivered
systems.
By the way, Dr Amirez, my news feed doesn't seem to pick you up
-- I'm replying to another reply to your post -- so please email
me if you reply. Thanks.
Best,
Sam Mize
[1] A lower-priority tasks's processing -- even a system call --
should not block a higher-priority task that becomes ready. Some
implementations failed to get that right, and it wasn't tested by
the validation suite, so some compilers that blocked on I/O got
into the community. Which is why you heard the question at all.
[2] I'm assuming this meant "You, as an Ada programmer, probably
know this even better than I do." However, I won't ARGUE with
the statement as written. :-)
--
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam
next prev parent reply other threads:[~1998-10-14 0:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-09-20 0:00 Win CE target William A Whitaker
1998-09-20 0:00 ` Tucker Taft
1998-09-21 0:00 ` dennison
1998-09-21 0:00 ` dewarr
1998-09-28 0:00 ` Ada --> C Translation, was: " Stefan Helfert
1998-09-29 0:00 ` Tucker Taft
1998-09-30 0:00 ` dewarr
1998-09-29 0:00 ` Robert A Duff
1998-10-10 0:00 ` Dr Amirez
1998-10-11 0:00 ` Dale Stanbrough
1998-10-10 0:00 ` Dr Amirez
1998-10-11 0:00 ` Dale Stanbrough
1998-10-11 0:00 ` Dr Amirez
1998-10-12 0:00 ` Larry Kilgallen
1998-10-13 0:00 ` dennison
1998-10-12 0:00 ` Niklas Holsti
1998-10-12 0:00 ` dennison
1998-10-12 0:00 ` Larry Kilgallen
1998-10-14 0:00 ` dewarr
1998-10-14 0:00 ` Andi Kleen
1998-10-12 0:00 ` PC
1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen
1998-10-12 0:00 ` Chris Morgan
1998-10-13 0:00 ` Larry Kilgallen
1998-10-13 0:00 ` Dale Stanbrough
1998-10-14 0:00 ` dewarr
1998-10-12 0:00 ` Tom Moran
1998-10-12 0:00 ` Brian Rogoff
1998-10-13 0:00 ` dennison
1998-10-13 0:00 ` Brian Rogoff
1998-10-13 0:00 ` Tucker Taft
1998-10-12 0:00 ` dennison
1998-10-21 0:00 ` Van Snyder
1998-10-22 0:00 ` Tom Moran
1998-10-13 0:00 ` Ada --> C Translation, was: Win CE target Robert I. Eachus
1998-10-14 0:00 ` Samuel Mize [this message]
1998-10-16 0:00 ` Tasking/blocking system calls (was: Ada --> C Translation) Mats Weber
1998-09-20 0:00 ` Win CE target dewarr
1998-09-20 0:00 ` dewarr
1998-09-23 0:00 ` falis
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox