Re: Ada --> C Translation, was: Win CE target

[Niklas Holsti <nholsti@icon.fi>]

Dr Amirez wrote:
> 
  [ snipped a lot of quotes ]

>  i would have dropped this. But since I am so bored I might as
>  well flame away.

Hoping to entertain you, I reply.

>  Well the reason why I brought the Operating systems issue up
>  is that it's impossible to write Ada utilities without an
>  Ada OS.

That is untrue. All Ada systems have the ability to interface to
the operating system. For one thing, Ada bindings to the POSIX
APIs are extensively standardised.

Also, I get the impression that you believe that no Ada OS exists.
To my knowledge, at least two OSes have been written in Ada:
the OS for the Rational R1000, and the OS for the Nokia MPS-10.
(Neither machine is alive today, but this is not because of
the OS implementation language.)

In addition, many if not most of the run-time systems (real-time
kernels) delivered with Ada compilers are written in Ada.

>  The core dumping has been a facility on UNIX to assist
>  in debugging .Maybe you don't know enough about UNIX. C programs can disable
>  the core dumping if they want to. The reason a core was left
>  behind was for the debugger to look at.

Of course the problem was not that a "core" was left behind.
(Having a core dump is indeed better than not having one.)
The problem was that the program crashed, instead of giving
a helpful error message.

>  Maybe Ada programs
>  don't have bugs so they don't have to dump cores or they contend
>  with printing a message "Array out of bound" then exit. I feel
>  neither approach is adequate. There are systems out there without
>  a screen to display a message or a disk drives to dump a core.
>  Bugs are bugs. They need to be fixed. I couldn't care less
>  how they are handled. They just need to be fixed.

Programs have flaws. Some languages (Ada among them) check for
common errors (at compile time and at run time) so that a
somewhat meaningful error message can be emitted. Some languages
(Ada and C++ among them) let you, the programmer, define what
to do when an error is detected at run time. In some cases,
the program can recover and continue; in all cases, it can
issue a detailed, specific error message that helps you fix
the flaw. The C language just runs on until the program is
totally messed up. Want to bet in which language bugs are
easier to fix?

  [ examples of C problems snipped ]

>  Not knowing Ada,  i will have to reiterate on the example
>  of undefined behavior on task. Basically if a task blocks
>  on I/O then anything -absolutely anything -can happen.

You are exaggerating this. What can happen is that either just
this task blocks and the other tasks continue, or all tasks
block until the I/O completes. The latter (undesirable) behaviour
can occur in an Ada implementation under an OS such as Unix or
Windows NT, if the entire Ada program has been mapped to
one OS process and the I/O call is process-blocking.

Exactly the same two cases can occur in a multi-threaded C
program, depending on the type of threads and OS calls used.

In modern Ada implementations the usual approach is to make each
Ada task a thread and use I/O calls that block only the
calling thread.

Whichever case happens, the execution of the Ada program
continues, once the I/O is completed. Only the real-time
aspects are affected.

Note that Ada was originally intended for bare embedded systems
where this problem cannot occur. The idea was that the whole
system, including I/O drivers, is written in Ada using the
Ada tasking model and run-time system. In this context, the
Ada standard defines the intended real-time performance quite
clearly. Modern Ada implementations using threads also
do this well.

>  What is the attitude of Ada? Don't use tasks? Use tasks
>  but do not perform I/O in tasks? Have tasks perform I/O
>  and pray nothing bad happens?

The attitude is to check the compiler documentation for
the blocking implications of OS interactions -- if you
are using an OS. Again, this affects only real-time
performance.

In practice, the only case where this problem is significant
for portability is where some task is waiting for an I/O
that can take an indefinite time, such as reading an
operator command or a network message. If your program
needs this, you choose a non-blocking OS call, or check
that your compiler uses such calls for Ada I/O procedures.

>  Someone here complained about C leaves so many things
>  undefined. True. Just don't do them. It's not "Yeah, it might
>  work for you, try it and see. "

The C problems are in C itself. The Ada task blocking
problem is not in Ada, but in the Ada-OS interaction.

I've met many C programmers who use the "try it and see"
approach. Also some Ada programmers... but it is definitely
not the "Ada attitude".

>  Dr Amirez

Niklas Holsti