Re: Ada --> C Translation

Re: Ada --> C Translation

[dennison]

In article <7047i9$ql1$1@jupiter.cs.uml.edu>,
  dramirez@cs.uml.edu (Dr Amirez) wrote:
> In article <702jg1$gst$1@prime.imagin.net> smize@imagin.net (Samuel Mize)
writes:
> >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.
>
> It's like you have a lot of Ada compilers to choose from!

That's a good point. In my experience its more like 1-3-2. If I've got a say
in it there's usually an extra step

0.5. Find out *if* compiler implements critical features.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada --> C Translation

[Stephen J Bevan]

dramirez@cs.uml.edu (Dr Amirez) writes:
> If C needs to do multitasking, it will use fork() , which is a system
> calls that is not part of C.

I agree that fork is not part of C, but ...

> I bet you can't find fork in libc.a.

It seems that some vendors like to put a binding for it (and a whole
lot more) in libc.a (presumably for the sake of convenience) :-

bash$ cat /etc/motd
SunOS Release 4.1.3 (MAXUSERS128) #2: Thu Jun 13 18:26:42 BST 1996
bash$ nm /usr/lib/libc.a | grep fork | grep -v "U"
Ovfork.o:
00000000 T _vfork
fork.o:
00000000 T _fork

Re: Ada --> C Translation

[Mats Weber]

Dr Amirez wrote:

> If C needs to do multitasking, it will use fork() , which is a system
> calls that is not part of C. I bet you can't find fork in libc.a.

Much more probably it will use pthreads (the current year is 1998).

> Unfortunately, when a read() blocks the whole process suspends. Sorry,

This was true in the past. Now all UNIX Ada compilers I know of use the
underlying OS' kernel threads, which avoid these kinds of blocking.

> tasks, UNIX doesn't know about you. You can work around by poll()ing
> before you read to avoid a block. On the other hand, I haven't seen
> a server that doesn't block and wait for connection . Also I have always
> wondered, if you have 3 tasks before you fork(), do you get 6 tasks
> after you fork(). Is it allowed to fork() at all when you have tasks.

Yes it is allowed to fork from a tasking/threaded program. I do not know the
exact rules (look at the pthreads standard), but it is definitely safe to do
fork in the parent if the child execs immediately (the most usual case).

> I made a big deal out of this  because
> one of the Ada architect on this news group did say that
> when an Ada task blocks on I/O, it's behavior is undefined and
> *NOT* implemention defined.  Even if he's wrong - in which case
> the behavior is implementation defined (and documented)  it's still
> unfortunate.

It is quite normal that the behavior in this situation not be defined by the
Ada standard. Here are a few reasons: some compiler vendors supply a tasking
kernel other than the OS's kernel threads for performance (and other reasons);
some OS have no kernel threads, and there is no other choice than blocking,
but that is better than no Ada compiler.

> For us C programmers, we don't have to go read the
> documentation to see what "i=i++" does. We know it's wrong to use it.
> And it's not a problem like someone puts it. When the law says
> "Don't drink and drive", that's not a problem. When you know the law
> and ignore it, then it becomes a problem.

Compare what is comparable. The C/C++ definitions do not even mention the word
"thread" or "task".

Re: Ada --> C Translation

[Dr Amirez]

Newsgroups: comp.lang.ada
Subject: Re: Ada --> C Translation, was: Win CE target
Summary: 
Expires: 
References: <6vobnk$vt9$1@jupiter.cs.uml.edu> <EACHUS.98Oct13164304@spectre.mitre.org> <702jg1$gst$1@prime.imagin.net>
Sender: 
Followup-To: 
Distribution: 
Organization: UMass-Lowell Computer Science
Keywords: 

In article <702jg1$gst$1@prime.imagin.net> smize@imagin.net (Samuel Mize) writes:
>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.

It's like you have a lot of Ada compilers to choose from!
>
>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.
If C needs to do multitasking, it will use fork() , which is a system
calls that is not part of C. I bet you can't find fork in libc.a.
>
>
>> 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.
>
It's ifdef (maybe you are too used to some case insensitive language)
I don't promote their use either; unfortunately many of the most useful
programs around abound with them (emacs, gcc, etc..) Maybe the code
for the system you work on has them too :)

>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.

>
Unfortunately, when a read() blocks the whole process suspends. Sorry, 
tasks, UNIX doesn't know about you. You can work around by poll()ing 
before you read to avoid a block. On the other hand, I haven't seen
a server that doesn't block and wait for connection . Also I have always
wondered, if you have 3 tasks before you fork(), do you get 6 tasks
after you fork(). Is it allowed to fork() at all when you have tasks.
Hmm, what do Ada wizards call this (undefined or implementation defined
)
>[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

I made a big deal out of this  because
one of the Ada architect on this news group did say that
when an Ada task blocks on I/O, it's behavior is undefined and 
*NOT* implemention defined.  Even if he's wrong - in which case
the behavior is implementation defined (and documented)  it's still
unfortunate. For us C programmers, we don't have to go read the
documentation to see what "i=i++" does. We know it's wrong to use it.
And it's not a problem like someone puts it. When the law says
"Don't drink and drive", that's not a problem. When you know the law
and ignore it, then it becomes a problem.

Dr Amirez

Ada tasks and fork (was Ada --> C Translation)

[Mats Weber]

I wrote:

> Yes it is allowed to fork from a tasking/threaded program. I do not know the
> exact rules (look at the pthreads standard), but it is definitely safe to do
> fork in the parent if the child execs immediately (the most usual case).

For more info on that, see <http://www.dejanews.com/getdoc.xp?AN=278959847>.