HDTenEightyP/NetNews huggingface dataset:
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 12 Jan 93 01:48:06 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>This may, or may not, be convenient; a site might want to have a single
>common copy of the program, but have different configuration files on
>different machines.  Can a "perl" script source another "perl" script? 
>If so, the command would be the first script, and the configuration file
>would be the one it sources....

Or, alternatively, it could have all of the "standard" smarts built in,
but, if possible, source another script that contains local additions;
that way, you can keep the standard distribution and local additions
separate, and be able to drop in an updated standard distribution
without necessarily having to hack local additions in....
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Can a script find out, under SVR4, the ABI to which a machine conforms?
Date: 8 Jan 93 03:01:26 GMT
Organization: Auspex Systems, Santa Clara

>Why whould a script care.

Because the script might be a wrapper script around an application -
let's give the application the hypothetical name "Frame Maker" - that
finds out the architecture for the machine, and runs the appropriate
binary, because the hypothetical vendor of this application - let's give
them the hypothetical name "Frame Technology" - apparently wants to have
shared versions of the non-architecture-dependent files, and separate
directories for the architecture-dependent files.

And yes, I *did* get bitten by that when I tried firing Frame up on a
Solaris 2.x machine here; the obvious fix, of using "uname -p", isn't
guaranteed to allow the same binary to be used on, for example,
386-based and 486-based boxes.

If you don't think Frame is doing the right thing, try convincing *them*
of that - and, if you don't succeed, consider that having "uname -b"
might be better than forcing Frame to have to recognize that "i80386"
and "i80486" and "iPentium" and... are really equivalent for its
purposes.

And also consider that Frame might not be the *only* application that
does this....

>The Generic ABI lists all the commands an
>ABI conforming script may call. If a script is attempting to perform
>different functions based on architecture type then by definition "sort of"
>the script is non ABI conforming.

So?  Who cares?  What's the *cost* of putting in a "get the architecture
name" option into "uname"?

>Now this doesn't address the real world problem of having servers
>export a tree which contains binaries for a bunch of different machines,
>but some view this as an admin problem not an ABI problem.

And some don't.
From: ah442@cleveland.Freenet.Edu (Erik C. Orange)
Newsgroups: comp.realtime
Subject: Re: pSOS vs VxWorks: Comments?
Date: 6 Jan 1993 04:49:50 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


We recently brought in pSOS and VxWorks in-house for live
demonstrations.  Here are some musings on our impressions of the two.
FYI, we are still deciding which to use (in addition to Lynx):

VxWorks seems to sport a more robust development environment, in
terms of source-level debugging and having a networked "window"
into your target processor for status checking, etc.  Wind River
also markets a host simulator, which allows you simulate your
application on your development host w/o the need for target 
hardware.  Operating system primitives are what you'd expect;
everything seems to be dynamic enough in nature.  Cost could be
an issue; we've heard different stories on the cost of development
environments versus run-time and how many licenses you actually need.

pSOS pretty much offers the same features as VxWorks, but it seemed
that their networking (aka TCP/IP) was not as robust.  Also, your
target application is compiled with predefined parameters to produce
a final, monolithic chunk of code, into which everything is
preallocated.  In other words, we got the impression that creating
new tasks on the fly can only be done within the predefined constraints
set at compile time -- not total dynamic usage of available system
resources.  Also, the biggie against pSOS is that their tasks are actually
different THREADS of one main process, whereas VxWorks truly maintains
separate processes.  This was our impression from the demo.  We were
thinking, what if he main process crashes?  All the threads go with it.
At least with VxWorks, you'd only lose that process.  Again, our
impressions.

It seems to us that pSOS is meant for embedded applications (printers,
FAX, etc), where VxWorks can fit a variety of applications.

Hope this helps.


Erik
-- 
----------
Erik C. Orange                            FRD Industrial Automation
Computer Engineering                      Avery-Dennison Corporation
ah442@cleveland.Freenet.Edu               Concord, OH
Newsgroups: comp.realtime
From: dstewart+@cs.cmu.edu (David B Stewart)
Subject: Re: VMEbus - Summary of Responses
Organization: The Robotics Institute, Carnegie Mellon University
Date: Tue, 12 Jan 1993 18:48:52 GMT

In article <1993Jan12.093413@se17.wg2.waii.com> mwj@se17.wg2.waii.com (Mike Johnson) writes:

>has no offical translation at all. One individual pointed out, correctly, that
>this question should have been posted to newsgroup comp.arch.vmebus. Mea
						    ^^^^^^^^^^^^^^^^

That should be "comp.arch.bus.vmebus".

~dave
From: genillou@litsun.epfl.ch (Guy Genilloud)
Newsgroups: comp.realtime
Subject: Re: novel idea?
Date: 11 Jan 93 10:12:32 GMT
Organization: Ecole polytechnique federale de Lausanne DI-LIT

In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
   |> ...
   |> I am looking for an OS (real time obviously) that has the
   |> ability to swap a task from one cpu to another. This is merely
   |> a multiprocessing system. The catch is that I want to be
   |> able to mix cpu's...
   |> 
   |> Evan Rempel
   |> erempel@sol.uvic.ca

If the CPUs are different, it is more appropriate to speak of migrating objects
than to speak of swapping tasks. Look for papers on distributed systems and
migration for ideas on this subject.

Migration can be done effectively provided you have templates (compiled
programs) for the objects/tasks on both CPUs, and provided you find a scheme to
transfer the data from a suspended object/task on one CPU to another 
(newly created) object on the other CPU. If you want the transfer to be done 
very efficiently, then you can try to define precisely the state of the object 
and transfer only the state.

Guy Genilloud
EPF Lausanne, Switzerland
Xref: sparky comp.realtime:1546 comp.lang.c++:18956
From: glb0270@smarine.UUCP (Guy Babineau)
Newsgroups: comp.realtime,comp.lang.c++
Subject: Anyone using C++ compilers on Lynx?
Keywords: C++ Lynx
Date: 11 Jan 93 18:50:37 GMT
Reply-To: virginia.edu!smarine.uucp!glb0270 (Guy Babineau)
Followup-To: comp.realtime
Organization: Sperry Marine, Inc.

Hello,

Has anyone had experience using any of the several C++ compilers for Lynx
(386 AT)?  Alternatively, has anyone ported a modern GNU c++ to Lynx with 
success? The g++ compiler provided is too antiquated for our purposes
(version 1.4).

Several companies, including Liant and EPC are advertising compilers.
I am particularly interested in how well the code links with the threads
library and how well the debugger works with threads.

Please respond via email to one of the following accounts or post news if the
reply is of general interest.  I will be glad to summarize.


Guy L. Babineau 			72147.2474@compuserve.com
					virginia.edu!smarine.uucp!glb0270
Newsgroups: comp.realtime
From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
Subject: Re: novel idea?
Organization: University of Newcastle, AUSTRALIA
Date: Mon, 11 Jan 1993 06:19:54 GMT

In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
> 
> I am looking for an OS (real time obviously) that has the
> ability to swap a task from one cpu to another. This is merely
> a multiprocessing system. The catch is that I want to be
> able to mix cpu's. Say a 68040 as the general, but then a i860
> running on the side for complex graphics. If the i860 becomes
> bogged down (I don't know what I would be doing to bog down the
> i860, but lets say I do) and the 68040 is sitting idle (or close
> to it) can one of the tasks that is running on the i860 be switched
> over to the 68040 to run there.
> 
> I know that the single task on the 040 would run slower than on the
> i860, but if the i860 was bogged down, the net result would
> be a system speedup.

You must be joking.  The machine languages of these two processors
are totally different.  Would you plan to run an 860 simulator on
the 68040, or recompile the source code each time you switched
processors?  Either way, the overheads are mind-boggling.

"Run slower" is a gross understatement.

-- 
Peter Moylan                      eepjm@wombat.newcastle.edu.au
Newsgroups: comp.realtime
From: kellyj@leland.Stanford.EDU (Kelly Johnson)
Subject: Re: novel idea?
Organization: DSG, Stanford University, CA 94305, USA
Date: Tue, 12 Jan 93 02:02:52 GMT

In article <1993Jan11.212259.16530@noao.edu> cole@noao.edu (Lonnie Cole) writes:
>In article <1993Jan11.065941.21342@leland.Stanford.EDU> kellyj@leland.Stanford.EDU (Kelly Johnson) writes:
>>In article <erempel.726720401@sol.UVic.CA> erempel@sol.UVic.CA (Evan Rempel) writes:
>>>I haven't read very much in the realtime environment, but I have
>>>a thought about an OS that has what I think is a fairly unique
>>>idea.
>>>
>>>I am looking for an OS (real time obviously) that has the
>>>ability to swap a task from one cpu to another. This is merely
>>>a multiprocessing system. The catch is that I want to be
>>>able to mix cpu's. Say a 68040 as the general, but then a i860
>>>running on the side for complex graphics. If the i860 becomes
>>>bogged down (I don't know what I would be doing to bog down the
>>>i860, but lets say I do) and the 68040 is sitting idle (or close
>>>to it) can one of the tasks that is running on the i860 be switched
>>>over to the 68040 to run there.
>>>
>>>I know that the single task on the 040 would run slower than on the
>>>i860, but if the i860 was bogged down, the net result would
>>>be a system speedup.
>>>
>>>Is there any system out there that provides this type of
>>>functionality?
>>>
>>
>>The problem with the idea is that the executable code for the 68040
>>and i860 are totally different.  It is not uncommon to have a
>>homogeneous multi-processor system that swaps tasks between cpu's
>>for load balancing, but doing so between totally different types of
>>cpu's would not be a simple task of just swapping tasks. 
>>I fail to see how this could ever be done effectively.  
>>Anyone else agree/disagree?
>>
>
>Why does each processor have to execute the same binary code. Suppose
>that each processor had its own binary copy of the code to execute and
>some mechanism to share the environment (local data, stack information
>etc.) then the process is not so far fetched.
>
>I don't think it's such a silly idea, kind of interesting.
>

I agree that it is interesting, but it sure has some significant problems.
I took the original post literally when I should not.  I figured he was
looking to do the same type of thing you would do when transfering context's
between homogeneous machines (ie. just transfer simple state information like
the PC, data space/code space addresses, etc).  In a heterogenous system
like that you would (like many have said) need separate executables on each
system.  This could easily introduce problems with data object sizes, alignment
restrictions, etc.  Also, what do you do in the case of instructions that have
"faulted" (like due to a page swapped out).  Theoretically it sounds interesting
and MAY have merit, but pragmatically it seems a bit out there, but who knows
it may be closer than I think.  I don't like to limit things more than the
laws of physics allow and even those can "appear" to be broken at times.

Newsgroups: comp.realtime
From: dstewart+@cs.cmu.edu (David B Stewart)
Subject: Re: novel idea?
Organization: The Robotics Institute, Carnegie Mellon University
Date: Mon, 11 Jan 1993 18:42:17 GMT

In article <1993Jan11.171954.1@wombat.newcastle.edu.au> eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
>In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
>> 
>> I am looking for an OS (real time obviously) that has the
>> ability to swap a task from one cpu to another. This is merely
>> a multiprocessing system. The catch is that I want to be
>> able to mix cpu's. Say a 68040 as the general, but then a i860
>> running on the side for complex graphics. If the i860 becomes
>> bogged down (I don't know what I would be doing to bog down the
>> i860, but lets say I do) and the 68040 is sitting idle (or close
>> to it) can one of the tasks that is running on the i860 be switched
>> over to the 68040 to run there.
>> 
>> I know that the single task on the 040 would run slower than on the
>> i860, but if the i860 was bogged down, the net result would
>> be a system speedup.
>
>You must be joking.  The machine languages of these two processors
>are totally different.  Would you plan to run an 860 simulator on
>the 68040, or recompile the source code each time you switched
>processors?  Either way, the overheads are mind-boggling.
>
>"Run slower" is a gross understatement.


I don't think he is joking, and I know it is feasible, as we are working
on reconfigurable systems, and the above is one possible application
for our methodology.

You obviously don't transfer the binaries across.  However, it is reasonable
to have the same source code module compiled for the different
architectures.   That same module is then downloaded to a few different
processors.  If there are a hundred processors in the system, it might
not be reasonable to download the code to all of them.  However, to download
it to 2 or 3 or 4 gives you at least some flexibility.

Suppose that you the module is a periodic task.  Then each cycle
of the periodic task can occur on any of the processors that has that
task's code downloaded.  Any state information for the task (i.e. passed
along from one cycle to the next) must be stored in a shared memory
segment, so that regardless of which processor the task executes on,
it can obtain that state information with only a fixed (and small) amount
of overhead.  The global state variable table mechanism in the
Chimera Real-Time Operating System already does this, so again I know
it is possible.

Instead of shooting down an idea so quickly, think about it more, and you'll
realize how many possibilities you can come up with, even though they are not
exactly what is described in the original idea.  Then think about the problems
of each, and one of those might actually work!

~dave

-------------------------------------------------------------------------------
David B. Stewart  - email: <dstewart@cmu.edu>            The Robotics Institute
snail mail:       - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213
Current Projects: - Chimera 3.0 Real-Time Operating System
		  - Reconfigurable Sensor-Based Control Systems
From: healy@nosc.mil (Mike Healy)
Subject: Re: pSOS vs VxWorks: Comments?
Organization: Naval Ocean Systems Center, San Diego
Date: Wed, 6 Jan 1993 00:13:43 GMT

In article <1993Jan4.143909.11736@resonex.com> michael@resonex.com (Michael Bryan) writes:
>
>We're considering using a commercial real time OS for our MVME-based
>data acquisition system.  Among the reasons for this are support for
>TCP/IP and NFS, as well as decent Unix-hosted development systems.
>
>Currently, the two main contenders are pSOS+ and VxWorks.  Does anybody
>have any comments on the various pros and cons of each of these products?
>
>-- 
>Michael Bryan     michael@resonex.com

There was a benchmark of various r/t os's posted here which included
both vxWorks and pSOS. As I recall, vxWorks had better network support
and pSOS had better interrrupt latency.

At any rate, I use vxWorks and have a lot of networking requirements and
I am happy with it. It does support TCP/IP and NFS and development is
done on a Unix workstation.

Mike Healy

healy@nosc.mil
From: miket@frog.CRDS.COM (Michael C Tiernan)
Newsgroups: comp.realtime
Subject: Re: Realtime Hardware
Date: 11 Jan 93 20:53:23 GMT
Organization: Charles River Data Systems

jcavin@tsd.arlut.utexas.edu (Jerry D. Cavin) writes:
>Is there anyone out there that have used the chip set that
>implements the XTP ( eXpress Transfer Protocol )?  

	Is there any references available for this protocol?
	What is it's intended use?

	Thanks.
-- 
<< MCT >>  Michael C Tiernan. - GEnie:M.Tiernan - AOL:M Tiernan/BCS Mike 
UUCP = alfalfa!pro-angmar!m.tiernan OR miket@frog.UUCP
      It's too bad that it takes almost half of our life
	to realize that it was a "Do-It-Yourself" project.
From: jammer@eskimo.com (Lyle Harwood)
Newsgroups: comp.realtime
Subject: The Stock Market, and futures
Date: 8 Jan 93 09:13:37 GMT
Organization: -> ESKIMO NORTH (206) For-Ever <-
X-Newsreader: TIN [version 1.1 PL6]


Hey, guys, I want to buy and sell futures and stocks through the
little curly wire on the back of me Mac.
Does anyone know where I can look for a newsgroup, a book, information,
take a class?
Thanks!

Jammer
Newsgroups: comp.realtime
From: michael@resonex.com (Michael Bryan)
Subject: pSOS vs VxWorks: Comments?
Organization: Resonex Inc., Sunnyvale CA
Date: Mon, 4 Jan 1993 14:39:09 GMT


We're considering using a commercial real time OS for our MVME-based
data acquisition system.  Among the reasons for this are support for
TCP/IP and NFS, as well as decent Unix-hosted development systems.

Currently, the two main contenders are pSOS+ and VxWorks.  Does anybody
have any comments on the various pros and cons of each of these products?

-- 
Michael Bryan     michael@resonex.com
Newsgroups: comp.realtime
From: michael@chg.mcd.mot.com (Michael Bodine)
Subject: Re: VMEbus
Organization: Motorola Computer Group, Schaumburg, IL
Date: Fri, 8 Jan 1993 18:55:48 GMT

mwj@se17.wg2.waii.com (Mike Johnson) writes:
>I've got a technical writer asking me what the VME in VMEbus stands for. I suppose it's an acronym for something, but nobody here knows what. The VMEbus specification we have doesn't give this information either. Anybody know?
The "official" answer, and the reason it doesn't appear in any bus specs,
is that VME doesn't stand for anything.  This is because Motorola,
Signetics and Mostek were trying together to make VME a standard and they
didn't want any vendor-specific acronyms to get in anyone's way.  The true
history, however:  VersaModuleEurocard.  VERSAbus was the early Motorola
bus designed to support the 68K.  The Europeans liked the way it worked
but not the way it looked, so they moved the electrical spec onto the 6U
Eurocard form factor.  Et voila!
-- 
[ Michael Bodine; michael@chg.mcd.mot.com; Voice: (708) 576-7840; FAX: x8875  ]
[ Motorola Computer Group - IL38;1100 Woodfield;Suite 334;Schaumburg, Il 60173]
From: deanp@peg.pegasus.oz.au
Newsgroups: comp.realtime
Date: 05 Jan 93 17:52 EST
Subject: Re: New Book: _Forth: the New Model_
Nf-ID: #R:jax.724484373@well.sf.ca.us:-885481972:peg:785400006:000:355
Nf-From: peg.UUCP!deanp    Jan  5 17:52:00 1993


> Steve (masticol@cs.rutgers.edu):
>Unfortunately, as Dean (me) pointed out, adopting a standard
>often doesn't get done because it might impact next quarter's profit
>margin

Although this is the business reality, my main concern was that there
is not enough programmer hours to redevelop everything that layered
over the "standard" kernel... 

dean...
From: R.Sheikhan2@lut.ac.uk (ZAGROS)
Newsgroups: comp.realtime
Subject: Papers by WA.HALANG on real time OS.
Date: 11 Jan 93 12:04:14 GMT
Reply-To: R.Sheikhan2@lut.ac.uk (ZAGROS)
Organization: Loughborough University, UK.

Hi Netters;
 
I am looking for papers by WA HALANG on real time operating systems. Can anybody
tell me if any of HALANG papers are available via ftp?? or alternatively if you have any papers from him I would be grateful if you could email them to me.

Many thanks ,
Z;
Newsgroups: comp.realtime
From: "elliott chapin" <elliott.chapin@canrem.com>
Subject: novel idea?
Reply-To: "elliott chapin" <elliott.chapin@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 11 Jan 93 11:34:38 EST

ER>a multiprocessing system. The catch is that I want to be
ER>able to mix cpu's. Say a 68040 as the general, but then a i860
ER>running on the side for complex graphics. If the i860 becomes
ER>bogged down (I don't know what I would be doing to bog down the

Forth vectored execution?

Elliott Chapin
---
  DeLuxe 1.12 #4315  elliott.chapin@canrem.com
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.realtime
From: ojr@itk.unit.no (Ornulf Rodseth)
Subject: Re: novel idea?
Organization: Norwegian Institute of Technology / SINTEF, Trondheim, Norway
Date: 12 Jan 93 09:39:49


In article <5620@disuns2.epfl.ch> genillou@litsun.epfl.ch (Guy Genilloud) writes:
>    |> ...
>    |> I am looking for an OS (real time obviously) that has the
>    |> ability to swap a task from one cpu to another. This is merely
>    |> ...
>    |> Evan Rempel
>    |> erempel@sol.uvic.ca
> 
> If the CPUs are different, it is more appropriate to speak of migrating objects
> than to speak of swapping tasks. Look for papers on distributed systems and
> migration for ideas on this subject.
> ...
> Guy Genilloud
> EPF Lausanne, Switzerland

It should be relatively easy to generalize this in an event-driven
system. In such systems all state should (in principle) be explicitly
represented in "state variables". Further more, all processing and
state changes are initiated by events.

You need a way to transfer state from one CPU to another in an
architecture-independent way (e.g., XDR) and you need two or more
identical set of event handlers (i.e., tasks), each compiled for its
own CPU.

As long as you keep the state in sync and switch tasks at
event-arrival boundaries you should be just fine.



--
Ornulf Jan Rodseth M.Sc.	ojr@itk.unit.no
SINTEF Automatic Control	+(47 7) 594351 (direct) / 594375 (switchboard)
N-7034 TRONDHEIM, NORWAY	+(47 7) 594399 (fax)
Newsgroups: comp.realtime