Re: Two Click disassembly/reassembly


Charles A. Crayne wrote:
On 7 Feb 2006 21:14:35 -0800
"randyhyde@xxxxxxxxxxxxx" <randyhyde@xxxxxxxxxxxxx> 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.

"Marketing hype?"
This is standard assembly language programming stuff we're talking
about here. I.e., the main reason assembly language programmers can
still write better code than compilers.

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.

It is trading a *lot* of performance. And accuracy. And effort on the
part of the programmer. Worse, it tries to gain performance at the cost
of less accuracy and more work on the part of the end user. This is my
major gripe.



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.

Did I ever claim that you do? OTOH, you do have a vested interest in
the argument.

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.

Yep. Rene has probably figured out by now that this concept is way
beyond his capabilities to implement :-).



: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

Again, we're back to the "compilers vs. humans" argument. No matter
*how* good a compiler may be, it cannot make up for some *really
stupidly written* HLL code. Likewise, no matter how good this x86->PPC
translator is, it cannot make up for the fact that a line by line
translation of x86 code to PPC just isn't going to be very good. Unless
they write their code to divine the semantics of the original x86 code
and write an equivalent program (using the PPC programming paradigm) to
accomplish the same thing, the results are going to stick. It's like
the argument about "writing FORTRAN with semicolons" (applied to C or
Pascal) or "writing APL and thinking in FORTRAN." You just don't get
decent code when you're not thinking in the target language. And thus
far, optimizations included, I've yet to see any hint that the
PortASM/86 product does this. I would be *very* impressed if it did, as
this is a very difficult problem to solve.


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.

Actually, emulation of the x86 register structure is done reasonably
well. What it doesn't seem to do is use registers in place of memory as
often as is possible. This is where a RISC architecture *really shines*
over CISC. You *don't* want to touch memory unless you absolutely have
to. Alas, with the limited x86 register set you have no choice; but
with the 32 PPC general-purpose registers, you can write functions that
rarely go to memory other than for processing large data structures.
And this is the main failing of PortASM/x86 -- it fails to make this
type of translation. But this is *exactly* the kind of thing a human
(PPC) programmer would do. Not only does this make the result faster,
but it also makes it easier for the next PPC programmer who comes along
and doesn't have to question why the program is accessing memory so
often.




: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?

Roughly the same number of lines of code as an x86 programmer. Given
equal experience, of course.


: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?

I don't know your code or how much time you put into it. But I would
imagine that if you were an expert at both x86 and PPC code, you'd
probably be able to convert at least 100-500 lines of code per day,
testing included (we'll assume it's already documented, and that design
is not an issue; that leaves coding and testing; presumably, testing is
easier because you've already got functional test suites for your
program, though code coverage tests have to be redesigned).
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Using DB
    ... If on the other hand, you are not a programmer, and just figure there must ... be a DB for the PPC that also works on the PC, ... if asked in a newsgroup for programmers. ...
    (microsoft.public.pocketpc)
  • Re: Ten years later
    ... But "x86 assembly language programmer" probably wouldn't need ... requirements statement by calling oneself an "x86 nasm assembly language ...
    (alt.lang.asm)
  • Re: simple assembler question
    ... is absolutely nonses. ... My assembly language knowledge is a bit outdated ... I just digged in the "Intel Assembler For Intel XScale Microarchitecture ... I don't have handy access to a PPC machine so ...
    (comp.sys.mac.programmer.help)
  • Re: State of MorphOS?
    ... Given Apple's recent announcement of moving Macs to Intel, and IBM more interested in supplying low cost PPC chips to all three major game console vendors, I hate to say it, but MorphOS developers would probably do well to *seriously* consider moving to either x86 or possibly IBM's Cell architecture. ... It is a shame however, as the architecture still holds a lot of promise, but IBM isn't willing to invest the R&D to scale it up, nor is Apple, and Freescale just doesn't have IBM's resources to do the same either in any timeframe that will keep it competitive with AMD or Intel's roadmaps. ... do a multicore variant of AMD's x86with a PPC core thrown in. ...
    (comp.sys.amiga.morphos)
  • [Full-disclosure] OSX - Multi arch shellcode.
    ... I was recently playing with the osx86 install on my friends developer ... I have written some shellcode which will work on Mac OS X running on ... both ppc32 and x86 architecture. ... * for osx (both the ppc and x86 version.) ...
    (Full-Disclosure)