Re: Two Click disassembly/reassembly

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


> alternatively, the user has to take care to only use instructions that
> _do_ have an equivalents. that would be crippling the power of
> assembly, which is one of it's big advantages.

There is no inconvenient at using a very reduced set
of the instructions of a Processor. This is what i do
everydays, and i push the users to do the same: Learn
as few as possible // do as much as possible. Learn
when _necessary_, not when useless. Learning takes
time, and when useless, this is wasted time. And for
the ones who could say that i am joking, the answer is
automatic: "RosAsm is extreemely fast, easy to develop
and easy to maintain".


>> But it is nevertheless very possible, and it
>> could even be made "easy" by reducing the number of OpCodes
>> to the ones in real use.
>
> Terrible. All this will allow is to do trivial things across many CPUs
> but not exploit the more advanced features of any of them.

To me, there is no advantage at using "the more advanced
features". Only inconvenients.


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


>> (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].


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

I would bet (i really do not 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.

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

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.


Betov.

< http://rosasm.org >








.