Two Click disassembly/reassembly [ASM]

From: Rod Pemberton on 8 Feb 2006 14:10

"?a\/b" <al(a)f.g> wrote in message
news:av9ju15rts73bctbt67m363mkn7gqofhvg(a)4ax.com...
> 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.

The 6502 assembly language could be reduced to only 13 instructions which
had the full capabitilities of the entire instruction set. No one ever did
that because it would be painfully slow. Most early 8-bit FORTHs implement
an 8-bit software CPU or "virtual machine." I think Phil Koopman determined
that there were only 20 FORTH primitives (assembly coded subroutines,
roughly an instruction) that were needed to develop a fast FORTH. The IA-32
architecture although CISC, has very RISC like instructions. In fact, from
my review of the IA-32 instruction set, I think it would be possible, for
"i586" and above CPU's, to develop a complete and fast C compiler which only
used a RISC-like subset of the IA-32 instruction set.

Rod Pemberton

From: randyhyde@earthlink.net on 8 Feb 2006 17:45

Charles A. Crayne 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.

"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

From: randyhyde@earthlink.net on 8 Feb 2006 17:51

From: Dragontamer on 8 Feb 2006 19:46

Betov wrote:
> "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.

It is nice to change your point of view to the stronger
argument.

BU_ASM->Introduction to the Assembly Rebirth by Rene
==========
The sub-line of such claims is always that Assembly is just good for
producing inline routines in order to improve the HLLs productions
performance quality and to overcome their limitations, but that writing
Applications in Assembly would be a strange idea coming from guys
unable to use ''the proper tool for the proper thing''.

These ideas are basically unfounded and stupid from every point of
view:

*If Assembly interest is the speed of produced Code, with the actual
Processors performances, the argument is very weak, and the Processors
evolutions will go on and on, pushing to stupid and dirty programming
methods.

*If Assembly interest is at the size of produced Code, the argument is
completely ridiculous, given the actual Hard Disks capacities and given
the modern OSes Memory Manager's performances.

==========

But all that aside, what is it? In your last post, you imply
that speed is a major advantage for writing in assembly.
While in BU_ASM, you claim it it is a weak argument.

And I know you say time and time again that you don't
write in assembly for speed, but for readability.

So which is it?

--Dragontamer

From: ?a/b on 9 Feb 2006 02:46

On 8 Feb 2006 06:11 -0800, "Dragontamer" <prtiglao(a)gmail.com> wrote:
>\\\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?

because i like more assembly than C, because i think there are many
routines and functions that have to be written in assembly (e.g.
numerical routines, OS routines, games etc)

>In fact, I write in assembly to use the specifics of x86, the MMX
>the SSE instructions.

i think like Betov: 25 instruction are enough; than can change cpu
registers size but the instructions are the same. to add more
instructons is not an advantage for an assembly programmer

>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)

i think
if "java-cpu" deal with *easy instructions* that can easily
implemented in any cpu, if cpu makers change their cpu for optimise
the "java-cpu" instructions then "java-cpu" will win

>--Dragontamer

First | Prev | Next | Last
Pages: 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Prev: Check out POASM
Next: Bad habits