NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/realtime/1545

Text File | 1993-01-11 | 3.5 KB | 71 lines

Newsgroups: comp.realtime
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!crabapple.srv.cs.cmu.edu!dstewart
From: [e-mail] (David B Stewart)
Subject: Re: novel idea?
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet News System)
Nntp-Posting-Host: ius4.ius.cs.cmu.edu
Organization: The Robotics Institute, Carnegie Mellon University
References: <[e-mail]> <[e-mail]>
Date: Mon, 11 Jan 1993 18:42:17 GMT
Lines: 58

In article <[e-mail]> [e-mail] (Peter Moylan) writes:
>In article <[e-mail]>, [e-mail] (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: <[e-mail]>            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