Re: Two Click disassembly/reassembly

Betov wrote: 
"santosh" <santosh.k83@xxxxxxxxx> écrivait news:1138025781.873803.322670
@g43g2000cwa.googlegroups.com:


Correct me if I'm wrong, but I think you mean an encoder which
substitutes the opcodes of an x86 encoder to the opcodes of it's
targeted processor. am I right?



Yes.



If so, then what about x86 opcodes which have no equivalents for the
cPU to which we are translating to. if our encoder goes ahead and
translates, it would break our program.



It depends on what you mean with "No equivalent"...
there may be, "No equivalent" but that can be emulated
by "Substitutions Sets", and there may be "No equivalent"
with not any capacity of substitution... Difficult to
imagine (to me...) for a Processor that would be able
to execute the same OS.

Linux on any number of non-x86 platforms for instance. There's more to the world than x86 Windows.

[inconvenient opcodes snipped]

This could be called a kind of
minimalist portable Assembler, but, so said, there is no
theorical possibility why any Instruction could not be
translated into a substitute


Not if the target CPU has no real equivalent instruction. For example,
a DSP might not have any facilities for memory management, debugging
etc. So how will your "substitute" encoder translate an x86 program
with opcodes/instructions using these features to the
opcodes/instructions for the DSP.



You are right, here. But is this a real case, when talking
of Processors able to execute a same given OS ?


Linux (again). What cave have you been living in?




(set, eventualy...). _Bad_,
evidently, on the substitutes side, but also evidently,
nothing but what the so called "portable" HLLs do.


Absolutely not. HLLs translate your HLL statements to _native_ assembly
instructions of the CPU for which your are compiling. The instruction
_sequence_ might not be as efficient as hand assembly by a knowledgeble
assembly programmer, but no "substitutions" are done. For each targeted
CPU, a seperate opcode generator is written.



??? And what does make it impossible, for an Assembler to
output the same substitution *** as an HLL ??? [I mean
"substitution ***" when no direct equivalent and direct
equivalent (or "almost equivalent"...) otherwise].

OK, how about machines with fewer registers. Flags in an addressable register. No base/index/offset instructions. Other than 32 bits. No equivalents to the string instructions. No stack register. Suddenly it looks like an x86 emulator, and to be quite honest, it would be easier to write one than your mythical "encoder".


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?


I would bet (i really do not know...) 

So stop, because you're right. You don'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.


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.

Optimizing at the
Code Level is reserved to the HLLers, because the reason why
they need speed is that... they have slowness. The guys who
Optimize Assembly at Code Level do simply not understand what
Assembly is, in 99% of the cases (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.

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


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

--
Regards
Alex McDonald
.