HDTenEightyP/NetNews huggingface dataset:
From: bran@helix.ObjecTime.on.ca (Bran Selic)
Subject: Re: novel idea?
Reply-To: bran@ObjecTime.on.ca (Bran Selic)
Organization: ObjecTime Limited
Distribution: bnr
Date: Wed, 13 Jan 93 01:15:47 GMT

In article <1993Jan12.020252.23939@leland.Stanford.EDU>, kellyj@leland.Stanford.EDU (Kelly Johnson) writes:
|> 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?

While working on a shared multiprocessor on one project (about ten years
ago), I ran into this problem. We had two processors with different instruction
sets each of which had its own copy of the task. The process could be suspended
on one processor and then resumed on the other. The only problem that we
encountered, if I recall, was that each time a process started the task up
again, the entire argument stack had to be converted to the format of that
particular processor. Other than that worked quite well. Oh, I should mention
that this was a real-time project.

*------------------------------------------------------------*
* Bran Selic                 |  phone: (613) 591-3435        *
* Vice President R&D         |  fax: (613) 591-3784          *
* ObjecTime Limited          |  e-mail: bran@objectime.on.ca *
* 340 March Road             |                               *
* Kanata, Ontario, CANADA    |                               *
* K2K 2E4                    |                               *
*------------------------------------------------------------*
From: sdm91r@ecs.soton.ac.uk (Stuart Maclean)
Newsgroups: comp.realtime
Subject: Real time journals
Date: 5 Jan 93 15:38:16 GMT

Could anybody tell me about the leading journals/periodicals for real
time systems programming. I have seen a few mentioned in various
papers, like Embedded Systems Programming. I can't get hold of these
people at all. I know IEEE Software, CACM, etc, but am looking for
more specialised stuff and would like to know where to look.
-- 
Stuart Maclean,
Dept of Electronics and Computer Science,
University of Southampton.
Newsgroups: comp.realtime
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: Re: novel idea?
    <1993Jan11.195020.25839@frog.CRDS.COM>
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International
Date: Tue, 12 Jan 1993 12:59:58 GMT
X-Bytes: 2045

In article <1993Jan11.195020.25839@frog.CRDS.COM> miket@frog.CRDS.COM (Michael C Tiernan) writes:

 >	  You *MIGHT* want to consider the use of a psudo code at this
 >	  point, THEN, you could switch systems for a process.  However,
 >	  you'd then need an interpreter running on each machine which is
 >	  identical from the appliction's point of view.  And a zillion
 >	  other complexites build up from there.                ^^^^^^^

That is not quite true.  For example, I have used embedded Smalltalk
on VMEbus machines for realtime military signal processing (Radar)
applications.  Yes, there are some issues.  It happened that the
machine was homogeneous shared memory but it would also work on groups
of heterogeneous distributed memory machines.  I would not have wanted
to approach that project in any other language/environment.

For those who don't know what Smalltalk is: It is fully
Object-Oriented language/environment that *typically* is compiled to
bytecodes (similar to p-code) which is then run by a virtual machine
(interpreter).  many of the new Smalltalk compilers actually compile
directly to machine-code.  BTW, if you buy one of Tektronix new
digital osciliscopes you are really buying a 680?0 running a fully
interpreted Smalltalk!  Who says you can't do real-time stuff with
interpreted languages?

Anyway, I am not trying to sell Smalltalk.  Just point out that by
looking at things a little higher level or from a different
perspective many of these "problems" go away.  

I would argue that if you are caring about machine instructions there
is something wrong with your design.  Especially if you have multiple
processors.

BTW, for our signal processing app, we could actually develop code on
a 486 and move it to the target (040) with no changes.  (well, ok,
little tiny changes because on the 486 we had to model our custom
hardware).  Doesn't take long to figure out the economics of 15
engineers, $100,000 testbed and $4,000 486s.

But I digress

--
ato de, |m        -- spice is the irony of life!   thks mm
Newsgroups: comp.realtime
From: rjf@lincroftnj.ncr.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: The Stock Market, and futures
Organization: AT&T/NCR, Lincroft, NJ, USA
Distribution: na
Date: Fri, 8 Jan 1993 20:23:34 GMT

In article <1993Jan8.091337.13830@eskimo.com> jammer@eskimo.com (Lyle Harwood) writes:
>
>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


Call Fidelity Investments, 1-800-544-6666.  As I recall, their on-line
trading service is called Fidelity Express.  Charles Schwaab has
similar a service.


bob.				| Heap big trouble in the land of plenty.
Were these more than just my opinions, they would have cost a bit more.
Newsgroups: comp.realtime
From: prevost@westford.ccur.com (Michael J. Prevost (CCC))
Subject: Re: Anyone Familiar with RTAP
Organization: Concurrent Computer Corp.  Westford, MA
Distribution: comp.realtime
Date: Thu, 7 Jan 1993 20:24:43 GMT

...sorry for the re-post folks... the news server glitched...

Anyone out there have any experience with RTAP?  Its a real-time
(non-relational) database from HP.

What can you say about it... how did you use it? did you like it?
did you look at competing products?



                                                          Thanks,

                                                          Mike
From: mwj@se17.wg2.waii.com (Mike Johnson)
Newsgroups: comp.realtime
Subject: Re: VMEbus - Summary of Responses
Date: 12 Jan 93 15:34:13 GMT
Organization: Western Geophysical Expoloration Products

If the VME in VME bus stands for anything, it appears to be Versa Module Eurocard,
or Versa Module European. More than one individual pointed  that it has no offical translation at all. One individual pointed out, correctly, that this question should have been posted to newsgroup comp.arch.vmebus. Mea culpa.
Thanks to all who responded.

Mike Johnson
From: grob@chorus.fr (Lori S. Grob)
Newsgroups: comp.realtime
Subject: Re: Lynx and Chorus
Date: 5 Jan 93 14:59:32 GMT

In article <1992Dec31.181031.11309@umr.edu>, quandt@mcs213c.cs.umr.edu (Brian Quandt) writes:
> 
> We are still looking for a real time OS for a 386/486 platform.  
> Currenlty we have been evaluating Lynx/OS and have found it 
> to be the best of ones we have looked at so far.  However, it 
> can be (and frankly is) a pain!  Many of their tools such as
> compilers, linkers, etc are old and really need to be updated.  We
> dont understand why they don't upgrade this stuff to more current
> software when most of the stuff is already public domain (mostly
> GNU stuff).  Here's a typical problem we have experienced with Lynx:
> 	We would like to use the large amount of PD software out there
> 	so we download it from the nets and then try to compile.  On
> 	average less then 5% of the stuff we try will compile without
> 	major screwing around.  Short list of failures: xf, tk, and even
> 	tcl would not compile.
> 
> So Anyways, does anyone know anything about Chourus?  I have heard
> they are trying to become a part of SCO (or extension or whatever).
> My big fear is that SCO is sys 5 and Chorus is berkely 4.3.  All I hope 
> is that the product that may result from SCO and Chorus is 4.3 becuase
> I sure as heck don't want to take a step backwards to sysV.k

There are papers on Chorus available through anonymous ftp
from cse.ogi.edu. For more commercial information please
contact Chorus Inc. 503 690 2300 (in Portland).

Chorus is System V. We do have a BSD compatible system
that we use for some research but all of our products are
V4. The joint Chorus-SCO product will be based on 
Chorus MiX 3.2 which is system V 3.2 compatible.

Our other products are USL compatible. In terms of utilities
and tools if it works on System V that you get from USL
it should work on the version of MiX (our Unix) that you get from us.

If you have questions on university access or research program
please write to Rodger Lea rodger@chorus.com

--
L.S. Grob
Chorus syste`mes			phone +33-1-30-64-82-17
6 avenue Gustave Eiffel			fax   +33-1-30-57-00-66	
F78182 Saint Quentin-en-Yvelines	email grob@chorus.fr	
FRANCE
--------
Newsgroups: comp.realtime
Subject: Re: What's wrong with DOS in real-time?
From: Christopher Vickery <CCVQC@CUNYVM.BITNET>
Date: Thursday, 7 Jan 1993 15:02:42 EST
Organization: City University of New York/ University Computer Center

> 2) Does the DOS app have free access to hardware registers and interrupts ?
> How much is this access slowed by the emulation ?
The more critical issue, I would think, is how well the real-time
side is protected from DOS programs that might disable interrupts for
long (any) period of time.  If the RT OS does not run DOS as a VM86 task,
a DOS program (or DOS itself) can break the real-time side.  I know that
you think that having QNX run DOS in real mode is an advantage, but I
don't understand it.

> 6) How much does the presence of Windows impact the realtime performance of
> the processes managed by the realtime OS ?
As I said, this seems to be much more critical than 2).
-------
Christopher Vickery, Computer Science Department, Queens College (CUNY)
Flushing, NY 11367-0904  vickery@ipc1.cs.qc.edu (718)997-3500
Newsgroups: comp.realtime
Subject: Re: What's wrong with DOS in real-time?
From: Christopher Vickery <CCVQC@CUNYVM.BITNET>
Date: Tuesday, 5 Jan 1993 12:19:35 EST
Organization: City University of New York/ University Computer Center

In article <2012@mwca.UUCP>, bill@mwca.UUCP (Bill Sheppard) says:
>
>In <92365.123047CCVQC@CUNYVM.BITNET> CCVQC@CUNYVM.BITNET (Christopher Vickery)
>writes:
>
>>There are real time kernels and real time operating systems available for the
>>8086, but if if you want to do real-time on a DOS machine, you have to use
>>iRMX for Windows.  That's a full-blown real-time OS that runs only on an 80386
>>or above, undoubtedly too big for a small embedded app.
>
>There are Real-Time Operating Systems available for 'DOS' machines
>(80386/80486 PC's) which are scalable, and thus suitable for many embedded
>applications.  OS-9000 (a product I sell) would be one example of such an OS.
>
Right.  My comment meant to indicate that the only real-time OS that runs
with DOS is iRMX for Windows.  Then I found out that QNX runs with DOS/
Windows too.  iRMX for Windows "ecapsulates" DOS as an iRMX task using
VM86 mode to make it so DOS and Windows don't know that anything has
changed.  I'm not sure how QNX does it, since they use the phrase "emulate
DOS" to describe what they do.
-------
Christopher Vickery, Computer Science Department, Queens College (CUNY)
Flushing, NY 11367-0904  vickery@ipc1.cs.qc.edu (718)997-3500
Newsgroups: comp.realtime
From: cohen@odie.ee.wits.ac.za (Jack Cohen)
Subject: LON Chip: Motorola's Echelon Neuron Chip
Organization: Wits Electrical Engineering (Novell Users).
Date: Tue, 5 Jan 1993 11:18:21 GMT


I am looking for information about Motorola's implementation of Echelon's 
Neuron chip, the MC143150. (Or alternatively Toshiba's implementation.)

An Internet e-mail contact at Motorola would be most helpful.

Thanks,

===============================================================
Dr Jack E. Cohen			Phone: 2711-716-5366
Department of Electrical Engineering	       2711-716-5440
University of the Witwatersrand         Fax:   2711-403-1929
Johannesburg, South Africa
Internet e-mail:  cohen@odie.ee.wits.ac.za
===============================================================
Newsgroups: comp.realtime
From: gak@inel.gov (Gregory Kelley)
Subject: Re: What's wrong with DOS in real-time?
Summary: Nancy says 'Just say NO.'
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Distribution: na
Date: Mon, 11 Jan 93 23:22:16 GMT

In article <sT3XwB1w165w@ade.no> kai@ade.no (Kai Atle Myrvang) writes:
>> >There are Real-Time Operating Systems available for 'DOS' machines
>> >(80386/80486 PC's) which are scalable, and thus suitable for many embedded
>> >applications.  OS-9000 (a product I sell) would be one example of such an OS
>> >
>> Right.  My comment meant to indicate that the only real-time OS that runs
>> with DOS is iRMX for Windows.  Then I found out that QNX runs with DOS/
>> Windows too.
>
>Not the only two, There is a product named WinVRTX out on the market.  As 
>the name indicates, this is a VRTX and Windows environment.  Don't know too 
>much about it.  For those wanting to seek info, try Ready Systems' office 
>in France or Responsive Software Inc, Methuen, MA (USA). 
>
There is an article on DOS and Real-Time in the February 1992 
_Embedded System Programming_.  The article is named _DOS meets
Real-Time_. They may be reached at:

Embedded Systems Programming
P.O. Box 41094
Nashville, TN  37204


The article (which i didn't read all of) discusses the pitfalls to
watch for with the understanding that you can do a semblance of
real-time under DOS (my biased interpretation).
In May and June 1992 they presented a "Portable Real-Time Kernal in C".
So if you want to "Roll Your Own"...  (targeted the 80186 i believe)

One of their issues also reviewed something like 40 RTOS's for the 
8086 - 80x86 platform.  I can't seem to find it right now.

Personally I use QNX and I like it.
--
Greg Kelley    gak@inel.gov                 Press 'n' now...
DOS -- Just say NO.
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
Newsgroups: comp.realtime
Subject: Re: novel idea?
From: adrian@pluto.logica.co.uk (Adrian Putley)
Date: 11 Jan 93 20:56:38 GMT
Reply-To: adrian@pluto.logica.co.uk
Organization: Logica Industry Ltd, UK

>>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.
>>> 
Have you looked into the Locus traansparent computing facility (TCF)?

(Mind you, I don't know how real-time it is.)

Adrian Putley		Logica Industry Ltd	Medina House, Business Park 4,
putleya@logica.co.uk				Randalls Way, Leatherhead,
(+44 71) 637 9111 x5715				Surrey  KT22 7TW, UK
From: erempel@sol.UVic.CA (Evan Rempel)
Newsgroups: comp.realtime
Subject: novel idea?
Date: 11 Jan 93 02:46:41 GMT
Organization: University of Victoria

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?

If there is can you give me some pointers to other info on it.

Thanks in advance.

Evan Rempel
erempel@sol.uvic.ca
From: kai@ade.no (Kai Atle Myrvang)
Newsgroups: comp.realtime
Subject: Re: What's wrong with DOS in real-time?
Date: 6 Jan 93 11:12:46 GMT
Organization: AD Elektronikk AS, Norway

> >There are Real-Time Operating Systems available for 'DOS' machines
> >(80386/80486 PC's) which are scalable, and thus suitable for many embedded
> >applications.  OS-9000 (a product I sell) would be one example of such an OS
> >
> Right.  My comment meant to indicate that the only real-time OS that runs
> with DOS is iRMX for Windows.  Then I found out that QNX runs with DOS/
> Windows too.

Not the only two, There is a product named WinVRTX out on the market.  As 
the name indicates, this is a VRTX and Windows environment.  Don't know too 
much about it.  For those wanting to seek info, try Ready Systems' office 
in France or Responsive Software Inc, Methuen, MA (USA). 


kai@ade.no (Kai Atle Myrvang)
AD Elektronikk AS, Norway    |  Keywords:  VMEbus
Phone:  Int+479 869 970      |             OS-9
Fax:    Int+479 869 920      |             VRTX
From: Adrian.Waterworth@newcastle.ac.uk (Adrian Waterworth)
Newsgroups: comp.realtime
Subject: Re: novel idea?
Date: 11 Jan 93 09:27:03 GMT
Organization: University of Newcastle upon Tyne, UK, NE1 7RU

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'm not sure that I entirely agree. In particular, why should
it be necessary "to re-compile the source code each time you switched
processors"? Assuming that enough memory or on-line storage is
available, what's wrong with having two _pre-compiled_ versions of the
task (one for each processor)? The task switching problem then becomes
a simple case of suspending on one processor and loading/running on the
other. I can't think of any references straight off the top of my head,
but I know that this kind of technique has long been proposed (and
probably used by now) as a means of supporting load-balancing and
process migration in heterogeneous distributed systems.

				Adrian.
_______________________________________________________________________________
FROM  : Adrian Waterworth.   E-MAIL : Adrian.Waterworth@newcastle.ac.uk
			     UUCP : ...!uknet!newcastle.ac.uk!Adrian.Waterworth
PHONE : +44 91 222 6858
POST  : DCSC, Department of Computing Science,
	University of Newcastle upon Tyne, UK. NE1 7RU.

DISCLAIMER : I just work here - any opinions expressed are my own.
Newsgroups: comp.realtime
From: "elliott chapin" <elliott.chapin@canrem.com>
Subject: wanted: realtime-exte
Reply-To: "elliott chapin" <elliott.chapin@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 9 Jan 93 03:20:25 EST

Geert-Dieter,

I don't know Ada, but this might work in anything at all:  set up an
empty look and see how many repetitions are completed in a given length
of time, and then ...

Aber warum nicht Forth ?   :-)

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
From: miket@frog.CRDS.COM (Michael C Tiernan)
Newsgroups: comp.realtime
Subject: Re: novel idea?
Date: 11 Jan 93 19:50:20 GMT
Organization: Charles River Data Systems

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 promise to not berate you for the statements but hopfully help
	educate you a bit.  Everyone's points in response to this are
	right on the money and warrent some good reading.  Additionally,
	the issue of the machine languages makes all of this a moot
	point but also the difference in the hardware scheme, the
	structures of the systems would have to be tailored to make them
	all look alike which would cause a good bit of overhead in the
	hardware not just for time but power too.

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

	You could do work like this (note the word "like") by using a
	tight network and using RCP's to use each machine for it's
	strenghts.

>If there is can you give me some pointers to other info on it.

	You *MIGHT* want to consider the use of a psudo code at this
	point, THEN, you could switch systems for a process.  However,
	you'd then need an interpreter running on each machine which is
	identical from the appliction's point of view.  And a zillion
	other complexites build up from there.

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