HDTenEightyP/NetNews huggingface dataset:
From: wittbj@nextnet.ccs.csus.edu (brian witt)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 17 Apr 92 01:50:27 GMT
Organization: California State University: Sacramento, USA
Originator: osr@ftp

RISC is quite wonderful. Discussion of RISC to comp.arch, please...

In article <32804@darkstar.ucsc.edu> emery@Dr_No.mitre.org (David Emery) writes:
>Incidentally, does everyone agree with the following:
>	0.  Operating Systems are best implemented in high-level
>	    languages.  
>If so, does this argue for the use of higher-level languages in
>contemporary O.S. implementations?  Is C (which has mediocre support
>for data abstraction and/or object orientation) too low level?  

C could be too low level, I vote for Eifffel, Hermes, Argus on language issue.

In "Reduced Instrction Set Computer Architectures for VLSI", by Manolis
G. H. Katevenis, page 74-77 there is an interesting chart about the
performance of routines in C and assembler for some popular processors.
Normalizing the exection time to his RISC II processor, he found
assembler for RISC was 90% of "C" code performance!  Not much too
much gain for the pain.

A Chart of numbers follows (from page 77):
                    C Code Perf      Assem Code Perf
RISC II (T=500nS)       1.0 (normalized)  0.9
VAX 11/780              2.1               0.9
M68000                  2.8               0.7
Z80002                  3.5               1.4
PDP 11/70               2.7               1.2

Conclusion: 
 1)  RISC II compiler code is *very* close to tight assembler code.
 2)  If you must write in assembler, use a M68000.
 3)  Compilers in 1982 aren't too smart....

Therefore, use a RISC chip and a High Level Language.
There are software engineering issues that can also be argued.  These
involve the analysis, design, and implementation language...
Software maintaince is troublesome on assembler code.

>				dave

--- "Why don't you just 'grep' for it?"
--- brian

-- 
======================================================================== !
   Brian Witt     [Sac State Comp Science]   "Waldo, the pariot, is dead"
   Internet:  wittbj@cube01.ccs.csus.edu               -- Agent Cooper
                  #define  POSIX_ME_HARDER     1      <-- GNU
From: samsung!ulowell!cps.msu.edu!nupairoj@uunet.UU.NET (Natawut Nupairoj)
Newsgroups: comp.os.research
Subject: need papers about Real-Time OS Scheduling
Date: 16 Apr 92 16:25:36 GMT
Organization: Dept. of Computer Science, Michigan State University

I am doing a research about Real-Time OS Scheduling.  I still cannot find
good references on this topic.  Perhaps, someone may be able to tell me
some good ones.

Thanks in advance,
Natawut Nupairoj.

nupairoj@cps.msu.edu
From: johnm@cory.berkeley.edu (John D. Mitchell)
Newsgroups: comp.os.research
Subject: PenPoint (was Re: A challenge (response) (response))
Date: 14 Apr 92 00:19:08 GMT
Organization: University of California, at Berkeley
Originator: osr@ftp

In article <32795@darkstar.ucsc.edu> mday@jukebox.lcs.mit.edu (Mark Day)
writes: 
>   bellcore!gizmo.bellcore.com!mo@uunet.UU.NET (Michael O'Dell) writes:
>   Penpoint - one of the most interesting pieces of OS work
>   I've seen in a long time.
>I second this opinion.  I recommend the book (The Power of PenPoint) to
>anyone interested in seeing a new perspective on operating systems.

Would either of you or anyone else like to voice some specifiics as to why
PenPoint is so interesting?

Thanks,
	John D. Mitchell
	johnm@cory.Berkeley.EDU
Newsgroups: comp.os.research
From: morin@irisa.fr (Christine Morin)
Subject: FINAL CFP : 5th ACM SIGOPS European Workshop
Organization: IRISA, Rennes (Fr)
Date: Thu, 16 Apr 1992 07:17:00 GMT


			*** FINAL CALL FOR PAPERS ***


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remember that the deadline for SENDING your position paper is tomorrow April
17th.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


			Call for Participation

		Fifth ACM SIGOPS European Workshop

	Models and Paradigms for Distributed Systems Structuring


			September 21-23, 1992
		     Le Mont Saint-Michel, France

			Organized by IRISA-INRIA


A significant body of experience in the design and implementation of
distributed operating systems has been developed in the last 15 years, both
through research prototypes and industrial products. The time seems to be
right for an attempt to formulate, to consolidate and to evaluate the main
models, concepts and paradigms on which the design of distributed operating
systems is based.

Examples of influential concepts are atomic transactions, atomic broadcast,
global time, order and causality, process groups, distributed shared memory,
etc. Examples of useful paradigms for structuring distributed systems are
object structures, client-server models, micro-kernel based architectures,
various forms of remote procedure call, etc.

This workshop should be the occasion for the distributed systems community to
take a global view of the main concepts on which their practice is based. We
should assess to which degree these concepts can help to design and build
systems that meet the requirements of efficiency, information sharing and
reliability imposed by the applications.

Contributions that emphasize the interplay between concepts and experience
will be specially appreciated.

Workshop attendance is limited to 50 people. The workshop will be held at the
historical site of Le Mont Saint-Michel, in Normandy. If you wish to
participate, please submit by April 17, 1992 a position paper of not more
than five pages. Please send seven copies of your position paper to the
Workshop Chairman:


Prof. Jean-Pierre Bana^tre
IRISA Campus universitaire de Beaulieu 35042 Rennes Cedex, France
Tel: (+33) 99 84 72 20
Fax: (+33) 99 38 38 32 
e-mail: jpbanatre@irisa.fr


Notification of acceptance will be mailed by May 30, 1992. Please include an
electronic mailing address (if you have one) in your position paper.
The workshop proceedings including all accepted papers will be published by
INRIA. We are also considering publishing revised versions of selected papers
in Operating Systems Review.


Program Committee
 
J.-P. Bana^tre, IRISA-INRIA, France (Chairman) 
S. Krakowiak, IMAG, France (Co-chairman) 
O. Babaoglu, Univ. Bologna, Italy 
A. Black, DEC CRL, USA 
K. Birman, Univ. Cornell, USA
S. Mullender, Univ. Twente, The Netherlands
M. Shapiro, INRIA, France
S. Shrivastava, Univ. Newcastle upon Tyne, UK

Organizing Committee

J.-P. Bana^tre, M. Bana^tre, C. Morin, G. Muller, IRISA-INRIA, France
From: mday@jukebox.lcs.mit.edu (Mark Day)
Newsgroups: comp.os.research
Subject: Re: A challenge (response) (response)
Date: 12 Apr 92 16:26:54 GMT
Article-I.D.: darkstar.32795
Organization: /u/mday/.organization
Originator: osr@ftp


   bellcore!gizmo.bellcore.com!mo@uunet.UU.NET (Michael O'Dell) writes:

   Penpoint - one of the most interesting pieces of OS work
   I've seen in a long time.

I second this opinion.  I recommend the book (The Power of PenPoint) to
anyone interested in seeing a new perspective on operating systems.

--Mark Day

mday@lcs.mit.edu
From: sjc@cs.purdue.edu (Steve Chapin)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 13:24:57 GMT
Article-I.D.: darkstar.32223
Organization: Department of Computer Science, Purdue University
Originator: osr@ftp


}} In article <32138@darkstar.ucsc.edu> J.P.Knight@lut.ac.uk writes:
}} 
}} >   - Threads should be managed by the kernel, not in user space
}} 
}} I think this should be in section 1.  If your threads are in the user
}} space then there's a lot more chance that they'll interfer and do
}} goodness knows what.

I'd say this definitely does *not* belong in section 1.  At SEDMS III
this year, Lazowska's keynote address was on the beauty of user-level
threads, when done properly.  In fact, the general consensus among
those that discussed them seemed to be that user-level threads were
better than kernel threads.

}} >Andy Tanenbaum (ast@cs.vu.nl)
}} Jon P. Knight,   Ph.D. Student, Part-time Research Assistant & Subwarden.

sjc@cs.purdue.edu             Steve Chapin             Today's Grammar Lesson:
                       Let's hope the usher lets us in.
From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
Newsgroups: comp.os.research
Subject: Languages (was Re: Have we learned anything in the last 20 years?)
Date: 8 Apr 92 03:52:18 GMT
Organization: University of Newcastle, AUSTRALIA
Originator: osr@ftp

In article <32272@darkstar.ucsc.edu>, andrew@rentec.com (Andrew Mullhaupt) writes:
> 
> I believe that the requirements of applications programming languages are
> not the same as those of systems programming languages. How do OS people
> feel about this?

There was a feeling in the early 1970s that for systems programming
you needed something different from "ordinary" programming languages
- and that was true, if your choice of "ordinary" languages was
limited to things like Fortran and Cobol - and that is how C and
similar languages arose.  In time people started using C for
non-systems work, because (a) it was there, and (b) they were used
to it.

These days, I use Modula-2 for my OS work, and I also use Modula-2 for
my applications work.  When a language I like better has stabilized,
I'll probably use it for both categories.

There are several good reasons why people like me will use the same
programming language for both low-level and high-level stuff, for
example:
 - the boundary between "applications" and "system" is becoming
   fuzzier.  Some of my "applications" work requires me to write
   device drivers, for example.
 - you can be more productive sticking to a single language, because
   of time saved for things like chasing up the best compilers,
   getting used to what library features are available, etc.

-- 
Peter Moylan                      eepjm@wombat.newcastle.edu.au
From: crispin@csd.uwo.ca (Crispin Cowan)
Newsgroups: comp.os.research
Subject: Re: microkernel layers (was Re: A challenge)
Date: 14 Apr 92 01:05:48 GMT
Organization: Department of Computer Science, University of Western Ontario, London
Originator: osr@ftp

In article <32794@darkstar.ucsc.edu> glew@pdx007.intel.com (Andy Glew) writes:
>[list of hazards inherent in same address space threads]
>Unfortunately, shared address spaces lead to efficient implementations
>on uniprocessors and tightly coupled multiprocessors.
>
>What is needed is efficient hardware support for multiple protection
>domains within the same address space. 
Or a slick language that guarantees that threads cannot interfere, like
Hermes.  Plug, plug.  Yes, the compiler proves that the threads won't
make seg-fault kinds of errors.  Thus threads can run efficently in the
same address space, and still be safe.

Crispin
-----
Crispin Cowan, CS grad student, University of Western Ontario
Phyz-mail:  Middlesex College, MC28-C, N6A 5B7
E-mail:     crispin@csd.uwo.ca		Voice:  519-661-3342 
"If you want an operating system that is full of vitality and has a
great future, use OS/2."  --Andy Tanenbaum
From: kahn@parc.xerox.com (Ken Kahn)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 09:59:31 GMT
Organization: Xerox PARC, Palo Alto, CA
Originator: osr@ftp

Regarding:

    The issues of designing programming languages for large scale
    distributed systems are well addressed in a 1989 landmark paper by
    Ken Kahn (kahn@parc.xerox.com) and Miller (markm@xanadu.com).
    Contact Ken for an electronic copy of this paper.

I have placed the paper on parcftp.xerox.com as
/transient/kahn/language-design.ps and
/transient/kahn/language-design.tex.  It should last about 2 weeks.

The paper was called "Language Design and Open Systems" and it appeared
in The Ecology of Computation, B. Huberman (ed.), North Holland, 1988.

Here's the abstract:

We argue that a distributed implementation of a programming language
brings flexibility and uniformity to the programming of open systems.
We define an {\em open system} to be a large collection of
computational services that use each other without central
coordination, trust, or complete knowledge of each other.  For a
distributed language to be well-suited for programming of such open
systems it should not rely upon global constructs.  It should be
possible to securely encapsulate servers with state.  It must deal with
the non-determinism and asynchrony of the world and other
computations.  It should localize errors and failures.  And it should
be possible to reprogram despite continuous operation.

We discuss why nearly all of today's programming languages and their
straight forward extensions are inadequate as a foundation upon which
to program large-scale open systems.  We describe two major exceptions:
actor languages and concurrent logic programming languages.  We attempt
to show why these languages are good for writing programs which both
provide services and take advantage of services offered by others in a
manner that scales from basic computation steps to very large
distributed systems.  We argue that actor languages and concurrent
logic programming languages are really very similar, despite very
different origins and conceptual models.  We examine how actor
languages and concurrent logic programming languages differ in their
suitability for open systems.

-----------------------

I would like to hear from people as to what lanaguages since 1988
should be included in the list of appropriate languages for open
systems programming. Hermes comes to mind.

 -ken kahn
From: johnm@cory.berkeley.edu (John D. Mitchell)
Newsgroups: comp.os.research
Subject: Re: What is PC/GEOS?
Date: 15 Apr 92 00:43:29 GMT
Article-I.D.: darkstar.32998
Organization: University of California, at Berkeley
Originator: osr@ftp

Since my posts referring to PC/GEOS I've gotten a few requests for
information about it.

PC/GEOS is a preemptive, multi-threaded, multi-tasking, graphical UI
operating system that runs on Intel 8088 (and above) MS-DOS compatible
machines.

Now that we gotten rid of the skeptical...  PC/GEOS is written in an object
oriented assembly language (which is a superset of MASM/TASM).  The kernel
fully supports the objects/messaging/etc.  The initial version of the
system was used to create GeoWorks Ensemble.  PC/GEOS has pioneered the
concept of a Generic/Specific UI split.  That is to say the all
applications are written to a very powerful generic user interface API that
is mapped onto a run-time selectable specific UI (e.g. a Motif style
interface).  Changing SpecificUI's (say from Motif-like to Windows-like)
changes the application not a whit.  The system can run on desktop PC's and
the latest version can also run out of ROM.  Pen support was built into the
system in a few man-months and is now an integral (but optional) component.
You can have any combination of keyboard, mouse, and/or pen supported
simultaneously.

The system supports a Single Imaging Model.  This means that all of the
output (be it screen, printer, etc.) is WYSIWYG (the same idea as Display
Postscript).

But wait there's more!  :-)  The entire Ensemble product (including
PC/GEOS, a mid-level word-processor, draw program, drivers for all
supported PC video adapters, 8 outline fonts, printer drivers, plus a bunch
of other applications) can fit in less than 4 Mbytes of disk space and will
execute in 512 Kbytes of RAM.

There's lots of other things but if you're interested in finding out more
information check out comp.os.msdos.pcgeos.

Hope this helps,
	John D. Mitchell
	johnm@cory.Berkeley.EDU

P.S.	I'm speaking solely for myself.  GeoWorks speaks for itself.
From: amr@seas.gwu.edu (Amr El-Kadi)
Newsgroups: comp.os.research
Subject: We did not learn a lot!
Date: 7 Apr 92 15:50:51 GMT
Article-I.D.: darkstar.32275
Organization: George Washington University
Originator: osr@ftp

Andy writes:

>GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
>   - Message passing is too primitive for application programmers to use
Not true!

>   - Synchronous (blocking) communication is easier to use than asynchronous
Again, not true.  It depends on what you need to do.  If the design of a 
DS needs to use asynchronous communications, then it would be much cleaner
and easier to implement it with straight asynchronous communications rather
than going around and doing it with synchronous communications trying to 
emulate asynchronous communications.

>   - New languages are needed for writing distributed/parallel applications
Did we really exhaust the languages that we have already that are intended
for DS.  I'm sure this is not the case, people are too lazy to use them,
they are still using C with calls to UNIX (or whatever) instead of using
the clean cut Concurrent C, or Ada etc.
When we have good compilers and support for those languages and they
pose problems, then start thinking about new languages.

>   - Distributed shared memory in one form or another is a convenient model
I thought we are trying to be more modular? So what is it convenient for?

--Amr El-Kadi
From: kupfer@sprite.berkeley.edu (Mike Kupfer)
Newsgroups: comp.os.research
Subject: Sprite, user-level servers
Date: 13 Apr 92 23:16:54 GMT
Organization: University of California, Berkeley
Originator: osr@ftp


Disclaimer: these are my opinions only.  I haven't run them past the
rest of the Sprite group.

I think Fred Douglis's statement that the Sprite group is "just
barely" in business is a bit misleading.  True, we are no longer doing
external releases, and the user community here at Berkeley is slowly
shrinking.  On the other hand, there are still 3 Sprite PhD students
doing active research (plus a soon-to-be graduating MS student and a
staff person [me]), and Sprite is (still) being used to support the
Berkeley disk array project.  Sprite's heyday is past, but I don't
think it's ready for the retirement condo in Florida yet.

The Sprite IP code is still in a user-level server.  Performance is
adequate for telnet and maybe mail and ftp.  It is uncomfortably slow
for X; Sprite has its own IPC mechanism that we normally use instead.
We keep threatening to put the IP code back into the kernel, but
nobody has been brave enough to volunteer, and I doubt it will ever
happen.

On the subject of Sprite and micro-kernels, we are in fact
implementing Sprite on top of Mach and looking at the resulting
performance.  When we have enough results that we can say something
intelligent, you can be sure you'll hear from us.

Mike Kupfer
kupfer@cs.berkeley.edu
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 7 Apr 92 03:22:51 GMT
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

In article <32224@darkstar.ucsc.edu> douglis@MITL.COM (Fred Douglis) writes:
>Getting back to the thread, though, I disagree with the claim that the
>Sprite people aren't believers in microkernels.  It's more a question
>that when Sprite was first designed, microkernels were not a
>widely-accepted technology, and the Sprite researchers chose to go
>with a more traditional structure and devote their research efforts in
>other areas.  

Sorry if i put the wrong words in Sprite's mouth. 

My comments on the Sprite project date from a discussion in 1990 
with a member of the project. 
His specific objection was to the idea that "micro-kernel" ::= "Mach". 
He pointed out that tcp/ip had been implemented outside the Sprite
kernel, and just as quickly moved back in (performance reasons). 
Thus his comment on the "maxi-kernel". Even back in 1990, people were
sensing a faddish aspect to the "micro-kernel" label.

And yes, no one can really agree on what it means. 
ron
From: cdash@moet.cs.colorado.edu (Charles Shub)
Newsgroups: comp.os.research
Subject: An off the wall response to the challenge challenge
Date: 10 Apr 92 21:37:57 GMT
Organization: University of Colorado at Colorado Springs
Originator: osr@ftp


  In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
=>     ... I hereby challenge all the people who have commented on my list
=>     to do better.  List what YOU consider the five most important
=>     things we have learned about distributed operating systems in the
=>     past 20 years.

I've relearned some old lessons, and learned some new lessons.  Pardon
the jadedness, and excuse a bit of tongue in cheek.

1.  The NIH syndrome is still alive and well:
    a) if it wasn't invented here, it isn't worth a lot...
    b) if it WAS invented here, there is a way to get around any
       purported flaw or shortcoming.

2.  You STILL can't fool all of the people all of the time.  (there is
    not now and never will be ONE BEST WAY for all applications)

3.  We still don't have a good feel for the intrinsic relation between
    (or even if there is a relation between) problem features and solution
    approaches.  We still don't understand what is crucial about
    structuring solutions.  This seems to be a direct consequence of
    both the first and second topics.

4.  We still have a long way to go to understand scalability.

5.  We can take a prototype program running on a sun, freeze it, move
    it to a microvax and resume it, but finding funding to explore the
    practical feasability, extensibility, and performance aspects of this
    is difficult.
-- 

charlie shub  cdash@cs.Colorado.EDU      -or-        (719) 593-3492     
  or even  cdash@colospgs (BITNET)  if the above address won't work