Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: randyhyde@earthlink.net on 24 Jan 2006 12:48 Alex McDonald wrote: > > OK, how about machines with fewer registers. Map the extra x86 registers to memory. Accumulator and stack machines (which are about the only machines with fewer registers than the x86) generally have a decent access to memory. > Flags in an addressable > register. What's so hard about that? > No base/index/offset instructions. As long as you've got indirection through a register and the ability to add values together, you can certainly simulate this. > Other than 32 bits. If the target processor is less than 32-bits, you can use multi-precision arithmetic. If the target processor is greater than 32 bits, you can *usually* ignore the extra bits and do everything with just 32 bits. It may be painful in some cases, but it can be done. > No > equivalents to the string instructions. So, you execute a sequence of instructions in a loop that do the same thing. > No stack register. Use a different register for this purpose. Or use a memory location. > Suddenly it > looks like an x86 emulator, No, it looks like a *compiler* rather than an *interpreter* (emulator). And that means it will run about 2-10x faster than an emulator. > and to be quite honest, it would be easier > to write one than your mythical "encoder". Certainly writing an interpreter is far easier than writing a compiler. But the interpreter is *much* slower. > > > > >>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? Rene still doesn't understand the difference between a language and an implementation of a language. You are forgiven for not understand what the heck he is talking about. In simple terms, he is describing an over-glorified macro processor that translates each x86 assembly instruction into some comparable sequence on a CPU found on a pocket PC or similar system. Of course, the concept of optimization has never occurred to him, so the code he would generate would be absolutely terrible. > > > > > I would bet (i really do not know...) > > So stop, because you're right. You don't know. You're right, he's right. He doesn'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. The undertaking *would* be a compiler. The hard part is not generating the sequence of instruction to emulate each x86 instruction, but optimizing the result afterward. > > > > > 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. SSE? Heck, he doesn't understand half the *integer* instruction set. And typical compilers use *far* more than the 20 or so instructions Rene talks about. This means that a typical compiler for a HLL is going to generate better code than Rene writes by hand simply because of the richness of the instruction set that the compiler uses. > > > Optimizing at the > > Code Level is reserved to the HLLers, because the reason why > > they need speed is that... they have slowness. Rene never writes HLL code. Therefore, he isn't in any position to talk about how fast or slow *his* assembly code is compared to comparable HLL code. Indeed, as he constantly talks about how speed and space are not important, it's pretty obvious to even a casual observer that a good optimizing compiler will probably beat him every time. >> The guys who > > Optimize Assembly at Code Level do simply not understand what > > Assembly is, in 99% of the cases Then again, at least they know (and use) a bigger chunk of the instruction set... > (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. And this "strategy optimization" cannot be applied by expert assembly programmers? Or even HLL programmers? Why is this optimization only available to people who limit themselves to using 20 or so instructions, Rene? > > ??? What is a "Code Level Optimizations", as opposed to a "Strategy > Optimization"? I've never seen these terms described. He never really has defined these terms, but over the years I've come to assume that "strategy optimization" means "pick an appropriate algorithm." Of course, this optimization is not specific to assembly language (and certainly not specific to someone who limits themselves to 20 or so instructions). Obviously the same approach can be applied by someone writing in a VHLL. And with a typical HLL optimizing compiler that takes advantage of the full instruction set, the result is going to be far better than the same approach used by someone who limits themselves to a small subset of the instruction set. Of course, the expert assembly language programmer who fully utilizes the instruction set can also use this approach and achieve even more. > > > > > 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, Compilers for HLLs use a reduced set of instructions. Assembly programmers don't have this limitation, Rene. As you would say, "anyone with an IQ over 80" ought to be able to figure out how to use all the instructions rather than limit themselves. The whole point of assembly language is to do things that cannot be done in HLLs. If you limit your use of the instruction set to a subset of what the HLL compilers use, the advantages of assembly language disappear. > 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. Even ignoring portability. He's completely blind to the reasons for using assembly language. Rene reminds me of this Canadian guy, Roedy Green, from the 1990s (though Roedy was a heck of a lot nicer). He used to be a *big* supporter of assembly language. Everything was to be written in assembly. One of the biggest supporters of assembly at the time. Then, one day, he switched to Forth because of assembly's "limitations". Someday, I expect the same sort of thing from Rene (probably when the ReactOS team calls it quits). ***************************** Further notes on the subject of code translation: Ever hear of "Rosestta"? It's a "just-in-time" compiler for PPC to x86 for the new Macs. Or how about the Java byte code engine? Again, JIT compilation does a run-time translation from one (virtual) machine code to another. Compilation of one processor's code to another is certainly possible. As all modern CPUs are "Turing Complete", it's pretty obvious that you *can* translate machine code for one CPU to any other. The only question is what performance loss are you willing to pay? JITs don't produce code that is as fast as a static compiler with a good optimizer, but reports claim only about a 50% loss in performance going from the PPC to the x86 (keeping in mind that the OS executes in native code, this figure is probably closer to 75% for the actual translated code). And this is going in a difficult direction (RISC with lots of registers and few addressing modes to the x86). Also note that there is no reason you couldn't compile x86 assembly language into a HLL like C. Sure, no stack, no registers, but you can certainly create software versions of all this stuff. Yep, the result would run slow, but it *would* run. Indeed, the translation would be pretty easy. You'd get something like this: mov esi, ptr1 mov edi, ptr2 mov ecx, 1000h rep movsb to the following C code: mov( esi, ptr1 ); // These could be macros if you don't want the overhead mov( edi, ptr2 ); // of a function call. mov( ecx, 0x1000 ); memcpy( edi, esi, ecx ); Subroutines would be interesting, but if you've got a compiler like GCC that allows pointers to labels, it's not hard at all. Cheers, Randy Hyde
From: Alex McDonald on 24 Jan 2006 14:00 randyhyde(a)earthlink.net wrote: > Alex McDonald wrote: > > > > OK, how about machines with fewer registers. > > Map the extra x86 registers to memory. Accumulator and stack machines > (which are about the only machines with fewer registers than the x86) > generally have a decent access to memory. > > > Flags in an addressable > > register. > > What's so hard about that? > > > No base/index/offset instructions. > > As long as you've got indirection through a register and the ability to > add values together, you can certainly simulate this. > > > > Other than 32 bits. > > If the target processor is less than 32-bits, you can use > multi-precision arithmetic. If the target processor is greater than 32 > bits, you can *usually* ignore the extra bits and do everything with > just 32 bits. It may be painful in some cases, but it can be done. > > > > No > > equivalents to the string instructions. > > So, you execute a sequence of instructions in a loop that do the same > thing. > > > > No stack register. > > Use a different register for this purpose. Or use a memory location. > > > Suddenly it > > looks like an x86 emulator, > > No, it looks like a *compiler* rather than an *interpreter* (emulator). > And that means it will run about 2-10x faster than an emulator. OK, I see your point. However, there are some tasks that even a compiler can't handle here. This; ADD EAX, [EBX+10] (in whatever x86 notation takes your fancy) would be better emulated on a VM on the target processor than make the attempt to translate each and every statement into a set of equivalent opcodes on the target. For instance, using memory instead of registers, or emulating the stack runs the problem of state; what state have I left at the last instruction I generated code for? The above code leaves states of overflow, zero, carry to name but a few. Now stick a label on it, and jump to it from somewhere else. Because we need to retain states at run time (we can't know them all at compile time), we're emulating, not compiling. It's worse with statements like CALL $+5 POP EAX That leaves the address of the POP in EAX. But there are architectures where the IP must be on a 4byte boundary and where branch delay slots are required to change the IP; like the MIPS. I'd like to see line-by-line compilation of the equivalent into MIPS; it's a serious challenge. There is a possible one opcode alternative, as the MIPS has a single instruction (jal) that leaves the return address /plus eight/ (after the branch delay slot) in a register. But that needs lookahead to identify that the target of the CALL is a POP; now it's a compiler again, rather than a line by line assembler. And what if the POP was reached from a CALL [EBX] miles away in the code? This is seriously hard stuff, even for a very smart compiler, and territory best handled by an emulator. > > > and to be quite honest, it would be easier > > to write one than your mythical "encoder". > > Certainly writing an interpreter is far easier than writing a compiler. > But the interpreter is *much* slower. And Betov's x86 source/MIPS backend assembler (as an example, and if possible) would be as slow, if not slower still. > > > > > > > > >>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? > > Rene still doesn't understand the difference between a language and an > implementation of a language. You are forgiven for not understand what > the heck he is talking about. > > In simple terms, he is describing an over-glorified macro processor > that translates each x86 assembly instruction into some comparable > sequence on a CPU found on a pocket PC or similar system. Of course, > the concept of optimization has never occurred to him, so the code he > would generate would be absolutely terrible. I would contend; not possible. There are too many variables to handle with states and side effects. Thats why compiled languages deliberately remove them. [snipped] > > ??? What is a "Code Level Optimizations", as opposed to a "Strategy > > Optimization"? I've never seen these terms described. > > He never really has defined these terms, but over the years I've come > to assume that "strategy optimization" means "pick an appropriate > algorithm." Of course, this optimization is not specific to assembly > language (and certainly not specific to someone who limits themselves > to 20 or so instructions). Obviously the same approach can be applied > by someone writing in a VHLL. And with a typical HLL optimizing > compiler that takes advantage of the full instruction set, the result > is going to be far better than the same approach used by someone who > limits themselves to a small subset of the instruction set. Of course, > the expert assembly language programmer who fully utilizes the > instruction set can also use this approach and achieve even more. > Ah. Thank you. It still doesn't make sense, even when the terminology is explained. > > Rene reminds me of this Canadian guy, Roedy Green, from the 1990s > (though Roedy was a heck of a lot nicer). He used to be a *big* > supporter of assembly language. Everything was to be written in > assembly. One of the biggest supporters of assembly at the time. Then, > one day, he switched to Forth because of assembly's "limitations". > Someday, I expect the same sort of thing from Rene (probably when the > ReactOS team calls it quits). Please, let it be not Forth. I am an amateur Forth programmer, a keen advocate and maintainer of a Forth compiler (part public domain, part GPL). I couldn't bear the thought of Rene lecturing the "sub sh*ts" on the "one true way" over on comp.lang.forth. Or of wannabee following his prophet and dribbling incoherent replies to every post there. -- Regards Alex McDonald
From: ~o/~///annabee on 24 Jan 2006 14:54 //Please, let it be not Forth. I am an amateur Forth programmer, a keen advocate and maintainer of a Forth compiler (part public domain, part GPL). I couldn't bear the thought of Rene lecturing the "sub sh*ts" on the "one true way" over on comp.lang.forth. Or of wannabee following his prophet and dribbling incoherent replies to every post there. -- Regards Alex McDonald // Whine whine whine. "This loop cant do signed integers" "This code cant port hardware" Save up for an operation to surgically remove that large piece of scrap metal someone showed up your ars. Maybe just operate it into your brain. It could not help much, but from what you are posting latly it could surly not hurt much either.
From: Alex McDonald on 24 Jan 2006 15:41 \~o/~///annabee wrote: > //Please, let it be not Forth. I am an amateur Forth programmer, a keen > > advocate and maintainer of a Forth compiler (part public domain, part > GPL). I couldn't bear the thought of Rene lecturing the "sub sh*ts" on > the "one true way" over on comp.lang.forth. Or of wannabee following > his prophet and dribbling incoherent replies to every post there. > > > -- > Regards > Alex McDonald > // > > Whine whine whine. > > "This loop cant do signed integers" That's a good point; I never did complete the analysis of why n > 0 (or n < 0 for that matter) for unsigned n doesn't make sense, and should be n != 0. I lost interest to be honest, and I've been distracted by writing code. Some of it includes signed tests. > "This code cant port hardware" > > Save up for an operation to surgically remove that large piece of scrap > metal someone showed up your ars. Maybe just operate it into your > brain. It could not help much, but from what you are posting latly it > could surly not hurt much either. > Ah, back to form I see. Is thinking before posting really that hard for you? -- Regards Alex McDonald
From: look and see on 24 Jan 2006 17:31
----- Original Message ----- From: "sevagK" Newsgroup: alt.lang.asm Sent: Tuesday, January 24, 2006 16:49:07 GMT Subject: Re: Two Click disassembly/reassembly > If I remember correctly, someone already did an ARM port for FASM. > Check it out on the fasm forum. The topic has been viewed 2454 times and the source code downloaded 325 times. http://board.flatassembler.net/topic.php?t=4191 Mike Gonta look and see - many look but few see http://mikegonta.com |