home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / realtime / 1534 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.6 KB
  1. Path: sparky!uunet!pipex!doc.ic.ac.uk!uknet!newcastle.ac.uk!warton!naw2
  2. From: Adrian.Waterworth@newcastle.ac.uk (Adrian Waterworth)
  3. Newsgroups: comp.realtime
  4. Subject: Re: novel idea?
  5. Message-ID: <C0onL4.2qE@newcastle.ac.uk>
  6. Date: 11 Jan 93 09:27:03 GMT
  7. References: <erempel.726720401@sol.UVic.CA> <1993Jan11.171954.1@wombat.newcastle.edu.au>
  8. Organization: University of Newcastle upon Tyne, UK, NE1 7RU
  9. Lines: 45
  10. Nntp-Posting-Host: warton
  11.  
  12. eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
  13.  
  14. >In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
  15. >> 
  16. >> I am looking for an OS (real time obviously) that has the
  17. >> ability to swap a task from one cpu to another. This is merely
  18. >> a multiprocessing system. The catch is that I want to be
  19. >> able to mix cpu's. Say a 68040 as the general, but then a i860
  20. >> running on the side for complex graphics. If the i860 becomes
  21. >> bogged down (I don't know what I would be doing to bog down the
  22. >> i860, but lets say I do) and the 68040 is sitting idle (or close
  23. >> to it) can one of the tasks that is running on the i860 be switched
  24. >> over to the 68040 to run there.
  25. >> 
  26. >> I know that the single task on the 040 would run slower than on the
  27. >> i860, but if the i860 was bogged down, the net result would
  28. >> be a system speedup.
  29.  
  30. >You must be joking.  The machine languages of these two processors
  31. >are totally different.  Would you plan to run an 860 simulator on
  32. >the 68040, or recompile the source code each time you switched
  33. >processors?  Either way, the overheads are mind-boggling.
  34.  
  35. >"Run slower" is a gross understatement.
  36.  
  37.     I'm not sure that I entirely agree. In particular, why should
  38. it be necessary "to re-compile the source code each time you switched
  39. processors"? Assuming that enough memory or on-line storage is
  40. available, what's wrong with having two _pre-compiled_ versions of the
  41. task (one for each processor)? The task switching problem then becomes
  42. a simple case of suspending on one processor and loading/running on the
  43. other. I can't think of any references straight off the top of my head,
  44. but I know that this kind of technique has long been proposed (and
  45. probably used by now) as a means of supporting load-balancing and
  46. process migration in heterogeneous distributed systems.
  47.  
  48.                 Adrian.
  49. _______________________________________________________________________________
  50. FROM  : Adrian Waterworth.   E-MAIL : Adrian.Waterworth@newcastle.ac.uk
  51.                  UUCP : ...!uknet!newcastle.ac.uk!Adrian.Waterworth
  52. PHONE : +44 91 222 6858
  53. POST  : DCSC, Department of Computing Science,
  54.     University of Newcastle upon Tyne, UK. NE1 7RU.
  55.  
  56. DISCLAIMER : I just work here - any opinions expressed are my own.
  57.