Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: Charles A. Crayne on 8 Feb 2006 02:12 On 7 Feb 2006 21:14:35 -0800 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: :I suspect you don't know PPC assembly language, else you :would recognize that the code it is producing is *very bad* and not at :all written in the RISC/PPC paradigm. And therein lies our difference :of opinion, I suspect. If, by this marketing hype, you mean to say that the generated code does not take full advantage of the unique elements of the PPC architecture, then I am in full agreement with you. The tool is trading performance for portability, as does writing for any virtual machine, be it MIX, Z-Machine, Java, or even (to a certain extent) all HLLs. Our difference of opinion does not lie in this fact, but rather in the conclusions which we each draw from it. It is also worth pointing out that I have no vested interest in either this particular tool, or the company which provides it. It does, however, provide a valuable test bench, since we can attempt to replicate each other's results, in the best scientific tradition. Unfortunately, you and I seem to be the only participants in this group who have any interest whatsoever in the topic. :But, alas, the code is *far* worse than the stuff :I've seen *any* compiler produce. Have you even given it a chance? The tool has a number of optimizations, which are initially switched off, to make debugging easier: Allocate sub-registers dynamically within blocks Avoid re-calculating factors in addresses Optimization of bit-shift sequences Defer updating stack pointer until end of sequence Remove superfluous mov before arithmetic instruction Optimize return instructions in ?leaf? routines Optimize sequences of operations involving carry flag Of course, none of these will change the basic fact that the tool is emulating the x86 register structure, but it may well significantly reduce the code bloat. :Again, I would :argue, that it's *less work* to simply hand port the few apps you need :moved to a different CPU rather than go to all the hassle of writing a :*decent* translator and then hand massaging the output. To have any credibility, you need to put reasonably numbers to each of these steps. To begin with, how many lines of clean code do you reasonably expect a PPC programmer to generate per unit of time? :It would be interesting to see how :much work is *really* required to pull this off (I'm assuming you wrote :it with MASM, back in the DOS days). Indeed it would, but what is the benchmark against which we measure the 20%? The 16-bit DOS code runs about 6,000 lines, and while that is not all that much, it is large enough that I am not going to waste my time by converting it twice. So again I ask, what would you consider a reasonable number of programmer hours to do this conversion by hand? -- Chuck
From: ?a/b on 8 Feb 2006 03:28 On Tue, 7 Feb 2006 23:12:02 -0800, "Charles A. Crayne" <ccrayne(a)crayne.org> wrote: >On 7 Feb 2006 21:14:35 -0800 >"randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: >:I suspect you don't know PPC assembly language, else you >:would recognize that the code it is producing is *very bad* and not at >:all written in the RISC/PPC paradigm. And therein lies our difference >:of opinion, I suspect. > >If, by this marketing hype, you mean to say that the generated code does >not take full advantage of the unique elements of the PPC architecture, >then I am in full agreement with you. The tool is trading performance for >portability, as does writing for any virtual machine, be it MIX, >Z-Machine, Java, or even (to a certain extent) all HLLs. > >Our difference of opinion does not lie in this fact, but rather in the >conclusions which we each draw from it. It is also worth pointing out that >I have no vested interest in either this particular tool, or the company >which provides it. It does, however, provide a valuable test bench, since >we can attempt to replicate each other's results, in the best scientific >tradition. >Unfortunately, you and I seem to be the only participants in >this group who have any interest whatsoever in the topic. i say that in the software side the ways were covered so there is something to try in the hardware part: to do some changes to cpu_s that allow to easy and efficiently translate *a small part* of x86 instruction set and data set. then compilers and humans have to translate or program in that *small part* of x86 instructions set if they want their programs portable. the problem is to define a "minimal x86 cpu" and find all agree.
From: o///annabee on 8 Feb 2006 04:02 P? Wed, 08 Feb 2006 09:28:00 +0100, skrev ?a\/b <al(a)f.g>: > i say that in the software side the ways were covered > so there is something to try in the hardware part: to do some changes > to cpu_s that allow to easy and efficiently translate *a small part* > of x86 instruction set and data set. then compilers and humans have to > translate or program in that *small part* of x86 instructions set if > they want their programs portable. > the problem is to define a "minimal x86 cpu" and find all agree. Best idea I heard yet on the porting issue.
From: Dragontamer on 8 Feb 2006 09:11 \\\o///annabee wrote: > På Wed, 08 Feb 2006 09:28:00 +0100, skrev ¬a\/b <al(a)f.g>: > > > i say that in the software side the ways were covered > > so there is something to try in the hardware part: to do some changes > > to cpu_s that allow to easy and efficiently translate *a small part* > > of x86 instruction set and data set. then compilers and humans have to > > translate or program in that *small part* of x86 instructions set if > > they want their programs portable. > > the problem is to define a "minimal x86 cpu" and find all agree. > > Best idea I heard yet on the porting issue. If you have a "minimal x86 cpu", why not just use a C compiler? In fact, I write in assembly to use the specifics of x86, the MMX the SSE instructions. As for a "minimal portable cpu", one based on x86 or other CPUs, powerful enough to represent anything and be efficient, but still translate efficiently to other CPUs could simply be a bytecode or semi-compiled language of some sort. Java for example, or other p-code thingys. (too many languages compile to p-code to list here... Java is a simple enough one for me to know) --Dragontamer
From: Betov on 8 Feb 2006 09:23
"Dragontamer" <prtiglao(a)gmail.com> ?crivait news:1139407866.049712.299530 @o13g2000cwo.googlegroups.com: > I write in assembly to use the specifics of x86, the MMX > the SSE instructions. Only HLLers can be interrested with those things. You know what? HLLers _NEED_ speed. Asmers _HAVE_ it. :) Betov. < http://rosasm.org > |