Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: Betov on 23 Jan 2006 04:33 "santosh" <santosh.k83(a)gmail.com> ?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 >
From: Betov on 23 Jan 2006 05:36 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:eZadnT1q8IsWAEnenZ2dnUVZ_sCdnZ2d(a)comcast.com: > If you believe in portable (across architectures) assembly, I'll see if > I can dig up Scot Nudds' address. No, i do not believe in a cross architectures Assembly. This does not make any sense to me... unless the name would be... C. I am just saying that, once you have written an Application in Assembly, if the used Assembler has an implemented Flag for Encoding "for this or for that", There is absolutely nothing, on a theorical point of view, saying that it would impossible to substitute the original OpCodes with remplacements, for Compile, as long as this is nothing but what the so called "portable" HLLs do. Cross Architectures Assembly would imply defining a "super-set to them all", where no version, at all, could ever deserve the name of Assembly. Another way, is with writting one version of an Application, for each Processor, either with a Flag saying which Encoder (in the given Assembler) to fire on the given Code, or even (as already done) to have one separated version of the given Assembler with a different Encoders. These two solutions are, in no way "Ported Assembler". They are "Assemblers", that is, they imply having as many Sources versions as targetted Processors... What nobody would really want to have. Again, an Assembler is _not_ an Encoder, even if tons of home-made Assemblers (for DOS, for example), are not anything significatively more than Encoders. Betov. < http://rosasm.org >
From: santosh on 23 Jan 2006 09:16 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.
From: randyhyde@earthlink.net on 23 Jan 2006 12:02 Frank Kotler wrote: > > Compiling 'rhbottle.hla' to 'rhbottle.asm' > using command line [hlaparse -v -sg -test "rhbottle.hla"] > > > And there it ends. Like Bernd's RedBlackTree, this is leaving me with > zero-length (.asm and .inc) files. The "index size" message is familiar > from that problem, too. If you'll recall, I finally *did* get > RedBlackTreeTest working, by deleting a couple of innocuous lines in > "macros.hhf", ignoring a bunch of error messages from hla, and running > as and ld "by hand". Hmm... I'll have to back up a version in HLA (so I'm using the same version most people are rather than the latest development version) and see if your problems are due to several defects I've corrected in the latest version. I wanted to finish the STL and TERMINAL class libraries before the next release of HLA, but I may need to put out a new version just to get the current bug fixes out there. Then again, I suspect you're compiling under Linux (based on the command line above) and I've not tested this code under Linux in a couple of months. I've really got to get my new Linux box functional so I can test the new code under Linux again. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 23 Jan 2006 12:05
Evenbit wrote: > > I am not able to try it on Linux at the moment. But I am confident > that you are correct in pointing the finger at HLA's macro-processing. > The issue is not limited to Linux. If you can recall a time many blue > moons ago (or craw amoung the cobwebs in ALA's dark cave repository) > when Randy suggested an Object-Oriented Syntax and provided some macro > code to test the concept with; I took the liberty of extending the > code. When my code failed to compile, Randy said something about > mumble bugs with multiple macro definitions mumble mumble jerry-rigged > mumble Flex/Bison mumble. Said he wouldn't fix it because it would be > easier to impliment proper macro processing in the HLA 2.0 release than > to further mumble jerry-rig mumble current 1.x prototype. He told me > to occasionally insert abitrary constants in-between multiple macro > definitions as a temporary work-around while we all wait for the HLA > 2.0 product. I tried the work-a-round [see "xoos.hhf" in the FILES > section] but it still will not compile. This is why I never use macros > when writing HLA code. > > Nathan. Actually, what I said is that Bison has a one symbol lookahead and that this operation skips over all compile-time statements (executing them). Therefore, in some *rare* cases you're going to have to put some sort of run-time construct (e.g., a semicolon or other object that doesn't disappear at compile time) between two constructs. The problem you're describing is sufficiently rare that it's *not* worth giving up macros over. :-) BTW, HLA v2.0 does handle the case properly. Cheers, Randy Hyde |