Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: Frank Kotler on 22 Jan 2006 20:28 Evenbit wrote: .... > Oh, what was I thinking? Churches tend to burn down when *you* pass > by. :) Churches are no issue to me, one way or the other. Like C, some people seem to enjoy it. I'm reluctant to be seen as advocating beer! As Betov would put it, "I have paid to know" that as a recreational drug, alcohol is a pretty good motor fuel. Around bottle 95, you're beginning to do yourself physical harm. If we make a checklist comparing alcohol and heroin, they compare pretty close, except that heroin doesn't have the long-term liver damage. Don't get me started, I can go on for quite a while... >>I suspect >>the way I allocated a buffer could be done in a more "hla-like" way. I >>tried several permutations of "string", but anything I could get hla to >>swallow segfaulted... >> >>static >> english_number :byte[128]; >>... >> conv.utoEng( ecx, &english_number ); >>... >> >>Seems to work okay, but there's probably a "nicer" way to do it. If it's >>going up as an "example", it ought to be "nice". > > > There several dozen different methods given in the text and the > examples that it is difficult to decide which is "nicest" or the > "official" way. > > One way... > > static > mystring :string := "19 dummy characters"; > var > pMyString :pointer to mystring; > > > Another way... > > static > s :string; > ... > mov(str.alloc(256), s); > > > Yet another way... > > static > MyText :str.strvar(256); > > > Can't think of the others at this moment, but this short list should > help you investigate the issue. *Me*??? I'm not an hla user! *You* guys figure out how hla can best represent itself. My only contribution to this is to point out that "utoEng" exists in the library. (I only know it's there 'cause I cribbed some code from it - "roman", too) These variations demo the Standard Library, and how easy it makes it to write - and modify - "portable" code. Randy's version stresses hla's macro capabilities more. But it *also* shows how a clever arrangement of your data can simplify the logic of your code. (IMHO, this second point is somewhat "shrouded" by the "cleverness", but...) >>But don't put Randy's code on the "99 Bottles" site until he gets it >>right! That's the first rule of assembly homework, as I understand it, >>"must assemble". :) > > Well, we can at least give him half of a gold star and a C- for getting > it to work on Windows. :) Yeah. There's no requirement that it work on Linux. Many - perhaps most(?) - of the languages represented on that site *are* portable. Assembly is generally considered not portable - and we *can't* do non-x86... I happen to think that hla's ability to assemble the same code (with some care) for either Windows *or* Linux is one of it's best features (in fact, it's one of the relatively few things about hla that I *do* like). A shame not to show off that feature, when you get an invitation to show off. :) Best, Frank
From: o///annabee on 23 Jan 2006 01:33 P? Sun, 22 Jan 2006 20:28:34 -0500, skrev Frank Kotler <fbkotler(a)comcast.net>: > Evenbit wrote: > > ... >> Oh, what was I thinking? Churches tend to burn down when *you* pass >> by. :) > > Churches are no issue to me, one way or the other. Like C, some people > seem to enjoy it. I'm reluctant to be seen as advocating beer! As Betov > would put it, "I have paid to know" that as a recreational drug, alcohol > is a pretty good motor fuel. Around bottle 95, you're beginning to do > yourself physical harm. If we make a checklist comparing alcohol and > heroin, they compare pretty close, except that heroin doesn't have the > long-term liver damage. Don't get me started, I can go on for quite a > while... You pipesmokers are all the same. :) You defend your hobby to the death, just as all people taking druggsies, even alachol does :) The diffrence I guess is that alacholdrinkers, usually have no need to call for help from green men from outer space, when they enter into the discussion, Also, pipesuckers are a bit more creative when taking the stuff. I mean : Is it to classify as psychosis, if you try to fill up a VW with hassssis in order to smoke it through the rear exchaust pipes? :) >> Can't think of the others at this moment, but this short list should >> help you investigate the issue. > > *Me*??? I'm not an hla user! Yeah. ! - Good for you Frank. > > Best, > Frank
From: Betov on 23 Jan 2006 03:42 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:MMudnQUH6__prEneRVn-gg(a)comcast.com: > Assembly is generally considered not portable - and we *can't* do > non-x86... Wrong. There is nothing making it impossible, for an Assembler, to have as many Encoders inside as you want, and to _translate_ the x86 OpCodes, into replacements (when not equivalent) substitutes. Of course, the substituted outputs would no more be true Assembly, but the original would remain Assembly. What do you think magic, in HLLs? Betov. < http://rosasm.org >
From: santosh on 23 Jan 2006 04:04 Betov wrote: > Frank Kotler <fbkotler(a)comcast.net> écrivait > news:MMudnQUH6__prEneRVn-gg(a)comcast.com: > > > Assembly is generally considered not portable - and we *can't* do > > non-x86... > > Wrong. There is nothing making it impossible, for an > Assembler, to have as many Encoders inside as you want, > and to _translate_ the x86 OpCodes, into replacements > (when not equivalent) substitutes. That would, IMHO, be the wrong way. x86 is a very complex processor with a CISC face. Many other processors like SPARC, M68000 don't have many of the features that x86 has. So translating x86 opcodes would be, I assume, most confusing and error prone, both for the assembler and for the user, if at all it is fully possible. 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? Better use GNU as (GAS). It is exactly designed for this purpose, if you can live with a twisted syntax. :)
From: Frank Kotler on 23 Jan 2006 04:09
Betov wrote: > Frank Kotler <fbkotler(a)comcast.net> ?crivait > news:MMudnQUH6__prEneRVn-gg(a)comcast.com: > >>Assembly is generally considered not portable - and we *can't* do >>non-x86... > > Wrong. There is nothing making it impossible, for an > Assembler, to have as many Encoders inside as you want, > and to _translate_ the x86 OpCodes, into replacements > (when not equivalent) substitutes. Are there equivalents? ...in this hypothetical non-x86 machine? (if so, what makes it non-x86?) > Of course, the substituted outputs would no more be > true Assembly, End of story. > but the original would remain Assembly. How do you figure that? It no longer represents machine instructions. > What do you think magic, in HLLs? No magic. Different assembly languages for different processors. Take a look in your /usr/src/linux/arch directory... never mind, you haven't got one... If you believe in portable (across architectures) assembly, I'll see if I can dig up Scot Nudds' address. You can correspond with him. Best, Frank |