Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: o///annabee on 24 Jan 2006 03:05 P? Tue, 24 Jan 2006 01:58:16 -0500, skrev Frank Kotler <fbkotler(a)comcast.net>: > Funny no one has done it. Perhaps they lack Betov's "vision"... Anyway. Why do you think it could not be done? > Best, > Frank
From: Frank Kotler on 24 Jan 2006 03:36 \\\o///annabee wrote: .... > Anyway. Why do you think it could not be done? Jesus! This is where I came in... Since I'm not familiar with other architectures, I'm not a good one to give you a concrete example of the problems you'd encounter. It might be instructive to imagine doing this from some other architecture to x86. Here's some ppc code snatched at random from the "arch" directory. There exists an assembler (Gas) which makes ppc opcodes out of this. How would you go about altering Gas to generate x86 opcodes from this? [snip - it's GPL] .text /* * Use the BAT0 registers to map the 1st 8MB of RAM to 0x90000000. */ .globl setup_bats setup_bats: mfpvr 3 rlwinm 3,3,16,16,31 /* r3 = 1 for 601, 4 for 604 */ cmpi 0,3,1 lis 4,0x9000 bne 4f ori 4,4,4 /* set up BAT registers for 601 */ li 5,0x7f b 5f 4: ori 4,4,0xff /* set up BAT registers for 604 */ li 5,2 mtdbatu 3,4 mtdbatl 3,5 5: mtibatu 3,4 mtibatl 3,5 isync blr /* * Flush the dcache and invalidate the icache for a range of addresses. * * flush_cache(addr, len) */ .global flush_cache flush_cache: addi 4,4,0x1f /* len = (len + 0x1f) / 0x20 */ rlwinm. 4,4,27,5,31 mtctr 4 beqlr 1: dcbf 0,3 icbi 0,3 addi 3,3,0x20 bdnz 1b sync isync blr Don't ask me what in hell it does, you were the one who claimed it was "simple"! I may have selected code which *does* translate easily to x86 - perhaps someone familiar with ppc will tell us if this is the case... Best, Frank
From: Betov on 24 Jan 2006 05:36 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:ULedndj42Z-iekjeRVn- uQ(a)comcast.com: > Don't ask me what in hell it does, Same for me. :))))) > you were the one who claimed it was > "simple"! No. Half said that the _idea_ was simple. He did not said (and neither said i) that it would be simple to implement. > I may have selected code which *does* translate easily to x86 > - perhaps someone familiar with ppc will tell us if this is the case... This does not, in any way answer to the question about _why_ outputing equivalent substitutions (even if several required for one, and therefore _evidently_ "no more Assembly"),... could not be done. Why i have this idea is because of the commercial explosure of the small pocket computers, with Processors like ARM... The costs are now so incredibly low, that this is becoming an interresting "side-market" for many things we develop on PCs. So, why wouldn't it be possible to give a try to something like this. Admiting there would be some real impossibility, this would be, at least a wonderful help for creating a port, in true Assembly (in such a case), with a signifive "partial automation" of the port job. As you know the x86 Opcodes are several hundreads, but, when you disassemble anything, all you see, is around 20 instructions (a little bit more if there are intensive FPU calculations...). So which example could be found, in real life, that could not be applied such substitutions, because of completely missing concept(s) as a given bu the x86 Mnemonic? The first thingie, i take a look about, is this Arm thingie (that is effectively sold with Windows OS). A quick look does not show to me any "can't do"... All i see tends to show me the reverse, that is, that the equivalencies are so evident, that, maybe, even true Assembly Substitutions could be possible and therefore, that the "Ported Assembly" could eventualy be very close to true Assembly. Again, you insist strangely on the "No more Assembly" point, which is a quite absurd thing to say to me, as i say exactely the same, if there is no 1:1 Substitution for such and such. My point is not with making true Assembly Processors substitutions if not possible. My point is that without "Ported Assembly" i cannot have any of my Applications runing on such "market niches" (unless i rewrite it all, one time for each). Where would the substitutions idea fail in real world? The only answer i got, up to now, was an example with direct usage of the Debug Registers, that would not exist on "xxxx Processor". Well, not exactely what we would call an "everydays real world Apps", is it? So, what else? Betov. < http://rosasm.org >
From: Frank Kotler on 24 Jan 2006 09:10 Betov wrote: > Frank Kotler <fbkotler(a)comcast.net> ?crivait news:ULedndj42Z-iekjeRVn- > uQ(a)comcast.com: [ppc code] >>Don't ask me what in hell it does, > > Same for me. :))))) Well, perhaps neither of us is qualified to even be having this discussion. But that won't stop us! :) Seriously, I *don't* know enough about other architectures to be able to come up with problems you'd have in "real world" code. I've gotten the impression that there are some. I suppose it depends on "which architecture". >>you were the one who claimed it was >>"simple"! > > No. Half said that the _idea_ was simple. He did not said > (and neither said i) that it would be simple to implement. Okay, the idea is simple. The idea is obvious. No one has implemented it. "Too" difficult to implement? Maybe... >>I may have selected code which *does* translate easily to x86 >>- perhaps someone familiar with ppc will tell us if this is the case... > > This does not, in any way answer to the question about > _why_ outputing equivalent substitutions (even if several > required for one, and therefore _evidently_ "no more > Assembly"),... could not be done. Okay, as long as we're agreed that it's "no more assembly". As I understand it, you're talking about combining an assembler and a compiler into a single executable. I suppose this could be done. Whether it's a good idea is probably a matter of opinion. I'm inclined towards "do one thing, and do it well". You seem to like "fully integrated" thingies, so our opinions might differ... > Why i have this idea is because of the commercial explosure > of the small pocket computers, with Processors like ARM... > The costs are now so incredibly low, that this is becoming > an interresting "side-market" for many things we develop on > PCs. Right. I don't know ARM, but there was an idea (some time ago) to extend Nasm to ARM. I get the impression that it's fairly "close" to x86. If so, there may be enough "equivalent" instructions (or few enough "unequivalent" instructions) to make something like this possible. > So, why wouldn't it be possible to give a try to something > like this. It would be possible to give a try to *anything*. "Nothing ventured, nothing gained." (I just don't think it'll work... well) > Admiting there would be some real impossibility, this > would be, at least a wonderful help for creating a port, in true > Assembly (in such a case), with a signifive "partial automation" > of the port job. Maybe... You mention that ARM has 16 registers. If our "cross asspiler" does the most "direct", "assembler-like", conversion of x86 source, it may not result in good register allocation on ARM. The existance of more registers might make a different algorithm possible. If we make this tool more "compiler-like", treat "eax" and "ebx" as "just variables", and let the compiler assign 'em to ARM registers as it will, we might get better code. At this point, I'm not sure what the advantage would be of using x86 asm as the syntax... .... unless, of course, you had a bunch of x86 asm code on hand. :) I suppose what you've got in mind is an addition to RosAsm whereby it would spit out apps to run on pocket devices running ARM and... Windows CE is it? That *would* be cool, if you could pull it off! > As you know the x86 Opcodes are several hundreads, but, when > you disassemble anything, all you see, is around 20 instructions > (a little bit more if there are intensive FPU calculations...). > So which example could be found, in real life, that could not > be applied such substitutions, because of completely missing > concept(s) as a given bu the x86 Mnemonic? I don't know specifics. I suppose any portabilty involves a "lowest common denominator". Maybe if you limit yourself to the subset of instructions that *do* have an equivalent... call it LCDasm... I don't think it'll fly. I think asm programmers want to be *able* to use all those hundreds of instructions, even if they don't actually use 'em. But I could be wrong... > The first thingie, i take a look about, is this Arm thingie > (that is effectively sold with Windows OS). A quick look does > not show to me any "can't do"... All i see tends to show me the > reverse, that is, that the equivalencies are so evident, that, > maybe, even true Assembly Substitutions could be possible and > therefore, that the "Ported Assembly" could eventualy be > very close to true Assembly. That may be true if we limit the discussion to ARM. I really don't know. The "problem instruction"(s), if any, won't be the first thing you see. Possibly the last... > Again, you insist strangely on the "No more Assembly" point, > which is a quite absurd thing to say to me, as i say exactely > the same, if there is no 1:1 Substitution for such and such. Strangely, I thought it was *you* who was calling this assembly. > My point is not with making true Assembly Processors > substitutions if not possible. My point is that without "Ported > Assembly" i cannot have any of my Applications runing on such > "market niches" (unless i rewrite it all, one time for each). This is where the C affectionados have their say! :) > Where would the substitutions idea fail in real world? The > only answer i got, up to now, was an example with direct usage > of the Debug Registers, that would not exist on "xxxx Processor". > Well, not exactely what we would call an "everydays real world > Apps", is it? So, what else? Well, I don't know. All it takes is one. Maybe not, if you're willing to switch into "compiler mode" and generate "whatever it takes" to get the result, when/if needed... As noted above, this might not generate optimum code. You'd be "thinking like an x86 asm programmer" rather than "thinking like an ARM asm programmer". At that, the result might compete with available code - some of it probably isn't hard to beat! Can't hurt to look into ARM more closely, and see if you still think it's possible/practical. Learning is never wasted! :) Best, Frank
From: sevagK on 24 Jan 2006 11:49
Frank Kotler wrote: > > Can't hurt to look into ARM more closely, and see if you still think > it's possible/practical. Learning is never wasted! :) > > Best, > Frank If I remember correctly, someone already did an ARM port for FASM. Check it out on the fasm forum. -sevag.k -=Kain=- www.geocities.com/kahlinor |