home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6440 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.7 KB
  1. Path: vb.franken.de!volker
  2. From: volker@vb.franken.de (Volker Barthelmann)
  3. Subject: Re: 680X0 -> PPC translator?
  4. Newsgroups: comp.sys.amiga.programmer
  5. References: <3143E4EB.7303@sapiens.com> <volker.0fsu@vb.franken.de> <31499F8E.26A9@netvision.net.il> <volker.0fw1@vb.franken.de> <315800D7.1854@sapiens.com>
  6. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  7. Message-ID: <volker.0g32@vb.franken.de>
  8. Date: 28 Mar 96 01:38:51 MET
  9. Organization: home
  10.  
  11. Avi L. (avil@sapiens.com) wrote:
  12. : Volker Barthelmann wrote:
  13. : >
  14. : > Jack (avilev@netvision.net.il) wrote:
  15. : > :
  16. : > : oh is that so?! unless you get the address from an outside source, such as allocating it YOU
  17. : > : must produce it, right?! so you have to have it stored somewhere in the program. if you get it
  18. : >
  19. : > No. I can get it from system functions or calculate it. And both possibilities
  20. : > can depend on information that is only available at runtime.
  21. :
  22. : you're a little confused here, you're talking about run-time values while that isn't necessary
  23. : to know when and how a certain memory space is used. you use the pointers as parameters
  24. : replacing the actual run-time addresses. these pointers already exist within the program
  25. : and can therefore be analyzed for any changes made to them and how they're being used.
  26.  
  27. Once an external function is called almost all information becomes useless,
  28. because You don't know what memory it changes.
  29.  
  30. : if you perform careful analysis of the pointers, and that means following the changes made
  31. : to them by the program, you CAN know in which context they are being used and act
  32. : appropriatly. for example:
  33.  
  34. Perhaps You can perform this analysis. An algorithm can't.
  35.  
  36. : call _malloc ; let's say register a1 holds the returned address.
  37. : move a1,xyz(a7) ; store it in some variable, noting the current value of a7.
  38.  
  39. Of course You can have a structure holding all Your variables. Now You pass
  40. the address of this structure to an external function that writes some
  41. values into it and You lost.
  42.  
  43. : what i mean is, you use your own value of a7 with an initial value of 0 and follow the
  44. : changes made to it resetting it to 0 on assignments. that way you don't need the actual value
  45. : of a7 for knowning to which variable it refers to. now you know the address of the pointer to
  46. : the allocated block i just malloc()'ed so you can know how it's being used later, eg. code or data.
  47. : and bear in mind that all memory allocation routines call evantually AllocMem() function so you
  48.  
  49. There are several memory allocating functions or other functions You can't
  50. know anything about.
  51.  
  52. : have the instruction address of where exactly the memory region was allocated and so you can change
  53. : the size argument for the function if that memory area is later used for self-modifying code.
  54. : also you have to follow any loops which do writes to the area cuz these might be the sections
  55. : that copy code into that area and so you have to make the adjustments so that they loop
  56. : according to the translated code size.
  57.  
  58. You would have to adjust EVERYTHING that is in any way dependant on the code
  59. size! How are You going to do this?
  60.  
  61. : > : from some outside source, such as malloc(), then you don't have it obviously but that being said
  62. : > : doesn't imply it's impossible to figure out in which context the address is being used (ie code
  63. : >
  64. : > Easy??
  65. :
  66. : yes easy, cuz as i said you know where it was allocated and you can change the appropriate
  67. : argument.
  68.  
  69. Er..have You ever really programmed anything with data flow analysis?
  70.  
  71. : > And in many programs You won't find any call to e.g. AllocMem with this
  72. : > size at all, because the program uses its own memory-pool-routines.
  73. : > Etc. etc...
  74. :
  75. : but then again it must have allocated the master pool from which it sub-allocates memory from
  76. : and besides it must pass that allocator the required size, so you can change it if that segment
  77. : is later used for code, you know the size of the copied code after all and if the size passed to
  78. : the function is sufficient for the translated code then you don't have to do anything otherwise
  79. : change it.
  80.  
  81. As the size of the sub-allocated memory changes You may have to completely
  82. rewrite the pool-allocator, because it may depend on the allocations being
  83. of certain sizes or a multiple of a certain sizes etc.
  84. To do this the translator would have to completely understand the allocator
  85. and this is impossible.
  86.  
  87. : > It's not unfounded, but I've thought about some things.
  88. : > There are much simpler similar problems that are AFAIK proven to be
  89. : > undecidable.
  90. :
  91. : care to elaborate on this please.
  92.  
  93. I think most standard data flow problems can only be approximated, but exact
  94. solutions (which would be needed by Your approach) can not be found.
  95. AFAIR I read somewhere that this was proven for some cases, but unfortunately
  96. I don't remember where it was.
  97.  
  98. : what the hell does recursion have to do with anything, it simply calls the function from within
  99. : itself, so what??? if you follow the changes to a7, then you'll always point to the right address,
  100. : remember that auto-variables don't exist cuz the programs is not running and so all references are
  101. : are register (a7) indirect and so nothing really matters, you use registers not absolute addresses.
  102.  
  103. You seem to think that every program uses variables and registers in the same
  104. way like a certain compiler. This is not true.
  105.  
  106. : > What do You mean by ansi-compliant programs and what does this have to do
  107. : > with it?
  108. : heheheh, i mean programs that use ansi C conventions for calling functions, register usage etc...
  109.  
  110. I don't know such ANSI C conventions. Implementation and generated code is
  111. up to the compiler. There may be OS conventions, but that is something
  112. completely different.
  113.  
  114. : > Functions are components of certain high level languages. In machine language
  115. : > there are only addresses. Even if this code was generated by a compiler You
  116. : > have to keep track of any jump addresses to be able to determine the
  117. : > beginning and end of a function and what is code an what is data.
  118. :
  119. : gimme one example where i would fail to translate that. believe me it should fine.
  120.  
  121. I gave several examples. The discussion is rather pointless as long as You
  122. just say 'I keep track of this' and 'adjust that according to xyz' etc.
  123. Of course it's possible to rewrite a program to PPC, but You have to show
  124. that this can be done by an algorithm and this is a different story.
  125.  
  126. Once You describe Your algorithm I will happily give You an example.
  127.  
  128. But believe me it will never ever work for anything more than some special
  129. programs. Data flow analysis can be useful for many things, but there are
  130. severe limitations and Your approach would practically have to 'understand'
  131. the program and completely rewrite it.
  132. This is completely absolutely impossible. No chance. Never. Won't work.
  133.  
  134. Volker
  135.  
  136.