home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / realtime / 1550 < prev    next >
Encoding:
Text File  |  1993-01-11  |  3.3 KB  |  67 lines
  1. Newsgroups: comp.realtime
  2. Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!kellyj
  3. From: kellyj@leland.Stanford.EDU (Kelly Johnson)
  4. Subject: Re: novel idea?
  5. Message-ID: <1993Jan12.020252.23939@leland.Stanford.EDU>
  6. Sender: news@leland.Stanford.EDU (Mr News)
  7. Organization: DSG, Stanford University, CA 94305, USA
  8. References: <erempel.726720401@sol.UVic.CA> <1993Jan11.065941.21342@leland.Stanford.EDU> <1993Jan11.212259.16530@noao.edu>
  9. Date: Tue, 12 Jan 93 02:02:52 GMT
  10. Lines: 55
  11.  
  12. In article <1993Jan11.212259.16530@noao.edu> cole@noao.edu (Lonnie Cole) writes:
  13. >In article <1993Jan11.065941.21342@leland.Stanford.EDU> kellyj@leland.Stanford.EDU (Kelly Johnson) writes:
  14. >>In article <erempel.726720401@sol.UVic.CA> erempel@sol.UVic.CA (Evan Rempel) writes:
  15. >>>I haven't read very much in the realtime environment, but I have
  16. >>>a thought about an OS that has what I think is a fairly unique
  17. >>>idea.
  18. >>>
  19. >>>I am looking for an OS (real time obviously) that has the
  20. >>>ability to swap a task from one cpu to another. This is merely
  21. >>>a multiprocessing system. The catch is that I want to be
  22. >>>able to mix cpu's. Say a 68040 as the general, but then a i860
  23. >>>running on the side for complex graphics. If the i860 becomes
  24. >>>bogged down (I don't know what I would be doing to bog down the
  25. >>>i860, but lets say I do) and the 68040 is sitting idle (or close
  26. >>>to it) can one of the tasks that is running on the i860 be switched
  27. >>>over to the 68040 to run there.
  28. >>>
  29. >>>I know that the single task on the 040 would run slower than on the
  30. >>>i860, but if the i860 was bogged down, the net result would
  31. >>>be a system speedup.
  32. >>>
  33. >>>Is there any system out there that provides this type of
  34. >>>functionality?
  35. >>>
  36. >>
  37. >>The problem with the idea is that the executable code for the 68040
  38. >>and i860 are totally different.  It is not uncommon to have a
  39. >>homogeneous multi-processor system that swaps tasks between cpu's
  40. >>for load balancing, but doing so between totally different types of
  41. >>cpu's would not be a simple task of just swapping tasks. 
  42. >>I fail to see how this could ever be done effectively.  
  43. >>Anyone else agree/disagree?
  44. >>
  45. >
  46. >Why does each processor have to execute the same binary code. Suppose
  47. >that each processor had its own binary copy of the code to execute and
  48. >some mechanism to share the environment (local data, stack information
  49. >etc.) then the process is not so far fetched.
  50. >
  51. >I don't think it's such a silly idea, kind of interesting.
  52. >
  53.  
  54. I agree that it is interesting, but it sure has some significant problems.
  55. I took the original post literally when I should not.  I figured he was
  56. looking to do the same type of thing you would do when transfering context's
  57. between homogeneous machines (ie. just transfer simple state information like
  58. the PC, data space/code space addresses, etc).  In a heterogenous system
  59. like that you would (like many have said) need separate executables on each
  60. system.  This could easily introduce problems with data object sizes, alignment
  61. restrictions, etc.  Also, what do you do in the case of instructions that have
  62. "faulted" (like due to a page swapped out).  Theoretically it sounds interesting
  63. and MAY have merit, but pragmatically it seems a bit out there, but who knows
  64. it may be closer than I think.  I don't like to limit things more than the
  65. laws of physics allow and even those can "appear" to be broken at times.
  66.  
  67.