home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4360 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: 680X0 -> PPC translator?
  5. Date: Wed, 28 Feb 96 04:48:12
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960228.43D838.45DF@an173.du.pipex.com>
  9. References: <4fstt2$old@newsstand.cit.cornell.edu> <PETERM.96Feb19135541@tui.maths.irl.cri.nz> <4glch6$rle@ra.nrl.navy.mil> <1190.6631T892T581@und.ida.liu.se> <4gvg0v$j2j@newsstand.cit.cornell.edu> <4h0dum$lb0@werple.net.au>
  10. NNTP-Posting-Host: an173.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Chris Hames (bytey@werple.net.au) wrote:
  14. : fkrj@crux4.cit.cornell.edu (Benjamin Kenobi) writes:
  15. : 
  16. : >On the amiga, don't we have separate "hunks" for code and data?
  17. : 
  18. : Yes but code hunks can contain data and data hunks can contain code.  You
  19. : need a much more strict executable format if you want to static translate to
  20. : another processor for all cases (without an unlimited machine).
  21.  
  22. In which case you need an emulation engine as well as a static translator. I
  23. believe DEC have a solution along these lines - it is a combination x86
  24. translator / emulator for Windows NT running on Alphas. It claims 70% of
  25. native Alpha performance for translated WinNT x86 executables - i.e. a
  26. translated x86 executable runs at 70% of the speed of that same application
  27. compiled for and running on an Alpha. An analog of this for PPC Amigas would
  28. be a godsend.
  29.  
  30. Handling instructions and data misplaced in hunks would be difficult to
  31. handle, though, and I am not sure how strict Windows NT is about such
  32. faults - i.e. does it allow them _at all_?
  33.  
  34. I can think of one possible method to deal with the problem which might be
  35. reasonably efficient in execution, but would require use of the MMU to
  36. operate.
  37.  
  38. The executable would be a fat binary format, containing the translated code
  39. and data hunks and also the untranslated hunks in their original, or perhaps a
  40. slightly altered, form.
  41.  
  42. Thus pretranslated instruction execution can proceed as normal, using the
  43. translated instruction and data hunks, _until_ an attempt is made to access
  44. _data_ in a code hunk (such accesses could be detected using the MMU). When
  45. this occurs the original code hunk must be referred to, since the translated
  46. code will be effectively impossible to reverse-translate into data.
  47.  
  48. A similar procedure could be used to handle code executed from within a data
  49. hunk, although this may not be necessary if the translated data hunks are only
  50. marginally different from the originals. A cache of translated versions of
  51. this misplaced code would probably speed things up substantially.
  52.  
  53. The above description is obviously overly simplistic, and extra layers of
  54. support would have to be built-in to provide access to OS calls and other
  55. shared routines and data, but am I on the right track here?
  56.  
  57. -- Mat.
  58.