Re: Two Click disassembly/reassembly

Betov wrote:
> Writing as many Encoders as supported Processors is a thing
> that exists (already been done). Writing a set of substitutions
> Encoders is a thing that, as far as can know, has never been done
> for an Assembler.

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?

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.

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.

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

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

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

However because assembly, by it's very nature, uses all the
_particular_ features of a CPU like it's registers, addressing modes,
special control commands etc., and because these vary drastically from
CPU to CPU, a "substitution" encoder would be reduced to the Common
Minimum Subset among these CPUs.

Even if such a strategy doesn't break most programs, the set of
available instructions would be so few, that the reason for doing it in
assembly would be lost. Might as well switch to _truly_ portable HLL.

> Now, for such an hypothetic Tool, the original version would
> keep the name of Assembly, whereas the substituted versions
> would diserve another Name. "Ported Asm" :))))) maybe.

"Crippled, substituted, broken Asm, worse than optimised HLL
implementations"

The way to go towards _portable_ assembler, (the whole concept is very
difficult if at all possible, atleast not completely), is to develop a
portable syntax.

In this way, you use certain common conventions in syntax across many
cpus and your assembler has a seperate parser and encoder for each such
_subset_ of the common syntax.

Even then, in Assembly, you simply HAVE TO remenber the peculiarities
of each processor for which you're coding, like register names,
numbers, valid memory addressing modes, special processor specific
instructions, initialisations, etc.

Otherwise what you'll be writing will no more be assembly than an HLL
like C++ can be assembly.

That is the at once the biggest disadvantage and biggest advantage of
the assembly programmmer.

Forced to relearn (to an extent) for each cpu family, but also gain the
understanding and knowledge to use the _full_ capabilities of each cpu
in a way that few HLLs can come close to doing so.

.

Relevant Pages

  • Re: Assembly Console Programming in Windows
    ... And then each programmer would be happy, not having to put up with the ... Then why did *you* write yet another assembler? ... Who's going to make such decisions in a "single" encoder? ... That single encoder could be NASM or Gas. ...
    (alt.lang.asm)
  • Re: Two Click disassembly/reassembly
    ... saying that it would impossible to substitute ... Cross Architectures Assembly would imply defining a ... saying which Encoder (in the given Assembler) to fire ... Again, an Assembler is _not_ an Encoder, even if tons ...
    (alt.lang.asm)
  • Re: Wheels falling off CLAX again ?
    ... > assembler written in asm. ... All you need for writting non-x86 Code, with an Assembler ... And, if you believe that "Assembler = Encoder", you must ...
    (alt.lang.asm)