Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: Betov on 21 Jan 2006 09:31 "Dragontamer" <prtiglao(a)gmail.com> ?crivait news:1137851617.220026.85660 @g44g2000cwa.googlegroups.com: > > Betov wrote: >> [And L0<< // L0>>, if the jumps are long, to give >> control to the programmer on the local jumps sizes, >> which is one another write-time security] > > Hmm, so does >> force a long jump and does > force > a short jump? Yes, absolutely. > If that is the case... maybe there is some kind of overflow > error. Yes, and this is exactly where the Write-Time security thingie comes into the story. Example, you write some Jmp L8> .... somewhere, in a Routine, but you forget to declare the Local Label. Unfortunately there is a previously existing "L8:" Label, downward, in another Routine. In such errors cases, the wrong jump will very likely generate an error at the compile time, saving the user from bugs that might have taken time to point out. > Probably not, another trivial error for a disassembler :-/ Impossible. The Assembler would tell it, when compiling. By the way, this particularity of RosAsm, with Short and Long Jxx Managements, has been one another good demonstration of the massive advantage of the All-In-One Environnement, because, when i got this error Message, it has been sometimes usefull: As you may know some x86 Mnemonics may have complicated Encodages, with up to 3 possible versions. In such cases, we are used to choose the shortest possible Encodage, but the fact is, when doing the real job, that we may miss some tricky cases, what i effectively had done. In such a case, the Two-Clicks Disassembler-ReAssembler shown me immidiately that "this or that Compiler" had a shortest form implemented, what was a good help to point out the real shortest form, that i had missed. Even tough the primary purpose of the Disassembler-ReAssembler, was to point out in seconds, where the Disassembler could have done interpretations errors, what achieved in a unic Tool that will not have any competitor before many years, it also had an impact the other way round, that is, by validating some details of the Assembler, from conflicts with the Disassembly. The massive advantages of Mono-Block Tools, compared to Brick&Brok toys, that can almost never (or with much additional efforts...) validate themselves by cross- comparisons, achieving, for example, in Disassemblers outputing nothing but a _text_, that no reality could validate. With RosAsm this problem is arased: Either it re-runs or it does not re-run. Period. This is huge advantage, as well for the user, who can very easily point out the problem and fix it in seconds, with the help of the Integrated Disassembler, as for the developer, who can improve the Disassembler itself, from quick and easy experiments. Betov. < http://rosasm.org >
From: Evenbit on 21 Jan 2006 20:35 Frank Kotler wrote: > randyhyde(a)earthlink.net wrote: > > > program bottles; > I may not go to the bother of trying to get it to work in this case. I > like Nathan's version, and my slight "tweak" of it, better anyway. I may > tweak it one more time, to "XCIX Bottles"... maybe run Jeff's asmsrc on > that... or not... Well, I did see *my* version gain enough votes on that site to get ranked in second place on that site one day.... but that doesn't mean anything. Might be interesting to read any comments if yours and Randy's versions were to be posted there as alternatives. I can "proxy submit" them if you two don't mind and can give the attribution as "found on the 'net" or "version suggested by ..." if either of you have an issue with your names appearing on a website (which your minister's wife can access) directly associated with the word "beer"? > > I may be screwing something up here, but I suspect there's something > "funny" going on with hla's macro-processing in Linux. If anyone else is > getting these to work, it's "just me"... 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.
From: Frank Kotler on 22 Jan 2006 01:19 Evenbit wrote: >>>program bottles; .... > Well, I did see *my* version gain enough votes on that site to get > ranked in second place on that site one day.... but that doesn't mean > anything. Better'n third place! There's a lot of competition on that site. My goodness, there are a lot of languages! > Might be interesting to read any comments if yours and > Randy's versions were to be posted there as alternatives. I can "proxy > submit" them if you two don't mind and can give the attribution as > "found on the 'net" or "version suggested by ..." if either of you have > an issue with your names appearing on a website (which your minister's > wife can access) directly associated with the word "beer"? I've got no problem with it either way - mostly *your* code! 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". >>I may be screwing something up here, but I suspect there's something >>"funny" going on with hla's macro-processing in Linux. If anyone else is >>getting these to work, it's "just me"... > > 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. Thank you for the testimonial to hla's macro power. So powerful, only Randy can run it! :) Seriously, that's why there's a prototype. These issues will work themselves out. 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". :) Best, Frank
From: Betov on 22 Jan 2006 04:38 "Evenbit" <nbaker2328(a)charter.net> ?crivait news:1137893738.650676.293640 @f14g2000cwb.googlegroups.com: > 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. You do well, but you should also never use the obfuscating Text Converter. :) Betov. < http://rosasm.org >
From: Evenbit on 22 Jan 2006 12:14
Frank Kotler wrote: > > Might be interesting to read any comments if yours and > > Randy's versions were to be posted there as alternatives. I can "proxy > > submit" them if you two don't mind and can give the attribution as > > "found on the 'net" or "version suggested by ..." if either of you have > > an issue with your names appearing on a website (which your minister's > > wife can access) directly associated with the word "beer"? > > I've got no problem with it either way Oh, what was I thinking? Churches tend to burn down when *you* pass by. :) > 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. > 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. :) Nathan. |