Re: Two Click disassembly/reassembly

randyhyde@xxxxxxxxxxxxx wrote:
> 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
> thing.
>
>
> > 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.

OK, I see your point. However, there are some tasks that even a
compiler can't handle here. This;

ADD EAX, [EBX+10]

(in whatever x86 notation takes your fancy) would be better emulated on
a VM on the target processor than make the attempt to translate each
and every statement into a set of equivalent opcodes on the target. For
instance, using memory instead of registers, or emulating the stack
runs the problem of state; what state have I left at the last
instruction I generated code for? The above code leaves states of
overflow, zero, carry to name but a few. Now stick a label on it, and
jump to it from somewhere else. Because we need to retain states at run
time (we can't know them all at compile time), we're emulating, not
compiling.

It's worse with statements like

CALL $+5
POP EAX

That leaves the address of the POP in EAX. But there are architectures
where the IP must be on a 4byte boundary and where branch delay slots
are required to change the IP; like the MIPS. I'd like to see
line-by-line compilation of the equivalent into MIPS; it's a serious
challenge. There is a possible one opcode alternative, as the MIPS has
a single instruction (jal) that leaves the return address /plus eight/
(after the branch delay slot) in a register. But that needs lookahead
to identify that the target of the CALL is a POP; now it's a compiler
again, rather than a line by line assembler. And what if the POP was
reached from a CALL [EBX] miles away in the code? This is seriously
hard stuff, even for a very smart compiler, and territory best handled
by 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.

And Betov's x86 source/MIPS backend assembler (as an example, and if
possible) would be as slow, if not slower still.

>
> >
> > >
> > >>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 contend; not possible. There are too many variables to handle
with states and side effects. Thats why compiled languages deliberately
remove them.

[snipped]

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

Ah. Thank you. It still doesn't make sense, even when the terminology
is explained.

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

Please, let it be not Forth. I am an amateur Forth programmer, a keen
advocate and maintainer of a Forth compiler (part public domain, part
GPL). I couldn't bear the thought of Rene lecturing the "sub sh*ts" on
the "one true way" over on comp.lang.forth. Or of wannabee following
his prophet and dribbling incoherent replies to every post there.

--
Regards
Alex McDonald

.

Relevant Pages

  • Re: GCC inline assembler question
    ... any register you use has to be preserved. ... ABI that the compiler implements otherwise the compiler is going to get ... The mechanism in compilers like RVCT is an embedded assembler where the ... Development Systems ARM Limited. ...
    (comp.sys.arm)
  • Re: What does 32 bit application mean?
    ... Does this means that the compiler is ... Thus it corresponds to the register ... > assembler for 32 bit architecture. ... > [On all the modern machines I know, the register size and the address ...
    (comp.compilers)
  • Re: Help with Chosing Hardware / Software
    ... Can anyone who has experience with FORTRAN / X86 coding ... The ASM IDE package includes how-to info on making Linux system calls from ... compiler that allows custom command design and optimization. ... The compiler comes with the NASM assembler which uses the ...
    (comp.lang.asm.x86)
  • Re: Auto-preservation of non-volatile registers by inline assembler
    ... usage of non-volatile register). ... A translation of HLL to assembler is capable to ... to bypass the restrictions of your inline assembler. ... If the compiler emits assembler files on demand ...
    (comp.lang.asm.x86)
  • Re: checking if a floating point number is equal in value to an integer
    ... the value in the register is not exactly an integer, ... value stored in memory is an integer value. ... operations (and can be an issue on x86 if A is double). ... You can declare A to be VOLATILE (if your compiler supports ...
    (comp.lang.fortran)