Re: Two Click disassembly/reassembly

"santosh" <santosh.k83@xxxxxxxxx> écrivait news:1138007082.991416.260850
@g49g2000cwa.googlegroups.com:

> The better way is to have a set of front and back ends, each for a CPU
> family. In that way, each front and back end would accept and parse the
> native assembly syntax of it's target CPU and generate it's opcodes.
> The appropriate front and back ends can be automatically called by the
> driver program, either via a command-line switch or a 'syntax' or 'cpu
> type' directive at the beginning of the source file.
>
> Of course, practically speaking, this is equivalent to writing several
> assemblers, each for a CPU family. When coding even _one_ assembler
> properly is so much work, who would be vain enough/competent enough to
> undertake this project?

You are in some way right, but you are confusing Assembler
and Encoder. Writing an Assembler is around 2, 3 or 4 years
(depending, for example, on the complexity of the Macros
Engine, on the Flexibility of the Syntax, and so on). Whereas
writing an Encoder is a matter of Months.

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. 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. 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 (set, eventualy...). _Bad_,
evidently, on the substitutes side, but also evidently,
nothing but what the so called "portable" HLLs do.

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. But
not yet HLL, for sure, because of the "way of thinking", at
the origine of the App construction. Such a Tool would have
its natural usage for Apps runing under some OS, like Windows,
runing under different Processors, and its natural interrest
in the fact of not having to rewrite it all for each damned
processor around, which number - i would bet - will tend to
explode, in the futur. Again, nothing but what the HLL do.

Now, how many hands for the job... :((( ... as usual.


Betov.

< http://rosasm.org >




.

Relevant Pages

  • The never ending assembly vs. HLL war
    ... > branch instruction excluded is not particularly effective optimization. ... > CPU, chances are pretty good it *won't* be optimal on a different CPU. ... > discussing the futility of optimizing it in *assembler* when the ... careful and consider the code the compiler is emitting (and adjust your ...
    (comp.lang.asm.x86)
  • Re: The War On HLA
    ... Different platforms support different models. ... you will be a better HLL programmer--and ... Even in a CPU as simple as the 8088, ... assembler won't tell you that. ...
    (alt.lang.asm)
  • Re: Can this loop be made faster ?
    ... > rather fast a HLL-like language might suit better than macros... ... are all different internally - the "shader assembly language" that DirectX ... they can have their own assembler and compilers and graphics-specific HLLs ... CPU" in the hardware... ...
    (alt.lang.asm)
  • Re: teaching OO
    ... to me the foundation of CS is abstract algorithmic thought, not a CPU; ... some feel it's best to start with assembler. ... you'd be writing MIX or some other fake assembler for a fake CPU. ... CPU in Python, and start programming it. ...
    (comp.lang.python)
  • Re: Is PSHUFW instruction MMX or SSE or SSE2? Is NASM manual correct?
    ... The CPU is a dead thing, ... remember all the most in used instructions. ... Scripting is not related to coding. ... Sure, if Windows or Word would be coded in assembler, it would be extremely ...
    (alt.lang.asm)