Re: Two Click disassembly/reassembly

Alex McDonald wrote:
> OK, how about machines with fewer registers.

Map the extra x86 registers to memory. Accumulator and stack machines
(which are about the only machines with fewer registers than the x86)
generally have a decent access to memory.

> Flags in an addressable
> register.

What's so hard about that?

> No base/index/offset instructions.

As long as you've got indirection through a register and the ability to
add values together, you can certainly simulate this.

> Other than 32 bits.

If the target processor is less than 32-bits, you can use
multi-precision arithmetic. If the target processor is greater than 32
bits, you can *usually* ignore the extra bits and do everything with
just 32 bits. It may be painful in some cases, but it can be done.

> No
> equivalents to the string instructions.

So, you execute a sequence of instructions in a loop that do the same

> No stack register.

Use a different register for this purpose. Or use a memory location.

> Suddenly it
> looks like an x86 emulator,

No, it looks like a *compiler* rather than an *interpreter* (emulator).
And that means it will run about 2-10x faster than an emulator.

> and to be quite honest, it would be easier
> to write one than your mythical "encoder".

Certainly writing an interpreter is far easier than writing a compiler.
But the interpreter is *much* slower.

> >
> >>Otherwise what you'll be writing will no more be assembly than an HLL
> >>like C++ can be assembly.
> >
> >
> > _Evidently_. Yes. And then?
> >
> > You miss several details, in your post.
> >
> > Doing what i imagine, would be writting Assembly, at one
> > end (for one Processor), and outputing subtitutes on the
> > other end (other Assemblers >>> no more real Assembly).
> > And, if the number of Alien Processors, say, that Windows
> > is runing under, like the Pocket Computers ones, such an
> > implementation, even if bad, even if "no more Assembly",
> > even if whatever you would dislike, would be infinitively
> > better than _nothing_, and would, in all cases, at least,
> > remain pure Assembly, on the original's end.
> Eh?

Rene still doesn't understand the difference between a language and an
implementation of a language. You are forgiven for not understand what
the heck he is talking about.

In simple terms, he is describing an over-glorified macro processor
that translates each x86 assembly instruction into some comparable
sequence on a CPU found on a pocket PC or similar system. Of course,
the concept of optimization has never occurred to him, so the code he
would generate would be absolutely terrible.

> >
> > I would bet (i really do not know...)
> So stop, because you're right. You don't know.

You're right, he's right. He doesn't know :-)

> > that there are extreemely
> > few chances for a Pocket Computer runing Windows, that there
> > would be less than the usual x86 Registers. And as i never took
> > any look at this, i just did it for the ARM Processor... the
> > first doc i see, says that it offers 16 32Bits Registers. I did
> > not took a real look at the Instructions set, but, for what
> > i have seen when, looking in diagonale, there also are, MOV,
> > SUB, ADD, end so on. Not _that_ Alien, even if slightly
> > different.
> Now take a look at a MIPS processor. It's very different. In fact, it's
> got such a limited RISC like instruction set that the assembler is more
> like a macro processor; most of the "assembler opcodes" generate several
> machine instructions. You'd hate it. The mapping to x86 opcodes would be
> a serious unertaking; it would be several times more complex than a
> compiler or emulator.

The undertaking *would* be a compiler. The hard part is not generating
the sequence of instruction to emulate each x86 instruction, but
optimizing the result afterward.

> >
> > Also, you seem to have an HLLer's vision of Assembly. No, a
> > Minimalist Assembly, like the one i use everyday, is in no
> > way a problem. I am not the kind of guy who gives a try to
> > the SEE Instructions set, and who is surprised to see that
> > it works slower that trivial Instructions.
> Only if you don't understand SSE.

SSE? Heck, he doesn't understand half the *integer* instruction set.
And typical compilers use *far* more than the 20 or so instructions
Rene talks about. This means that a typical compiler for a HLL is going
to generate better code than Rene writes by hand simply because of the
richness of the instruction set that the compiler uses.

> > Optimizing at the
> > Code Level is reserved to the HLLers, because the reason why
> > they need speed is that... they have slowness.

Rene never writes HLL code. Therefore, he isn't in any position to talk
about how fast or slow *his* assembly code is compared to comparable
HLL code. Indeed, as he constantly talks about how speed and space are
not important, it's pretty obvious to even a casual observer that a
good optimizing compiler will probably beat him every time.

>> The guys who
> > Optimize Assembly at Code Level do simply not understand what
> > Assembly is, in 99% of the cases

Then again, at least they know (and use) a bigger chunk of the
instruction set...

> (There _are_ effectively cases
> > when Code Level Optimizations are required, but extreemely few).
> > Strategy Optimization can very unlikely be really degraded by
> > any degradation of the Code, you know.

And this "strategy optimization" cannot be applied by expert assembly
programmers? Or even HLL programmers? Why is this optimization only
available to people who limit themselves to using 20 or so
instructions, Rene?

> ??? What is a "Code Level Optimizations", as opposed to a "Strategy
> Optimization"? I've never seen these terms described.

He never really has defined these terms, but over the years I've come
to assume that "strategy optimization" means "pick an appropriate
algorithm." Of course, this optimization is not specific to assembly
language (and certainly not specific to someone who limits themselves
to 20 or so instructions). Obviously the same approach can be applied
by someone writing in a VHLL. And with a typical HLL optimizing
compiler that takes advantage of the full instruction set, the result
is going to be far better than the same approach used by someone who
limits themselves to a small subset of the instruction set. Of course,
the expert assembly language programmer who fully utilizes the
instruction set can also use this approach and achieve even more.

> >
> > So, it seems to me that, even if a little bit "degraded",
> > even if, in some limit-cases some alert messages should
> > be send to the programmer, even if a reduced set of
> > instructions should be recommanded,

Compilers for HLLs use a reduced set of instructions. Assembly
programmers don't have this limitation, Rene. As you would say,
"anyone with an IQ over 80" ought to be able to figure out how to use
all the instructions rather than limit themselves. The whole point of
assembly language is to do things that cannot be done in HLLs. If you
limit your use of the instruction set to a subset of what the HLL
compilers use, the advantages of assembly language disappear.

> in order to avoid the
> > complications, and so on... this should much probably be a
> > way more interresting track, than writing as many Sources,
> > for an App, as the number of targetted Processors.
> Then use an HLL, and stop talking junk. Really, you're blind to reason
> on the subject of portability.

Even ignoring portability. He's completely blind to the reasons for
using assembly language.

Rene reminds me of this Canadian guy, Roedy Green, from the 1990s
(though Roedy was a heck of a lot nicer). He used to be a *big*
supporter of assembly language. Everything was to be written in
assembly. One of the biggest supporters of assembly at the time. Then,
one day, he switched to Forth because of assembly's "limitations".
Someday, I expect the same sort of thing from Rene (probably when the
ReactOS team calls it quits).


Further notes on the subject of code translation:

Ever hear of "Rosestta"? It's a "just-in-time" compiler for PPC to x86
for the new Macs. Or how about the Java byte code engine? Again, JIT
compilation does a run-time translation from one (virtual) machine code
to another. Compilation of one processor's code to another is certainly
possible. As all modern CPUs are "Turing Complete", it's pretty obvious
that you *can* translate machine code for one CPU to any other. The
only question is what performance loss are you willing to pay? JITs
don't produce code that is as fast as a static compiler with a good
optimizer, but reports claim only about a 50% loss in performance going
from the PPC to the x86 (keeping in mind that the OS executes in native
code, this figure is probably closer to 75% for the actual translated
code). And this is going in a difficult direction (RISC with lots of
registers and few addressing modes to the x86).

Also note that there is no reason you couldn't compile x86 assembly
language into a HLL like C. Sure, no stack, no registers, but you can
certainly create software versions of all this stuff. Yep, the result
would run slow, but it *would* run. Indeed, the translation would be
pretty easy. You'd get something like this:

mov esi, ptr1
mov edi, ptr2
mov ecx, 1000h
rep movsb

to the following C code:

mov( esi, ptr1 ); // These could be macros if you don't want the
mov( edi, ptr2 ); // of a function call.
mov( ecx, 0x1000 );
memcpy( edi, esi, ecx );

Subroutines would be interesting, but if you've got a compiler like GCC
that allows pointers to labels, it's not hard at all.

Randy Hyde