Re: Language runtime requirements (was Re: DoD

Re: Language runtime requirements (was Re: DoD

[David Tannen]

[stuff deleted]

>Ada has a problem with running well on UNIX systems, partially because
>its tasking model doesn't match that of UNIX.  

Not always so.  I am currently working w/ a Verdix compiler and I believe
that all the Ada tasks (200 in the system I am working on) are "mapped"
to Unix processes.  The compiler takes care of all the implementation 
details - I just write Ada code.

I also worked w/ a DDCI compiler for a bare-bones 80286 system that took
advantage of the environment to make task switching very fast.  Sort of
"mapped" Ada tasks to x286 virtual machines (I may be wrong about my
explaination on this one - its been a while.  But task switching was
very fast.)

>The IEEE POSIX standards
>efforts have tried to resolve that somewhat.  It would not surprise me
>if some aspects of Ada cannot run WELL on Windows NT, for similar
>reasons.  Any language that assumes its runtime has control of the
>environment will have problems.

The Alsys compilers I have worked w/ seem to make the assumption that
their runtime is in charge no matter what the OS is.  There are advantages
and disadvantages to this.  I would think that one advantage is that
if the application is ported to another HW/OS environment you would get 
task processing would be "similiar" between the two environments.  Of 
course it doesn't take advantage of whatever "tasking" support may come
w/ the environment.

>Since Ada makes so many such
>assumptions (tasking, exception control, file control, etc.) it must
>have problems.  This makes Ada more than a programming language.  It is
>also an operating system requirements specification.

>So the question really isn't if you can write a program in Ada that
>will execute in a Windows NT environment.  You can pretty much write
>ANY program in ANY language that will run in ANY environment, with
>enough effort.  The real question is whether you you can build a system
>in Ada that effectively runs in a Windows NT environment without using
>a much effort tailoring it to that environment.  

Actually I think the real ? will be if any vendors "map" Ada tasks to
NT's thread mechanism.  If they do this could be a great advantage for
programming NT applications in Ada.  Of course someone needs to provide
GUI interface tools, and a library of components like Borlands OWL or
Microsofts library support.

Any vendors out in net land want to comment?  Any of you folks going to
compete head-to-head w/ Microsoft/Borland for the NT market?  Or have
you all already given up on that market too?  (I already got burned 
waiting for Alsys to deliver a promised compiler for MS-Windows 3.1.
And I won't ever use a Meridian compiler again - if I can help it.)

(IMHO [honest, haven't been humble for a long time])


---
David Tannen
tannend@source.asset.com
tannen@tigger.geg.mot.com
----------------------------------------------------------------------
-- "Dependance on wizardry to mitigate the fundamental limitations
--  of software is called 'hacking'."  Grady Booch.
--
-- Developing MS-Windows applications often requires 'wizardry'.
----------------------------------------------------------------------

Re: Language runtime requirements (was Re: DoD

[magnesium.club.cc.cmu.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!falis]

As for our LynxOS, MVS, Solaris, HP-RT and OS/2 products, the Windows-NT
Ada compiler will map Ada tasks onto OS threads.  For OS' that don't
provide lightweight processes, we generally map all tasks into a single
process.  For embedded-oriented products, tasks are basically a register
set, control block and some workspace.

So, while I agree with the comment that the Alsys runtime does assume it's
the "main", I can't agree with the conclusion that we ignore the OS under-
lying capabilities.  The runtime comprises multiple virtual machine layers
that are mapped onto a bottom layer of services that we judge to be
most effective for a given operating environment.

The NT compiler will be on display at our booth at Tri-Ada.

- Ed Falis, Alsys

Re: Language runtime requirements (was Re: DoD

[Dave Bashford]

In article ... falis@ajpo.sei.cmu.edu (Edward Falis) writes:
>
>As for our LynxOS, MVS, Solaris, HP-RT and OS/2 products, the Windows-NT
>Ada compiler will map Ada tasks onto OS threads.  For OS' that don't
>provide lightweight processes, we generally map all tasks into a single
>process.  For embedded-oriented products, tasks are basically a register
>set, control block and some workspace.
>
>So, while I agree with the comment that the Alsys runtime does assume it's
>the "main", I can't agree with the conclusion that we ignore the OS under-
>lying capabilities.  The runtime comprises multiple virtual machine layers
>that are mapped onto a bottom layer of services that we judge to be
>most effective for a given operating environment.
>
...
>- Ed Falis, Alsys

So, why the problem with Unix ?  I've heard excuses like "it would be too
inefficient."  But Unix/C has been using multi-tasking well for years.
Besides, I'd take inefficient over useless any day.
-- 

db
bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)

Re: Language runtime requirements (was Re: DoD

[Mark Atwood]

In article <1993Aug12.224346.20541@scf.loral.com> bashford@srs.loral.com (Dave 
Bashford) writes:
>In article ... falis@ajpo.sei.cmu.edu (Edward Falis) writes:
>>...  For OS' that don't
>>provide lightweight processes, we generally map all tasks into a single
>>process.  ...
>
>So, why the problem with Unix ?  I've heard excuses like "it would be too
>inefficient."  But Unix/C has been using multi-tasking well for years.
>Besides, I'd take inefficient over useless any day.

I've used Alsys Ada on HPUX at work, and used a preemptive cthreads
on BSD at school for an OS class.  The problem I see with mapping Ada
tasks on UNIX processes is that UNIX processes are too independent.
Once a process starts, it doesn't share memory and doesn't have any
sync points with the parent that forked it until it exits.  Admittadly
it COULD be done using pipes and/or OS supplied shared memory or sync
resources, but it would be a major design pain.

Threads are a model of multiple tasks that are closely related.
Processes are a model of multiple virtual processors.

You could use one of the several Ada socket or distributed processing
packages to build a multi-process Ada system, but I don't think
tasks map to processes very well




-- 
Mark Atwood                  | My school and employer have too many problems
matwood@peruvian.cs.utah.edu | without being blamed for mine.

Re: Language runtime requirements (was Re: DoD

[Mike Bates]

VAXELN, DEC's "real-time" OS for VAXen, does a nice job of mapping Ada
tasks to the OS; perhaps it's more accurate to say that the OS's
structure coincides neatly with Ada's requirements.  An Ada program
corresponds to a VAXELN job.  Tasks map to processes within the job;
the main task corresponds to the master process.  Scheduling is
preemptive, based on job priority, then on priority of processes
within the active job.

VAXELN Ada has a very useful, "thick" binding for system calls -- I
imagine it helps that VAXELN is written in a variant of Pascal.  The X
and Motif bindings were fairly easy to work with as well.  (X and
Motif themselves weren't so easy...)

We had a few problems with the environment -- device drivers were
written for transaction-processing "real-time," not for hard
real-time.  With the Pascal source for their drivers and some
assistance from DEC's customer support, we were able to write the
drivers we needed in Ada.  The other big problem is that VAXELN's
user community is relatively small; we uncovered several previously
undiscovered bugs in the Motif library and in the user shell.  It's a
strange feeling when the customer support engineer says, "We've never
known anyone to try that before."





-- 
------------------------------------------------------------------------------
Mike Bates               FlightSafety International, Simulation Systems Div.
Principal Engineer       2700 North Hemlock Circle
Computer Systems Group   Broken Arrow, Oklahoma 74012
mikeb@ssd.fsi.com        918-251-0500 ext. 581

Re: Language runtime requirements (was Re: DoD

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!falis]

In regard to Dave Bashford's question: "So, what's the problem with
UNIX", I'll make the following observations / HO's:

Solaris, HP-RT, LynxOS are effectively UNIX or UNIX variants.  The difference
from traditional UNIX implementations ispport for threads or lightweight
processes.  This s a key issue for mapping Ada tasking over the operating
system schedulable entities.

For starts, UNIX process switching times are quite large, because such a
process has much more context associated with it (including a separate
address space) than an Ada task does.  In view of the complaints of
the user comunity about Ada context switch and rendezvous times bac 

when these design deision were made, it  did not seem sensible to add
this overhead to operatons that were already on the heavy side.  Given
that Ada tasks can potentially share address spaces, there are additional
overheads incurred to map shareable address spaces among multiple UNI|
processes.  Both of these problems are solved by threads, since they're
defined within the shared address space of the process corresponding to
the Ada mai subprogram, and threads have much less context associated
with them than processes.  

The upside of using threads or processes for Ada tasks is that the
tasks are scheduled by the OS, so that blocking operations allow
other parts of the application to proceed.  So in light of these
considerations, threads are almost ideal.

What we wound up having to do with the approach of mapping all Ada
tasks into a single process, was to provide ways of having blocking
operations inform the Ada scheduler to switch to another task.
Initially, this was done for standard I/O operations, and Kludges
were made available on some platforms to fork off a child process
for system calls and calls to other languages that might block.
Very ugly, and it still didn't address issues like priorities
across multiple applications.

Hope this gives a little perspective on where we were coming from.

- Ed Falis, Alsys

Re: Language runtime requirements (was Re: DoD

[David Emery]

>But Unix/C has been using multi-tasking well for years.

Huh?  Unix systems run multiple processes, but these processes are
very heavyweight.  In particular, each Unix process has its own
address space.  This does NOT match the Ada model, where tasks can
share address space (e.g. two tasks using a common package.)  

The Unix community has been talking about true multitasking, e.g.
"threads" in Unix-speak, for several years now, and the POSIX 1003.4a
standard is still in ballot.  Part of the problem is getting a full
understanding of the effects of multitasking on C, and another part of
the problem is understanding the effects of multitasking on things
like the traditional POSIX.1 interface.

Some C programmers have been using threads packages for a while, but
not with anywhere near the semantic precision of Ada nor the
portability of Ada.

				dave

Re: Language runtime requirements (was Re: DoD

[agate!howland.reston.ans.net!spool.mu.edu!sgiblab!sgigate!sgi!fido.asd.sg]

While I'll probably get flamed for this...

SGI and VERDIX jointly developed an Ada compiler that ties tasks to POSIX compl
iant 
threads. It's been available since March, 1993 commercially.

"MP/Ada - Ada as it was meant to be!"

Dave McAllister



-- 
*SHINDO - the ART of the MIND*

*Fortune for the day*

Re: Language runtime requirements (was Re: DoD

[David Emery]

>SGI and VERDIX jointly developed an Ada compiler that ties tasks to
>POSIX compliant threads. It's been available since March, 1993
>commercially.

There is no such thing as "POSIX compliant threads".  The POSIX
threads standard (P1003.4a) is still in ballot, so there's no standard
to conform to.  

Presumably SGI is supporting one of the drafts of P1003.4a.  Which
one?  How much has the standard changed since this draft?  

				dave