Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Loren@cup.portal.com (Loren Louis Hart)]

In an article posted by barmar@think.com on this topic
>In article <5476@crdgw1.crd.ge.com> oconnordm@CRD.GE.COM (Dennis M. O'Connor) 
w
>rites:
>>mike@cs (Mike Coffin) writes:
>>] but the operating system itself is optimized for running C programs.
>>If we allow that UNIX is optimized for anything ;-), just what
>>are these C-specific optimizations that favor C and C++ over Ada ?
>
>The most obvious way in which a particular OS is oriented towards a
>particular language is when it comes to data being passed between
>application programs and OS routines.  Unix kernel routines and system
>library routines expect things like null-terminated strings and structures
>laid out the way that system's C compiler lays them.  Programs written in
>other languages often need to transform data when passing it into and out
>of the OS.

I would say that things like null terminators and other system representations
are implementation issues of the compiler, particularly with respect to Ada.
Having written the Unix system interface for an Ada database, I would have
to say that the Verdix compiler's implementation is superior.  Ada allows for
the implementation to deal with terminating strings and other such platform
specific issues.  I found that the Verdix Ada compiler provided all the 
necessary capabilites to write an effective, reliable, and efficient Unix
Interface.

>Another area of language bias is documentation.  Unix manual pages for
>subroutines generally describe the invocation mechanism and argument types
>in C syntax.

In our case it was helpful to know some C to write the OS interface; however
since our project, Verdix has written and provided the text of the Ada package
specifications for many of the unix system calls.  I often find these Ada
package specifications clearer than the unix manuals on issues of types and
parameter passing mechanisms.

>Ada representation clauses may be useful for solving some parts of the
>first problem, but such programs are not portable.  Further, the manual
>pages are written portably, so they don't describe argument representation.
>In order to write the rep spec for a structure being passed to a system
>routine you would have to go through the C compiler documentation and find
>out how it lays out structures (hopefully this is documented).

>These problems aren't as bad so long as programs stick to OS-independent
>libraries, such as stdio for C and the standard packages that Ada provides.
>However, the data transformation overhead is still there, buried inside the
>library implementation.

Again, given the right choice of compiler in a given instance, what little
data transformation overhead is negligable by comparison to the inherent cost
of a system call.

>>Sorry, I disagree. Operating systems provide a "virtual machine"
>>for the applications programs to execute on; compilers provide
>>a "virtual machine" for the programmer to write programs for.

>But there's opportunities to optimize when the two virtual machines have
>similarities.  For instance, both the Unix VM and the C VM share the same
>string abstraction, so it is never necessary to convert C strings to Unix
>strings.

Again with the Verdix implementatio, their strings are null terminated and
there is never a need to convert them.

>>An operating system that is only able to efficiently support one
>>language or one family of languages is an inadequate operating system :

>Unfortunately, many OSes are inadequate.  The Mac OS is Pascal-oriented,
>Unix is C-oriented, Genera (the OS on Symbolics Lisp Machines) is
>Lisp-oriented, Multics is PL/I-oriented, etc.

Again I argue that a proper implementation of an Ada compiler should be in 
line with the platform it runs on.  A platform for a compiler includes not only
the particular CPU, but the OS as well.  I will admit that there are some
special purpose operating systems that make these kinds of adaptations next
to impossible, but I would not put Unix into this category!
--
Loren L. Hart
loren@cup.portal.com
San Jose, California