Win CE target

Win CE target

[William A Whitaker]

Is there such a thing as an Ada 95 Win CE target.  Does it make sense? 
I have never seen, touched or smelled a Win CE so I have no idea if it
is possible or desirable.

Whitaker

Re: Win CE target

[dewarr]

In article <3604A4C6.8C4@erols.com>,
  whitaker@erols.com wrote:
> Is there such a thing as an Ada 95 Win CE target.  Does it make sense?
> I have never seen, touched or smelled a Win CE so I have no idea if it
> is possible or desirable.
>
> Whitaker


Well first, Win CE is available for multiple architectures,
so you are talking about a family of ports rather than a
single port (it is much like asking if there is an Ada 95
Unix target).

The targets for Win CE are all familiar ones (e.g. x86)
so it certainly would not be impossible to create a Win CE
port. As with other Microsoft products, probably the biggest
problem would be Microsoft's annoying habit of keeping
things secret (e.g. NT is the only kernel based system where
the kernel interface is secret, and the debugging formats
are secret). Still people have (with effort!) managed to
figure out many of the details for NT, and probably Win CE
would be no worse.

Probably the most practical approach is to try a GNAT port.
We have had no customer interest in such a port so we have
not investigated this, and as far as we know, no one else
has worked on a GNAT Win CE port.

Most certainly a port of Ada to Win CE is possible,
practical, and desirable! I would also like to see a GNAT
port for the Palm Pilot, which is also possible, practical
and desirable. Again with PP, you run into annoying
proprietary secrecy (the PP license, which supposedly you
agree to by just opening your PP says that you recognize
that the user interface of the PP is a valuable trade
secret of 3COM which you will not disclose to any
unauthorized third party :-)

Robert Dewar
Ada Core Technologies


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Win CE target

[dewarr]

In article <3604A4C6.8C4@erols.com>,
  whitaker@erols.com wrote:
> Is there such a thing as an Ada 95 Win CE target.  Does it make sense?
> I have never seen, touched or smelled a Win CE so I have no idea if it
> is possible or desirable.
>
> Whitaker

Well first, Win CE is available for multiple architectures,
so you are talking about a family of ports rather than a
single port (it is much like asking if there is an Ada 95
Unix target).

The targets for Win CE are all familiar ones (e.g. x86)
so it certainly would not be impossible to create a Win CE
port. As with other Microsoft products, probably the biggest
problem would be Microsoft's annoying habit of keeping
things secret (e.g. NT is the only kernel based system where
the kernel interface is secret, and the debugging formats
are secret). Still people have (with effort!) managed to
figure out many of the details for NT, and probably Win CE
would be no worse.

Probably the most practical approach is to try a GNAT port.
We have had no customer interest in such a port so we have
not investigated this, and as far as we know, no one else
has worked on a GNAT Win CE port.

Robert Dewar
Ada Core Technologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Win CE target

[Tucker Taft]

William A Whitaker (whitaker@erols.com) wrote:

: Is there such a thing as an Ada 95 Win CE target.  Does it make sense? 
: I have never seen, touched or smelled a Win CE so I have no idea if it
: is possible or desirable.

We have an Ada 95 compiler that generates efficient, human-readable
ANSI C as an intermediate language.  Given sufficient interest, this 
could be integrated with any ANSI C development system for "Wince" 
to produce an Ada 95 capability.

: Whitaker

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Win CE target

[dennison]

In article <EzLBxq.40n.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> We have an Ada 95 compiler that generates efficient, human-readable
> ANSI C as an intermediate language.  Given sufficient interest, this
> could be integrated with any ANSI C development system for "Wince"
> to produce an Ada 95 capability.

Is this the legendary "Ada to C" converter that everyone is always asking
about? :-)

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Win CE target

[dewarr]

In article <6u65h0$f1b$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <EzLBxq.40n.0.-s@inmet.camb.inmet.com>,
>   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
> > We have an Ada 95 compiler that generates efficient, human-readable
> > ANSI C as an intermediate language.  Given sufficient interest, this
> > could be integrated with any ANSI C development system for "Wince"
> > to produce an Ada 95 capability.
>
> Is this the legendary "Ada to C" converter that everyone is always asking
> about? :-)


Well of course the issue is the word "readable" in Tuck's
message (some people can read things more easily than others,
after all some people think the whole of the Ada RM is quite
readable :-)

Compiling Ada by translating into C is nothing new, at least
two vendors have followed this route before. Whether IM has
somehow managed to succeed where the others failed in
producing readable code remains to be seen.

Some of the trouble areas in compiling into C are

  1. Arithmetic overflow checks, especially in complex
     expressions, which have to be broken down into steps
     or written in prefix notation.

  2. Nested procedures, and particularly nested procedures
     with complex local declarations.

  3. Subunits (hard to do anything other than create a huge
     source in which the subunits are substituted).

  4. Exceptions

Note here I am talking about readability, rather than
efficiency, although all the above are also efficiency
issues.

Of course if you write simple minded Ada that uses only
features that translate into C, then the two vendors
compilers that I have talked about in the past have
worked fine.

Note that the list above is a small one, there are many
other problems.

It is interesting in the case of GNAT and GCC, that of course
it was possible for us to translate GNAT into a form that can
be processed by the backend, but we preferred not to because
the transformations were awkward and would have intefered
with optimizations in some cases. So we enhanced the backend
for example by adding self describing types to map Ada's
variant records directly. And remember we were working not
with C, but with GNU C, which solves some of these problems

Actually if I was trying to write a translator like this, I
would certainly consider Ada to GNU C, which would be much
easier. However, that would not meet all needs (e.g. the
requirement as for the SHARC of interfacing to the vendors
proprietary C compiler).

I will say for the record, that, according to MY definition
of readability, it is not possible to translate Ada 95 into
readable C in all cases.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

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

[Stefan Helfert]

dewarr@my-dejanews.com wrote:
[...]
> Some of the trouble areas in compiling into C are
> 
>   1. Arithmetic overflow checks, especially in complex
>      expressions, which have to be broken down into steps
>      or written in prefix notation.
> 
>   2. Nested procedures, and particularly nested procedures
>      with complex local declarations.
> 
>   3. Subunits (hard to do anything other than create a huge
>      source in which the subunits are substituted).
> 
>   4. Exceptions
> 
[...]
> I will say for the record, that, according to MY definition
> of readability, it is not possible to translate Ada 95 into
> readable C in all cases.

Clearly this is a statement that you cannot argue with.  

But I am tempted to add that the C preprocessor features clearly help to
add readability to a certain degree.  One of my projects some time ago
was a ML2C-translator, where we wanted to preserve "style" (not only
readability).  Now ML covers, as you may know, most of the language
features that Ada sports (especially those mentioned above) and adds
more (famous: garbage collection).  And ML as a functional language is
relying on a different programming paradigm.

The C preprocessor did really help a lot: E.g., you can implement
exceptions with setjmp/longjmp and hide this before the users' eyes, or
hide the interface to the garbage collector/memory management.


Stefan Helfert

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

[Robert A Duff]

Stefan Helfert <helfert@galileo.mpi-hd.mpg.de> writes:

> dewarr@my-dejanews.com wrote:
> [...]
> > Some of the trouble areas in compiling into C are
> > 
> >   1. Arithmetic overflow checks, especially in complex
> >      expressions, which have to be broken down into steps
> >      or written in prefix notation.
> > 
> >   2. Nested procedures, and particularly nested procedures
> >      with complex local declarations.
> > 
> >   3. Subunits (hard to do anything other than create a huge
> >      source in which the subunits are substituted).
> > 
> >   4. Exceptions
> > 
> [...]
> > I will say for the record, that, according to MY definition
> > of readability, it is not possible to translate Ada 95 into
> > readable C in all cases.

What's YOUR definition of "readability"?

A master C programmer doesn't have access to any of the features
mentioned above (eg nested procedures), either.  So of COURSE a program
that could benefit from nested procedures will be more readable in Ada
than in C (eg maybe the C code will have to pass extra bogus parameters,
or whatever).

Of course an automatic translator can't use nested procedures either.
Or subunits.  Or tasks.  Or whatever.

But, given an automatic translator from Ada to C, one ought to measure
the readability of the translator output with respect to hand-written C
code.  Given that the hand-written C code can't do (say) exceptions in
any direct way, why should one complain when the output of the
Ada-to-C translator can't do it directly?

In other words, we shouldn't complain if the generated C code is less
readable than the Ada code; we should only complain if the generated C
code is less readable than typical hand-written C code.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

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

[Dr Amirez]

In article <wcck92nbxdh.fsf@world.std.com> Robert A Duff <bobduff@world.std.com> writes:
>Stefan Helfert <helfert@galileo.mpi-hd.mpg.de> writes:
>
>> dewarr@my-dejanews.com wrote:
>> [...]
>> > Some of the trouble areas in compiling into C are
>> > 
>> > 
>> >   4. Exceptions
>> > 
Well, C didn't have exceptions for years and probably will never have it.
That didn't keep it from being one of the most successful languages
ever created. 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. After all, isn't Ada intended to be a system 
programming language? You can't program systems using features that 
are system dependant themselves.
The more features a language has, the more flaws it has. You, as an Ada
programmer, probably know better than I.

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

[Dale Stanbrough]

Dr Amirez wrote:

" Well, C didn't have exceptions for years and probably will never have it.
  That didn't keep it from being one of the most successful languages
  ever created. 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. After all, isn't Ada intended to be a system 
  programming language? You can't program systems using features that 
  are system dependant themselves.
  The more features a language has, the more flaws it has. You, as an Ada
  programmer, probably know better than I".



Ok, let's put your rather simplistic analysis to the test. 

An issue of Communications of the ACM tested a large number of Unix 
utilities (vi was one of them) to the test by feeding them with a stream
of randomly produced characters. A very high proportion of the programs
crashed (core dumped!).

This is from a simple language. Why did this happen? If it is such a
simple language, surely by your logic, any program will be aok?


Lets face reality. A language with more features may be harder to 
implement. There may be some flaws in the definition. But does it mean
that the language can't be used to create reliable code? Certainly the 
opposite (a simple language will always produce good code) isn't true.
What it really means is you have to analyze the features to see if they
help you write better programs. Another recent article in Communications
of the ACM had a discussion about all the terrible things that could
happen in programs (it did a fault analysis of a large number of (C) 
programs). Guess what.. a large number of the _run time_ problems in
these programs would have been _compile time_ problems in Ada.

Your analysis seems to have the depth of someone comparing the space
shuttle to a fireworks rocket...

   "Has rocket motor?" "Check!"
   "Takes off vertically?" "Check!"
   "Is firework rocket cheaper?" "Check!"
   "Firework rocket simpler?" "Check!"
   "Sheesh! why would anyone use a more complex Space shuttle when
    a firework rocket is cleary much more useful!"

You then rather amazingly assert...

"You can't program systems using features that are system dependant themselves"

Once again I will point you at C. In this language the size of an integer
hasn't been defined. This is a system dependent feature. By your definition
you can't program systems with C. 

You had better ring up AT&T and tell them the bad news...

Dale

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

[Dr Amirez]

In article <dale-1110980932270001@dale.ppp.cs.rmit.edu.au> dale@cs.rmit.edu.au (Dale Stanbrough) writes:
>Dr Amirez wrote:
>
>" Well, C didn't have exceptions for years and probably will never have it.
>  That didn't keep it from being one of the most successful languages
>  ever created. 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. After all, isn't Ada intended to be a system 
>  programming language? You can't program systems using features that 
>  are system dependant themselves.
>  The more features a language has, the more flaws it has. You, as an Ada
>  programmer, probably know better than I".
>
>
>
>Ok, let's put your rather simplistic analysis to the test. 
>
>An issue of Communications of the ACM tested a large number of Unix 
>utilities (vi was one of them) to the test by feeding them with a stream
>of randomly produced characters. A very high proportion of the programs
>crashed (core dumped!).
Well, any software needs testing. Much of this is the fault of UNIX
vendors. I understand the bugs got reported times after times but
never got fixed. I can only think of one reason: patching one thing
will only make another problem emerge. That's sad. But then the time
for UNIX has passed, investing into fixing UNIX bugs isn't productive.
Then again, how many times does the ACM get a chance to test an OS
in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but
you never know.
>
>This is from a simple language. Why did this happen? If it is such a
>simple language, surely by your logic, any program will be aok?
>
>
>Lets face reality. A language with more features may be harder to 
>implement. There may be some flaws in the definition. But does it mean
>that the language can't be used to create reliable code? Certainly the 
>opposite (a simple language will always produce good code) isn't true.
>What it really means is you have to analyze the features to see if they
>help you write better programs. Another recent article in Communications
>of the ACM had a discussion about all the terrible things that could
>happen in programs (it did a fault analysis of a large number of (C) 
>programs). Guess what.. a large number of the _run time_ problems in
>these programs would have been _compile time_ problems in Ada.

How about I hate guessing. I will wait for a an Ada OS to come along. 
Linux is (used to be anyway ) a one man project. Surely an OS can't be that
hard to build. Please leave AT&T out of this. They contribute greatly
to the Computer Sci community. Without them I would still be working
on some obscure system written in a mixture of FORTRAN, PL1 and assembly.

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

[Dale Stanbrough]

Dr Amirez wrote:

"Well, any software needs testing. Much of this is the fault of UNIX
 vendors. I understand the bugs got reported times after times but
 never got fixed. I can only think of one reason: patching one thing
 will only make another problem emerge. That's sad. But then the time
 for UNIX has passed, investing into fixing UNIX bugs isn't productive.
 Then again, how many times does the ACM get a chance to test an OS
 in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but
 you never know."


Um, they weren't part of the OS, I was talking about the _Utilities_ such
as vi, cat, etc. that come with it. The article commented on the fact that
these programs had a very long history of no problems, yet were still
vunerable to failure. An Ada program could well have the same faults,
but given the inclusion of array bounds checking, and numerous other
checks these would have either been picked up earlier, or would have
resulted in a constraint_error exception - which I view as being
better than a core dump. At least with a constraint error you can be
reasonably assured that no other data has been corrupted and saved
unwittingly due to a program running on. 

I don't understand why you started talking about OS developement in
Ada. You seem to have a very strange way of making a point. I certainly
don't understand what you are on about.

 
"How about I hate guessing. I will wait for a an Ada OS to come along. 
 Linux is (used to be anyway ) a one man project. Surely an OS can't be that
 hard to build."

Ok you may hate guessing, but what i asked was a rhetorical question, so 
it didn't need an answer.

"Please leave AT&T out of this. They contribute greatly
 to the Computer Sci community. Without them I would still be working
 on some obscure system written in a mixture of FORTRAN, PL1 and assembly."


Maybe they do, but you were the one who claimed that you can't write
system software with facilities that are system dependent, which is
exactly what AT&T have done. I really don't understand what you are
on about, and I suspect that continuing this discussion is just a waste
of time.

Good Bye.

Dale

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

[Dr Amirez]

In article <dale-1110981647250001@dale.ppp.cs.rmit.edu.au> dale@cs.rmit.edu.au (Dale Stanbrough) writes:
>Dr Amirez wrote:
>
>"Well, any software needs testing. Much of this is the fault of UNIX
> vendors. I understand the bugs got reported times after times but
> never got fixed. I can only think of one reason: patching one thing
> will only make another problem emerge. That's sad. But then the time
> for UNIX has passed, investing into fixing UNIX bugs isn't productive.
> Then again, how many times does the ACM get a chance to test an OS
> in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but
> you never know."
>
>
>Um, they weren't part of the OS, I was talking about the _Utilities_ such
>as vi, cat, etc. that come with it. The article commented on the fact that
>these programs had a very long history of no problems, yet were still
>vunerable to failure. An Ada program could well have the same faults,
>but given the inclusion of array bounds checking, and numerous other
>checks these would have either been picked up earlier, or would have
>resulted in a constraint_error exception - which I view as being
>better than a core dump. At least with a constraint error you can be
>reasonably assured that no other data has been corrupted and saved
>unwittingly due to a program running on. 
>
>I don't understand why you started talking about OS developement in
>Ada. You seem to have a very strange way of making a point. I certainly
>don't understand what you are on about.
>
> 
>"How about I hate guessing. I will wait for a an Ada OS to come along. 
> Linux is (used to be anyway ) a one man project. Surely an OS can't be that
> hard to build."
>
>Ok you may hate guessing, but what i asked was a rhetorical question, so 
>it didn't need an answer.
>
>"Please leave AT&T out of this. They contribute greatly
> to the Computer Sci community. Without them I would still be working
> on some obscure system written in a mixture of FORTRAN, PL1 and assembly."
>
>
>Maybe they do, but you were the one who claimed that you can't write
>system software with facilities that are system dependent, which is
>exactly what AT&T have done. I really don't understand what you are
>on about, and I suspect that continuing this discussion is just a waste
>of time.
>
>Good Bye.
>
>Dale

 i would have dropped this. But since I am so bored I might as
 well flame away.
 Well the reason why I brought the Operating systems issue up
 is that it's impossible to write Ada utilities without an
 Ada OS.  But if you could build Ada utilities on UNIX that
 outperform UNIX C utilities then it's fine with me. Make sure
 you ship copies to the ACM.
 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. 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.
 Last, the undefined behaviour of C are pretty well known
 and well documented. It's unlikely that there is an
 undefined behaviour that I don't know about:
 A few examples are:
 i = i++; /* dont do this. You have been warned */
 char *c = "abc"; c[0] = 0; /* don't do this. You have been warnted */
 fflush(stdin); /* Don't do this. You have been warned*/
 The attitude of C towards undefined behavior is "Don't do it"
 period.
 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.
 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?
 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. "
 Dr Amirez

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

[Niklas Holsti]

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

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

[Larry Kilgallen]

In article <6vrlb4$jj$1@jupiter.cs.uml.edu>, dramirez@cs.uml.edu (Dr Amirez) writes:

>  Well the reason why I brought the Operating systems issue up
>  is that it's impossible to write Ada utilities without an
>  Ada OS.  But if you could build Ada utilities on UNIX that
>  outperform UNIX C utilities then it's fine with me. Make sure
>  you ship copies to the ACM.

I can't speak for Unix, but on VMS it is quite possible to write
general purpose utilities in Ada.  The trick is in the bindings
that describe the operating system services to the compiler. This
is no different than for C, Pascal, Fortran, Cobol or any other
language.

>  The core dumping has been a facility on UNIX to assist
>  in debugging .Maybe you don't know enough about UNIX.

Although VMS has a memory dump capability, I find it much more
helpful to run my defective Ada program with the debugger.  Then
when there is a problem where I want to examine variables, the
capability is right there.  My conversations in the past with Unix
people indicate they use the same technique.

There is a class of problems where the program will fail when
run without the debugger but will succeed when the debugger is
present.  In that case, a memory dump may be helpful, but I find
this type of failure much less likely to occur with Ada than with
other languages.

Larry Kilgallen

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

[dennison]

In article <1998Oct12.162441.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <6vrlb4$jj$1@jupiter.cs.uml.edu>, dramirez@cs.uml.edu (Dr Amirez)
writes:
>
> >  Well the reason why I brought the Operating systems issue up
> >  is that it's impossible to write Ada utilities without an
> >  Ada OS.  But if you could build Ada utilities on UNIX that
> >  outperform UNIX C utilities then it's fine with me. Make sure
> >  you ship copies to the ACM.
>
> I can't speak for Unix, but on VMS it is quite possible to write
> general purpose utilities in Ada.  The trick is in the bindings
> that describe the operating system services to the compiler. This
> is no different than for C, Pascal, Fortran, Cobol or any other
> language.

I can. Its quite possible for Unix and Windows NT as well. In fact its often
*easier* to write Unix utilities in Ada, since you typically don't have to
create and keep working one of those gawd-awful Unix makefiles.

--
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, was: Win CE target

[dennison]

In article <6vp23h$hc3$1@jupiter.cs.uml.edu>,
  dramirez@cs.uml.edu (Dr Amirez) wrote:

> Linux is (used to be anyway ) a one man project. Surely an OS can't be that
> hard to build. Please leave AT&T out of this. They contribute greatly

:-))

Oh my! That's a good one!

I wonder if that's what Microsoft managers are telling the Windows NT 5.0 team
right now. :-)

--
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, was: Win CE target

[Larry Kilgallen]

In article <6vtams$gir$1@nnrp1.dejanews.com>, dennison@telepath.com writes:

> I wonder if that's what Microsoft managers are telling the Windows NT 5.0 team
> right now. :-)

The captain wants to water-ski ?

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

[dewarr]

In article <6vp23h$hc3$1@jupiter.cs.uml.edu>,
  dramirez@cs.uml.edu (Dr Amirez) wrote:

> Linux is (used to be anyway ) a one man project. Surely an OS can't be that
> hard to build. Please leave AT&T out of this. They contribute greatly

That's a completely absurd characterization of Linux. The existence of Linux
is the culmination of the work of many people working on many things. Yes,
most certainly the kernel that Linus originally wrote was a critical
component, but an OS is much more than a kernel, and the work of hundreds of
people, perhaps thousands has gone into creating the operating system that we
know as Linux. In particular, the GNU project provided a large set of
critical components, including most importantly the compilers that made the
project possible, as well as many other important utilities.

Robert Dewar

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

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

[Andi Kleen]

dewarr@my-dejanews.com writes:

> In article <6vp23h$hc3$1@jupiter.cs.uml.edu>,
>   dramirez@cs.uml.edu (Dr Amirez) wrote:
> 
> > Linux is (used to be anyway ) a one man project. Surely an OS can't be that
> > hard to build. Please leave AT&T out of this. They contribute greatly
> 
> That's a completely absurd characterization of Linux. The existence of Linux
> is the culmination of the work of many people working on many things. Yes,
> most certainly the kernel that Linus originally wrote was a critical
> component, but an OS is much more than a kernel, and the work of hundreds of
> people, perhaps thousands has gone into creating the operating system that we
> know as Linux. In particular, the GNU project provided a large set of
> critical components, including most importantly the compilers that made the
> project possible, as well as many other important utilities.

Also the Linux kernel is definitely not a one-man project, although it has a
chief architect (Linus Torvalds). It consists of lots of separated
subsystems (kernel core, networking, file systems, isdn, drivers, scsi,
console code, tty subsystem, ...) and has also separated architecture
specific code sections.  All these have their own maintainers or groups of
maintainers with only minor overlap. The largest part of Linux are the
drivers which have all their own maintainer.

Then there are of course lots of other important parts of the systems
which are developed by other people, like XFree86 or the C Library. 

To get back on the topic. Simple OS without advanced features like
networking or virtual memory are not that difficult to build. For an 
example see UCOS. Another smaller OS available in source is vsta (it has
virtual memory and networking, but it still much simpler than Linux) 

These are writen in C, but they probably could be writen in Ada as well. 

-Andi

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

[PC]

Hello,

> How about I hate guessing. I will wait for a an Ada OS to come along. 
> Linux is (used to be anyway ) a one man project. Surely an OS can't be that
> hard to build.

That's actually an interesting proposal... anyone undertaken a OS written
completely in Ada yet?

PC

Operating System in Ada (was Ada --> C Translation)

[Larry Kilgallen]

In article <philip-ya02408000R1210980953070001@news.cs.uwa.edu.au>, philip@cs.uwa.edu.au (PC) writes:
> Hello,
> 
>> How about I hate guessing. I will wait for a an Ada OS to come along. 
>> Linux is (used to be anyway ) a one man project. Surely an OS can't be that
>> hard to build.
> 
> That's actually an interesting proposal... anyone undertaken a OS written
> completely in Ada yet?

The operating system that most people would think about copying first
is Unix -- and that seems like a non-starter from its anti-Ada interfaces
(null-terminated strings and the like).  Yes it is possible to interact,
but it is not in the "spirit" of Ada.

What was the last totally new operating system to achieve prominence ?
I suppose it was MS-DOS or MacOS.  VMS, Unix, VM etc. all seem older.

Larry Kilgallen

Re: Operating System in Ada (was Ada --> C Translation)

[Chris Morgan]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> The operating system that most people would think about copying first
> is Unix -- and that seems like a non-starter from its anti-Ada interfaces
> (null-terminated strings and the like).  Yes it is possible to interact,
> but it is not in the "spirit" of Ada.

I totally disagree with this. My view of Ada strings is that they are
a higher level construct than C style strings. I believe at least some
Ada implementations on top of Unix simply use many of the standard C
library's string functions under the hood. I may be wrong but isn't a
null-terminated string a valid representation of an Ada string?

Chris
-- 
Chris Morgan <mihalis at ix.netcom.com> http://www.netcom.com/~mihalis

Re: Operating System in Ada (was Ada --> C Translation)

[Larry Kilgallen]

In article <87d87xmdkn.fsf@mihalis.ix.netcom.com>, Chris Morgan <mihalis@ix.netcom.com> writes:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>> The operating system that most people would think about copying first
>> is Unix -- and that seems like a non-starter from its anti-Ada interfaces
>> (null-terminated strings and the like).  Yes it is possible to interact,
>> but it is not in the "spirit" of Ada.
> 
> I totally disagree with this. My view of Ada strings is that they are
> a higher level construct than C style strings. I believe at least some
> Ada implementations on top of Unix simply use many of the standard C
> library's string functions under the hood. I may be wrong but isn't a
> null-terminated string a valid representation of an Ada string?

Ada strings allow a null in the middle, without terminating the string.
To the extent that an operating system accepts that, it would behave
quite differently from what a C programmer would expect, and would
not match Unix.  I believe the null termination is defined in the C
standard.

Larry KIlgallen

Re: Operating System in Ada (was Ada --> C Translation)

[Dale Stanbrough]

Chris Morgan wrote:

"I totally disagree with this. My view of Ada strings is that they are
 a higher level construct than C style strings. I believe at least some
 Ada implementations on top of Unix simply use many of the standard C
 library's string functions under the hood. I may be wrong but isn't a
 null-terminated string a valid representation of an Ada string?"


Yes, the Ada string could have an Ascii.Nul at the end of it, so long
as it never appeared in the array. However it still would be of no use
to represent C style strings. For example...

   A : String (1..10);
   Last : Integer;

   Get_Line (A, Last);


If Last is 5, then don't expect a \0 at position 6! (there may be one
at position 11 however).

Dale

Re: Operating System in Ada (was Ada --> C Translation)

[dewarr]

In article <87d87xmdkn.fsf@mihalis.ix.netcom.com>,
  Chris Morgan <mihalis@ix.netcom.com> wrote:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>
> > The operating system that most people would think about copying first
> > is Unix -- and that seems like a non-starter from its anti-Ada interfaces
> > (null-terminated strings and the like).  Yes it is possible to interact,
> > but it is not in the "spirit" of Ada.
>
> I totally disagree with this. My view of Ada strings is that they are
> a higher level construct than C style strings. I believe at least some
> Ada implementations on top of Unix simply use many of the standard C
> library's string functions under the hood. I may be wrong but isn't a
> null-terminated string a valid representation of an Ada string?
>
> Chris


It is conceivable, but it is certainly not a likely representation, since
it does not handle the case of slices without copies. And in any case you
need to store the lower bound, so why not the length as well.

Robert Dewar

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

Re: Operating System in Ada (was Ada --> C Translation)

[Tom Moran]

What constitutes an Operating System?  An embedded kernel?  Does the
Patriot missile have an OS?  If so, is it written in Ada?  If so, does
that count?

Re: Operating System in Ada (was Ada --> C Translation)

[Brian Rogoff]

On Mon, 12 Oct 1998, Tom Moran wrote:
> What constitutes an Operating System?  An embedded kernel?  Does the
> Patriot missile have an OS?  If so, is it written in Ada?  If so, does
> that count?

Darn it, you beat me to the punch!

Some people have mentioned an early version of RTEMS (the Ada version of
RTEMS is deceased now I think) and one called "PULSE" I think. A colleague
at a company I worked at told me that he had written an OS kernel in Ada 83 
while in graduate school without much trouble.

It all depends on what one means by OS. If one means a complete Unix
clone, then no, I don't think one has been written in Ada, and it would be 
silly to do so since Unix users expect C APIs. OTOH, a complete new OS 
functionally similar to Unix/NT/VMS/AS4000/... in Ada would be an
interesting research project. It can obviously be done, since Ada-95
provides all of the capabilities of C, and much more. So, like Dale, I
have no idea what kind of point "Dr Amirez" is trying to make. 

-- Brian

Re: Operating System in Ada (was Ada --> C Translation)

[dennison]

In article <Pine.BSF.4.02A.9810121002380.15516-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> silly to do so since Unix users expect C APIs. OTOH, a complete new OS
> functionally similar to Unix/NT/VMS/AS4000/... in Ada would be an
> interesting research project. It can obviously be done, since Ada-95
> provides all of the capabilities of C, and much more. So, like Dale, I

As a (part-time) C.S. graduate student I suppose I'm in a position to take on
such a project, but I have to say I don't see what the value of it would be.
It might be somewhat interesting to folks here that it had been done. But why
would anyone else care in the slightest?

I picture the conversation going something like this:
Me           : Hey, I just implemented my own Operating System!
Other person : Yeah? What's it do?
Me           : Well....nothing really. But I wrote it in Ada!!
Me:          : Hey. Wait! Where're you going?

For anyone really interested in toying with this, I have two references that
may be handy. "Operating System Design, The XINU Approach" by Douglas Comer
and Timothy Fossum implements and explains (and provides) the code for a
small Unix-like OS that will run on a PC clone. "The Oberon System" by (I
believe) Martin Reiser and Niklaus Wirth goes over the design and code for a
small Object-Oriented OS (and compiler!).

--
T.E.D.

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

Re: Operating System in Ada (was Ada --> C Translation)

[Brian Rogoff]

On Tue, 13 Oct 1998 dennison@telepath.com wrote:
> In article <Pine.BSF.4.02A.9810121002380.15516-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> 
> > silly to do so since Unix users expect C APIs. OTOH, a complete new OS
> > functionally similar to Unix/NT/VMS/AS4000/... in Ada would be an
> > interesting research project. It can obviously be done, since Ada-95
> > provides all of the capabilities of C, and much more. So, like Dale, I
> 
> As a (part-time) C.S. graduate student I suppose I'm in a position to take on
> such a project, but I have to say I don't see what the value of it would be.
> It might be somewhat interesting to folks here that it had been done. But why
> would anyone else care in the slightest?

It would depend of course on what you implemented. I didn't say that if
you just implemented some vanilla OS that the world would suddenly accept
Ada as an obviously superior (to me at least ;-) system implementation
language. 

> I picture the conversation going something like this:
> Me           : Hey, I just implemented my own Operating System!
> Other person : Yeah? What's it do?
> Me           : Well....nothing really. But I wrote it in Ada!!

Well, here is where you have to differentiate what you are planning to
write from what already exists. How about writing a research OS where the 
answer to that question is something, rather than "nothing really", for
some value of something. No one cares if you implement something that
already exists in Ada.

Now the interesting question becomes what that "something" is supposed to
be. Let me suggest Ted that you add EROS to the list of OSes you're
looking at (http://www.cis.upenn.edu/~eros/) as well as its ancestor
KeyKOS (http://www.cis.upenn.edu/~KeyKOS/) and some others like AS400 and 
the defunct GNU Hurd. 

> For anyone really interested in toying with this, I have two references that
> may be handy. "Operating System Design, The XINU Approach" by Douglas Comer
> and Timothy Fossum implements and explains (and provides) the code for a
> small Unix-like OS that will run on a PC clone. "The Oberon System" by (I
> believe) Martin Reiser and Niklaus Wirth goes over the design and code for a
> small Object-Oriented OS (and compiler!).

If you want to do a Unix-like OS, there is no point in exactly duplicating
Unix. Rather, think of some features of Unix OSes which would be better
implemented in Ada 95, like STREAMS, and take it from there. 

-- Brian

Re: Operating System in Ada (was Ada --> C Translation)

[Tucker Taft]

Tom Moran (tmoran@bix.com) wrote:

: What constitutes an Operating System?  An embedded kernel?  Does the
: Patriot missile have an OS?  If so, is it written in Ada?  

Yes, and yes.  (Actually, I don't know anything about the missiles
per se.  I know about the Patriot ground support system, which is the
one that does all the hard work of tracking incoming missiles and choosing
where and when to fire.  That was written in Jovial, but has now been
rewritten in Ada 95.)

: ... If so, does that count?

There are plenty of real-time executives written in Ada (perhaps
too many ;-).  Also, essentially every Ada run-time kernel is written
in Ada, and it has a number of operating-system-like functions.

The big pain in building your own commercial operating system is
keeping up with all the quirks of the hardware which keep evolving, 
like virtual memory systems, serial devices, timers, interrupt controllers, 
network interfaces, graphics subsystems, disk drives, etc., etc., etc.

Even if the Instruction Set Architecture (ISA) is relatively stable,
nothing else is, in the hardware world.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Operating System in Ada (was Ada --> C Translation)

[dennison]

In article <1998Oct12.072036.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

> What was the last totally new operating system to achieve prominence ?
> I suppose it was MS-DOS or MacOS.  VMS, Unix, VM etc. all seem older.

I'd say WindowsNT, but I suppose it all depends on your definition of
"totally new" and "prominence". One could certainly argue against NT based on
its Windows and VMS influences.

Of course, if NT doesn't count, then MS-DOS shouldn't either.

--
T.E.D.

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

Re: Operating System in Ada (was Ada --> C Translation)

[Van Snyder]

In article <1998Oct12.072036.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> In article <philip-ya02408000R1210980953070001@news.cs.uwa.edu.au>, philip@cs.uwa.edu.au (PC) writes:
> > Hello,
> > 
> >> How about I hate guessing. I will wait for a an Ada OS to come along. 
> >> Linux is (used to be anyway ) a one man project. Surely an OS can't be that
> >> hard to build.
> > 
> > That's actually an interesting proposal... anyone undertaken a OS written
> > completely in Ada yet?
> 
> The operating system that most people would think about copying first
> is Unix -- and that seems like a non-starter from its anti-Ada interfaces
> (null-terminated strings and the like).  Yes it is possible to interact,
> but it is not in the "spirit" of Ada.
> 
> What was the last totally new operating system to achieve prominence ?
> I suppose it was MS-DOS or MacOS.  VMS, Unix, VM etc. all seem older.
> 
> Larry Kilgallen

Multics was over 85% written in PL\1, so there's some precedent for writing
an OS in a higher-level language than PDP-11 assembler (also known as C).

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Operating System in Ada (was Ada --> C Translation)

[Tom Moran]

>Multics was over 85% written in PL\1, so there's some precedent for writing
>an OS in a higher-level language than PDP-11 assembler (also known as C).
And the B5500 OS was about 99% in Burroughs Algol.  

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

[Robert I. Eachus]

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.

   I suspect that you misheard.  The correct answer is not that it is
undefined, but that it is not defined unless the implementation
supports the Systems Programming Annex. (In particular, section C.3,
Interrupt Support.)

  But this misses the point.  The real reason it is not defined in the
core standard is that for some purposes, you need to be able to
control things like tasking policies.  The Real-Time Systems annex
allows the programmer to change the task dispatching policy.  Also,
some implementations have different run-time libraries available with
support for different policies.  So the real answer is that, if it
matters and you don't like the standard policy, read annex D, and
choose a policy that you do like.

 > After all, isn't Ada intended to be a system programming language?

    Yes, especially if the System Programming annex is supported. ;-)
(Actually, I suspect that most, if not all compilers try to support
annex C.)

 > You can't program systems using features that are system dependant
 > themselves.

   Huh?  The SP annex has nine implementation-defined characteristics
that are required to be documented.  For the most part they are things
which MUST be implementation dependent, such as what interrupts the
hardware has, or the op-codes for machine instructions.

 > The more features a language has, the more flaws it has. You, as an
 > Ada programmer, probably know better than I.

   No, I don't know that.  I do know that if the language is at least
as powerful as Peano arithmetic, it is either incomplete or
inconsistant.  The Ada community puts lots of effort into being
consistant, but does have well marked doors you can use if you need
completeness.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Samuel Mize]

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

Tasking/blocking system calls (was: Ada --> C Translation)

[Mats Weber]

Samuel Mize wrote:

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

You can't pick one way for all purposes. Some systems need tasking that is
faster or different from kernel threads, while other systems need tasks to be
implemented as kernel threads. See e.g. the GNAT documentation for reasons to
choose between tasking runtimes.

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

... which could also block the whole process. The reason why Text_IO blocked
the whole process in non-kernel-threads tasking implemenetations does not come
from Text_IO itself, but from the underlying machine-specific code used to
implement Text_IO.

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

OK, it was defined, but that is not something you can reasonably enforce on
any system without kernel threads. Implementing this on e.g. SunOS
(pre-Solaris), AIX 3.x or VMS 5.x, would either require the OS to be modified,
or some very unreasonble implementation of tasking, or making all potentially
blocking system calls go through an extra layer.

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

[Tucker Taft]

dewarr@my-dejanews.com wrote:
[...]
> Some of the trouble areas in compiling into C are
> 
>   1. Arithmetic overflow checks, especially in complex
>      expressions, which have to be broken down into steps
>      or written in prefix notation.
> 
>   2. Nested procedures, and particularly nested procedures
>      with complex local declarations.
> 
>   3. Subunits (hard to do anything other than create a huge
>      source in which the subunits are substituted).
> 
>   4. Exceptions
> 
[...]
> I will say for the record, that, according to MY definition
> of readability, it is not possible to translate Ada 95 into
> readable C in all cases.

Stefan Helfert (helfert@galileo.mpi-hd.mpg.de) wrote:

: Clearly this is a statement that you cannot argue with.  

Nevertheless, it is possible to "compile" all of Ada 95 to C, 
which can be useful for using Ada on a target lacking a "full-up"
Ada compiler, and it is possible to "translate" much of Ada 95 to 
reasonably readable C, which can ease certain kinds of reuse, and
can be used to satisfy certain clients' arbitrary requirements for C.

For what that's worth...

As an example of reasonably readable C, I have appended a translation
of a simple priority-heap package, where the automated translator did its 
best to preserve comments, Ada names, etc. in the generated C.  Note that
constraint checks have been suppressed in this translation, to avoid
offending the sensibilities of C programmers ;-).

The original Ada is appended at the end.

: Stefan Helfert

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

----------- prio_heap_pkg.spc.h ---------

#ifndef __prio_heap_pkg_spc_h__
#define __prio_heap_pkg_spc_h__


#include "standard.ada.h"

typedef uint8 Prio_heap_pkg_Prioritynumber;


extern void  Prio_heap_pkg_Add_prio(Prio_heap_pkg_Prioritynumber 
  Prio_To_Add); /* | Add new prio to prio heap */


extern void  Prio_heap_pkg_Remove_top_prio();
  /* | Remove top priority from prio heap */


extern void  Prio_heap_pkg_Print_prio_heap();
  /* | Print all priorities in priority heap, */
/*| in priority order. */

/**
 *| Overview
 *| This package maintains a "binary heap" of priorities
 *| allowing fast access to the highest priority in the heap.
 **/


#endif /* prio_heap_pkg.spc.h */

----------- prio_heap_pkg.bdy.h ---------

#ifndef __prio_heap_pkg_bdy_h__
#define __prio_heap_pkg_bdy_h__


#include "standard.ada.h"

#include "prio_heap_pkg.spc.h"


/**
 *| Overview
 *| This package maintains a "binary heap" of priorities
 *| allowing fast access to the highest priority in the heap.
 **/
#define Prio_heap_pkg__Min_prio ((Prio_heap_pkg_Prioritynumber)(0))
/*| Lowest priority supported. */


#define Prio_heap_pkg__Num_prio ((Universal_integer)(255 - 0+1))
/*| Number of priorities supported */

typedef uint16 Prio_heap_pkg__Prio_heap_count;
/**
 *| type for count of items in prio heap
 *| One extra so may always assume have 2 or 0 children (see
 *| Remove_Prio below).
 **/

typedef Prio_heap_pkg__Prio_heap_count Prio_heap_pkg__Prio_heap_index;
/*| subtype for index into prio heap */


extern uint8 Prio_heap_pkg__Prio_heap[257];
/**
 *| List of priorities which might have non-empty task queue.
 *| This list is organized as a "binary heap" where
 *| Prio_Heap(n/2) > Prio_Heap(n) for n in 2..Num_In_Prio_Heap.
 *| Initialize to Min_Prio to simplify Remove_Prio algorithm.
 **/


extern Prio_heap_pkg__Prio_heap_count Prio_heap_pkg__Num_in_prio_heap;
/*| Count of items in prio heap */


extern Boolean Prio_heap_pkg__In_prio_heap[256];
/*| Indication for each priority whether in prio heap */

/*| Highest priority which might have non-empty queue */



extern void  Prio_heap_pkg__Print_prio_list
  (Prio_heap_pkg__Prio_heap_index Parent);
  /* | Print all priorities in heap */
/*| in priority order, starting at given slot */



#endif /* prio_heap_pkg.bdy.h */

----------- prio_heap_pkg.bdy.c ---------

#include "standard.h"
#include "prio_heap_pkg.bdy.h"


/**
 *| Overview
 *| This package maintains a "binary heap" of priorities
 *| allowing fast access to the highest priority in the heap.
 **/
uint8 Prio_heap_pkg__Prio_heap[257] = {(uint8 )(int32 )
  Prio_heap_pkg__Min_prio, (uint8 )(int32 )Prio_heap_pkg__Min_prio, (
  uint8 )(int32 )Prio_heap_pkg__Min_prio, ... 
 
 [... elided lots of repeats ...]

  Prio_heap_pkg__Min_prio, (uint8 )(int32 )Prio_heap_pkg__Min_prio};
/**
 *| List of priorities which might have non-empty task queue.
 *| This list is organized as a "binary heap" where
 *| Prio_Heap(n/2) > Prio_Heap(n) for n in 2..Num_In_Prio_Heap.
 *| Initialize to Min_Prio to simplify Remove_Prio algorithm.
 **/

Prio_heap_pkg__Prio_heap_count Prio_heap_pkg__Num_in_prio_heap = {0};
/*| Count of items in prio heap */

Boolean Prio_heap_pkg__In_prio_heap[256] = {False, False, False, False, 
  False, False, False, False, False, False, False, False, False, False, 

 [... elided lots of repeats ...]

  False, False, False, False, False, False, False, False, False, False, 
  False, False};
/*| Indication for each priority whether in prio heap */

/*| Highest priority which might have non-empty queue */

void  Prio_heap_pkg_Add_prio(
    /*| Add new prio to prio heap */
    Prio_heap_pkg_Prioritynumber Prio_to_add
)
{
    /**
     *| Algorithm
     *| Add new prio to end of heap, then "sift" it up,
     *| until binary heap condition is restored
     *| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1))
     **/

    Prio_heap_pkg__Prio_heap_index Parent;
    Prio_heap_pkg__Prio_heap_index Child;




    Prio_heap_pkg__Num_in_prio_heap = (uint16 )((int32 )
      Prio_heap_pkg__Num_in_prio_heap+1);

    /* Start at end of heap */
    Child = (uint16 )(int32 )Prio_heap_pkg__Num_in_prio_heap;

    /* Loop until reach top of heap, or parent greater than new prio */
    while ((int32 )Child > 1) {
        Parent = (uint16 )((int32 )Child/2);
          /*  Find slot which should be greater */
        if ((int32 )Prio_heap_pkg__Prio_heap[(int32 )Parent - 1] >= (
          int32 )Prio_to_add) {
            goto loop_label__1;
        }
        /* All done if Parent is already greater */

        /* Parent smaller, move it down to child's slot */
        Prio_heap_pkg__Prio_heap[(int32 )Child - 1] = (uint8 )(int32 )
          Prio_heap_pkg__Prio_heap[(int32 )Parent - 1];

        /* Advance up to parent slot and iterate */
        Child = (uint16 )(int32 )Parent;
    }
    loop_label__1:;

    /*| ASSERT: Prio_To_Add < Prio_Heap(Child/2) or top-of-heap */
    Prio_heap_pkg__Prio_heap[(int32 )Child - 1] = (uint8 )(int32 )
      Prio_to_add;


}


void  Prio_heap_pkg_Remove_top_prio(void)
  /* | Remove top priority from prio heap */
{
    /**
     *| Algorithm
     *| Move bottom of heap to top of heap, and then "sift" it down
     *| until binary heap condition is restored
     *| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1))
     **/

    Prio_heap_pkg_Prioritynumber Prio_to_move;
    /*| Priority to sift down */

    Prio_heap_pkg__Prio_heap_index Parent;
    /*| Child = higher-prio-of (2*Parent, 2*Parent+1) */

    Prio_heap_pkg__Prio_heap_index Child;
    Prio_heap_pkg__Prio_heap_count Parent_limit;
    /*| Last parent with any children */



    Prio_to_move = (uint8 )(int32 )Prio_heap_pkg__Prio_heap[(int32 )
      Prio_heap_pkg__Num_in_prio_heap - 1];

    /**
     * Ensure that empty slots have min prio
     *  This allows us to ignore special case when parent has
     * exactly one child, since missing child will appear to have
     * minimum priority.
     **/
    Prio_heap_pkg__Prio_heap[(int32 )Prio_heap_pkg__Num_in_prio_heap
      - 1] = (uint8 )(int32 )Prio_heap_pkg__Min_prio;

    /* Shorten the heap */
    Prio_heap_pkg__Num_in_prio_heap = (uint16 )((int32 )
      Prio_heap_pkg__Num_in_prio_heap - 1);

    if ((int32 )Prio_heap_pkg__Num_in_prio_heap == 0) {

        /* All done if heap now empty */
        return ;
    }

    /* Start at top of heap */
    Parent = 1;

    /**
     * Calculate limit on parent
     * (do this to avoid overflow in child calculation)
     **/
    Parent_limit = (uint16 )((int32 )Prio_heap_pkg__Num_in_prio_heap/2);

    /* Loop until reach bottom of heap, or prio-to-mv > both children */
    while ((int32 )Parent <= (int32 )Parent_limit) {

        /* Determine larger "child" */
        Child = (uint16 )((int32 )Parent*2);
        if ((int32 )Prio_heap_pkg__Prio_heap[(int32 )Child+1 - 1] > (
          int32 )Prio_heap_pkg__Prio_heap[(int32 )Child - 1]) {
            /* 2n+1 child is greater than 2n child */
            Child = (uint16 )((int32 )Child+1);
        }

        if ((int32 )Prio_to_move >= (int32 )Prio_heap_pkg__Prio_heap[(
          int32 )Child - 1]) {
            goto loop_label__2;
        }
        /* All done when slot found for prio being moved */

        /* Move larger child up, and iterate with child's slot */
        Prio_heap_pkg__Prio_heap[(int32 )Parent - 1] = (uint8 )(int32 )
          Prio_heap_pkg__Prio_heap[(int32 )Child - 1];
        Parent = (uint16 )(int32 )Child;
    }
    loop_label__2:;

    /**
     * ASSERT: Prio_To_Move > both children (2*Parent,2*Parent+1)
     *         or slot has no children
     **/

    /* Put prio in its new slot */
    Prio_heap_pkg__Prio_heap[(int32 )Parent - 1] = (uint8 )(int32 )
      Prio_to_move;


}
void  rts_ss_mark(Root_address );
Character *  rts_integer_image(int32*,
    Integer );

#include "ada.text_io.spc.h"
void  rts_ss_release(Root_address );

void  Prio_heap_pkg__Print_prio_list(
    Prio_heap_pkg__Prio_heap_index Parent
)
{

    Prio_heap_pkg__Prio_heap_index Child;
    uint8 *pointer__3;
    int32 dyn_temp__4[2];
    Character *pointer__5;

    if ((int32 )Parent <= (int32 )Prio_heap_pkg__Num_in_prio_heap) {
        rts_ss_mark((uint8 *)&pointer__3);
        pointer__5 = rts_integer_image(dyn_temp__4,(int32 )
          Prio_heap_pkg__Prio_heap[(int32 )Parent - 1]);

        Ada_Text_io_Put_line__2((Character *)pointer__5,dyn_temp__4);
        rts_ss_release((uint8 *)&pointer__3);

        if ((int32 )Parent <= (int32 )Prio_heap_pkg__Num_in_prio_heap/2
          ) {

            Child = (uint16 )(2*(int32 )Parent);
            if ((int32 )Prio_heap_pkg__Prio_heap[(int32 )Child+1 - 1]
              > (int32 )Prio_heap_pkg__Prio_heap[(int32 )Child - 1]) {

                Prio_heap_pkg__Print_prio_list((uint16 )((int32 )Child+1));
                Prio_heap_pkg__Print_prio_list((uint16 )(int32 )Child);
            } else {

                Prio_heap_pkg__Print_prio_list((uint16 )(int32 )Child);
                Prio_heap_pkg__Print_prio_list((uint16 )((int32 )Child+1));
            }
        }
    }
}


void  Prio_heap_pkg_Print_prio_heap(void)
{
    Prio_heap_pkg__Print_prio_list(1);
}
----------- prio_heap_pkg.spc ---------
pragma Suppress(All_Checks);
package Prio_Heap_Pkg is
    --| Overview
    --| This package maintains a "binary heap" of priorities
    --| allowing fast access to the highest priority in the heap.

    subtype PriorityNumber is Integer range 0..255;
    
    procedure Add_Prio ( --| Add new prio to prio heap
      Prio_To_Add : PriorityNumber
    );
    
    procedure Remove_Top_Prio;  --| Remove top priority from prio heap
    
    procedure Print_Prio_Heap;  --| Print all priorities in priority heap,
				--| in priority order.
end Prio_Heap_Pkg;
----------- prio_heap_pkg.bdy ---------
with Ada.Text_IO;
package body Prio_Heap_Pkg is  --| Maintain priority heap
  
    --| Overview
    --| This package maintains a "binary heap" of priorities
    --| allowing fast access to the highest priority in the heap.
    
    
    Min_Prio : constant PriorityNumber := PriorityNumber'First;
      --| Lowest priority supported.
    
    Num_Prio : constant :=
      PriorityNumber'Pos(PriorityNumber'Last) -
       PriorityNumber'Pos(PriorityNumber'First) + 1;
      --| Number of priorities supported
      
    type Prio_Heap_Count is range 0 .. Num_Prio + 1;
      --| type for count of items in prio heap
      --| One extra so may always assume have 2 or 0 children (see
      --| Remove_Prio below).
      
    subtype Prio_Heap_Index is Prio_Heap_Count
      range 1 .. Prio_Heap_Count'Last;
      --| subtype for index into prio heap
    
    Prio_Heap : array(Prio_Heap_Index) of PriorityNumber :=
      (others => Min_Prio);
      --| List of priorities which might have non-empty task queue.
      --| This list is organized as a "binary heap" where
      --| Prio_Heap(n/2) > Prio_Heap(n) for n in 2..Num_In_Prio_Heap.
      --| Initialize to Min_Prio to simplify Remove_Prio algorithm.
      
    Num_In_Prio_Heap : Prio_Heap_Count := 0;
      --| Count of items in prio heap
      
    In_Prio_Heap : array(PriorityNumber) of Boolean :=
      (others => False);
        --| Indication for each priority whether in prio heap
      
    Top_Prio_In_Heap : PriorityNumber renames Prio_Heap(Prio_Heap'First);
      --| Highest priority which might have non-empty queue
    
    procedure Add_Prio ( --| Add new prio to prio heap
      Prio_To_Add : PriorityNumber
    ) is
	--| Algorithm
	--| Add new prio to end of heap, then "sift" it up,
	--| until binary heap condition is restored
	--| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1))
	
	Parent, Child : Prio_Heap_Index;
    begin
	Num_In_Prio_Heap := Num_In_Prio_Heap + 1;
	
	-- Start at end of heap
	Child := Num_In_Prio_Heap;
	
	-- Loop until reach top of heap, or parent greater than new prio
	while Child > 1 loop
	    Parent := Child/2;  -- Find slot which should be greater
	    exit when Prio_Heap(Parent) >= Prio_To_Add;
	      -- All done if Parent is already greater
	      
	    -- Parent smaller, move it down to child's slot
	    Prio_Heap(Child) := Prio_Heap(Parent);
	    
	    -- Advance up to parent slot and iterate
	    Child := Parent;
	end loop;
	
	--| ASSERT: Prio_To_Add < Prio_Heap(Child/2) or top-of-heap
	Prio_Heap(Child) := Prio_To_Add;
	
    end Add_Prio;
    
    procedure Remove_Top_Prio   --| Remove top priority from prio heap
    is
	--| Algorithm
	--| Move bottom of heap to top of heap, and then "sift" it down
	--| until binary heap condition is restored
	--| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1))
	
	Prio_To_Move : constant PriorityNumber :=
	  Prio_Heap(Num_In_Prio_Heap);
	  --| Priority to sift down
	  
	Parent, Child : Prio_Heap_Index;
	  --| Child = higher-prio-of (2*Parent, 2*Parent+1)
	  
	Parent_Limit : Prio_Heap_Count;
	  --| Last parent with any children
    begin
	-- Ensure that empty slots have min prio
	--  This allows us to ignore special case when parent has
	-- exactly one child, since missing child will appear to have
	-- minimum priority.
	Prio_Heap(Num_In_Prio_Heap) := Min_Prio;
	
	-- Shorten the heap
	Num_In_Prio_Heap := Num_In_Prio_Heap - 1;
	
	if Num_In_Prio_Heap = 0 then
	    
	    -- All done if heap now empty
	    return;
	
	end if;
	
	-- Start at top of heap
	Parent := 1;
	
	-- Calculate limit on parent
	-- (do this to avoid overflow in child calculation)
	Parent_Limit := Num_In_Prio_Heap / 2;

	-- Loop until reach bottom of heap, or prio-to-mv > both children
	while Parent <= Parent_Limit loop
	    
	    -- Determine larger "child"
	    Child := Parent * 2;
	    if Prio_Heap(Child + 1) > Prio_Heap(Child) then
		-- 2n+1 child is greater than 2n child
		Child := Child + 1;
	    end if;
	    
	    exit when Prio_To_Move >= Prio_Heap(Child);
	      -- All done when slot found for prio being moved
	      
	    -- Move larger child up, and iterate with child's slot
	    Prio_Heap(Parent) := Prio_Heap(Child);
	    Parent := Child;
	end loop;
	
	-- ASSERT: Prio_To_Move > both children (2*Parent,2*Parent+1)
	--         or slot has no children
	
	-- Put prio in its new slot
	Prio_Heap(Parent) := Prio_To_Move;
	
    end Remove_Top_Prio;
	
    procedure Print_Prio_List(  --| Print all priorities in heap
                                --| in priority order, starting at given slot
      Parent : Prio_Heap_Index
    ) is
	--| Algorithm
	--| Print prio at given slot in heap,
	--| Then recurse with children, higher prio first.
	
	Child : Prio_Heap_Index;
    begin
	if Parent <= Num_In_Prio_Heap then
	    -- Print priority
	    Ada.Text_IO.Put_Line(Integer'Image(Prio_Heap(Parent)));
	    
	    if Parent <= Num_In_Prio_Heap/2 then
		-- Parent has children, recurse on children in order
		Child := 2 * Parent;
		if Prio_Heap(Child+1) > Prio_Heap(Child) then
		    -- Second child is higher prio
		    Print_Prio_List(Child+1);
		    Print_Prio_List(Child);
		else
		    -- First child is higher prio
		    Print_Prio_List(Child);
		    Print_Prio_List(Child+1);
		end if;
	    end if;
	end if;
    end Print_Prio_List;
 
    procedure Print_Prio_Heap is  --| Print all priorities in priority heap,
				  --| in priority order.
    begin
	-- Just pass the buck to the recursive routine
	Print_Prio_List(Prio_Heap_Index'First);
    end Print_Prio_Heap;

 ----------------------------------------------------------------------
 end Prio_Heap_Pkg;
 ----------------------------------------------------------------------

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

[dewarr]

In article <F01sL5.5Ey.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> As an example of reasonably readable C, I have appended a translation
> of a simple priority-heap package, where the automated translator did its
> best to preserve comments, Ada names, etc. in the generated C.  Note that
> constraint checks have been suppressed in this translation, to avoid
> offending the sensibilities of C programmers ;-).

It is not only the sensibilities of C programmers that would be offended
by putting in full constraint checking, but this would also impact the
readability considerably I suspect.

It is certainly the case that some subset of Ada can be represented as
readable C, especially if constraint checking is suppressed, my comments
were responding to the suggestion that the whole of Ada can be translated
to meet this criterion, and it is no suprise to me that Tuck agrees with
this assessment (all of Ada can be translated to C, but only a subset
will be readable). This is actually a well known result, at least two
previous commercial Ada compilers have operated by generating C, with
similar results.

By the way, efficiency and readability can definitely be at odds. From
experiments done in one case, it appears that the use of setjmp and
longjmp is generally less efficient than providing an extra parameter
on every call. This is most certainly true on the SPARC, where the
standard setjmp uses a kernel call -- this is by the way total incompetence,
there is no requirement for this approach, and if you are translating Ada
to GNU-C, you will find it far better to use the builtin setjmp and longjmp
functions of this compiler.

One place where the generated C will get very far from readable is packed
arrays. This important feature is completely missing from C. Perhaps you
can partly deal with it by macros, but only partly! Have a look at the
-gnatdg output from GNAT to get an idea of what has to be generated (this
is one thing that is currently handled by the front end of GNAT rather
than the backend).

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Win CE target

[falis]

I've already been able to run ObjectAda for Windows 
executables on the Win-CE x86 simulator (which seems to be of 
little practical use, since there don't appear to be any real x86 
devices running ce).

Using the win-ce sdk, link the OA object modules with 
subsystem=<some magic win ce type>.  The main has to be a 
winmain.

Sorry about the missing details - did this a few months back.

- Ed