Multiple Statements per Line
in [ASM]
|
From: Alex McDonald on 7 Apr 2006 18:45 randyhyde(a)earthlink.net wrote: > Alex McDonald wrote: > > > > Perhaps factoring (aka refactoring) is just as important; that is, as > > few lines of code (or statements, or whatevers) per > > function/subroutine. > > I assume you're posting this because you read my last paragraph. Though > the way your post comes across, it sound's like you hadn't. But I'll > give you the benefit of the doubt. > Snip early, snip often. -- Regards Alex McDonald
From: JGCASEY on 7 Apr 2006 19:06 Regards readable code I would find your code below, ======================================== begin DAInstrs; preserve( eax, ecx, edx, edi ); // The byte following the $DA prefix is the real opcode. movzx( (type byte [esi]), eax ); add( 1, esi ); if( al >= $c0 ) then if( al < $e0 ) then // We've got an FCMOVB, FCMOVBE, FCMOVE, or FCMOVU // instruction. mov( register_c, instrEDI.firstOp.opClass ); mov( st0_c, instrEDI.firstOp.register ); mov( al, cl ); and( %111, cl ); add( st0_c, cl ); mov( cl, instrEDI.secondOp.register ); mov( register_c, instrEDI.secondOp.opClass ); mov( fcmovb_c, ecx ); if( al >= $c8 ) then mov( fcmove_c, ecx ); if( al >= $d0 ) then mov( fcmovbe_c, ecx ); if( al >= $d8 ) then mov( fcmovu_c, ecx ); endif; endif; endif; elseif( al = $e1 ) then mov( fucompp_c, ecx ); else mov( undef_instr_c, ecx ); endif; mov( ecx, instrEDI.mnemonic ); else // DA instructions with memory operands // Instruction opcode comes from bits 3..5. mov( eax, ecx ); shr( 3, ecx ); and( %111, ecx ); mov( DAInstrMap[ecx*4], edx ); mov( edx, instrEDI.mnemonic ); fModRm( al, 4, esi, instrEDI.firstOp ); endif; end DAInstrs; =========================================================== Easier to read like this, +---------------------------------------------------------------+ | begin DAInstrs; preserve( eax, ecx, edx, edi ); | | | | // The byte following the $DA prefix is the real opcode. | | | | movzx( (type byte [esi]), eax ); | | add( 1, esi ); | | | | +-----------------------------------------------------------+ | | | if( al >= $c0 ) then | | | | +-------------------------------------------------------+ | | | | | if( al < $e0 ) then | | | | | | | | | | | | | | | | | | // We've got an FCMOVB, FCMOVBE, FCMOVE, or FCMOVU | | | | | | // instruction. | | | | | | | | | | | | mov( register_c, instrEDI.firstOp.opClass ); | | | | | | mov( st0_c, instrEDI.firstOp.register ); | | | | | | | | | | | | mov( al, cl ); | | | | | | and( %111, cl ); | | | | | | add( st0_c, cl ); | | | | | | mov( cl, instrEDI.secondOp.register ); | | | | | | mov( register_c, instrEDI.secondOp.opClass ); | | | | | | mov( fcmovb_c, ecx ); | | | | | | | | | | | | +---------------------------------------------------+ | | | | | | | if( al >= $c8 ) then | | | | | | | | mov( fcmove_c, ecx ); | | | | | | | | | | | | | | | | +-----------------------------------------------+ | | | | | | | | | if( al >= $d0 ) then | | | | | | | | | | mov( fcmovbe_c, ecx ); | | | | | | | | | | | | | | | | | | | | +-------------------------------------------+ | | | | | | | | | | | if( al >= $d8 ) then | | | | | | | | | | | | mov( fcmovu_c, ecx ); | | | | | | | | | | | | endif; | | | | | | | | | | | +-------------------------------------------+ | | | | | | | | | | | | | | | | | | | | endif; | | | | | | | | | +-----------------------------------------------+ | | | | | | | | | | | | | | | | endif; | | | | | | | +---------------------------------------------------+ | | | | | | | | | | | | elseif( al = $e1 ) then | | | | | | +---------------------------------------------------+ | | | | | | | mov( fucompp_c, ecx ); | | | | | | | +---------------------------------------------------+ | | | | | | | | | | | | else | | | | | | +---------------------------------------------------+ | | | | | | | mov( undef_instr_c, ecx ); | | | | | | | +---------------------------------------------------+ | | | | | | | | | | | | endif; | | | | | +-------------------------------------------------------+ | | | | | | | | mov( ecx, instrEDI.mnemonic ); | | | | | | | | else // DA instructions with memory operands | | | | | | | | +-------------------------------------------------------+ | | | | | // Instruction opcode comes from bits 3..5. | | | | | | | | | | | | mov( eax, ecx ); | | | | | | shr( 3, ecx ); | | | | | | and( %111, ecx ); | | | | | | mov( DAInstrMap[ecx*4], edx ); | | | | | | mov( edx, instrEDI.mnemonic ); | | | | | | fModRm( al, 4, esi, instrEDI.firstOp ); | | | | | | | | | | | +-------------------------------------------------------+ | | | | endif; | | | +-----------------------------------------------------------+ | | | | end DAInstrs; | +---------------------------------------------------------------+ ========================================== Assuming you choose the right font first :-) -- JC
From: Jim Carlock on 7 Apr 2006 19:08 <randyhyde(a)earthlink.net> wrote: > Actually, *most* people read faster, and with better comprehension, > when working with short lines (though this is not an argument for > manually insert line breaks everywhere; almost any decent newsreader > is going to allow someone to adjust the width to their liking). > Allow me to give an example. The editor I personally prefer (Borland's > CodeWright) allows me to insert JPEG and other images directly into > my source file (as comments) and display those in the editor. This is a > really cool feature for documenting the program. Alas, only CodeWright > owners can take advantage of this facility. So I don't use it because > other people who don't own CodeWright can't see my nice diagrams. HTML and notepad provides the same thing, although better HTML editors exist. SciTE (the Scintilla editor) http://www.scintilla.org/ or http://sourceforge.net/projects/scintilla/ is a wonderful editor for a variety of languages. SciTE uses plain-text Property sheets for each language (based upon the file exension, .c, .asm, .php, .htm, et al). Really nice editor in my book. Versions for both Unix and Windows. HTML encoding isn't all that hard to work with. Just have to know some HTML tags to get it done properly (pretty easy for the English speaking world, but people of other languages might find it slightly more cryptic). JGCASEY wrote: > One thing I never liked about C and the other languages that use > the curly brackets { and } is that visually the blocks of code did > not pop out for me without practice and even today some effort > despite indentation. > > Or maybe I am just visually handicapped in some way > which is why I have a problem with multiple statements > per line? Maybe it's the particular editor and font used ? I don't mind reading C code in a proper editor where the tabs are set to 2 characters and provided the lines aren't very long. I have difficulties switching between languages. But that's an issue I've been dealing with all my life. I took two years of German and had problems learning the language but I did okay in the class and passed. When I decided to take Spanish though, I realized I knew more German than I previously thought and when someone sayeth something in Spanish, all of a sudden, "Ich spreche Deutsch." Really weird. After messing with VB for a long time, I broke VB habits, I started writing in PHP, and when I went back to VB it started coming out in PHP. I'm sure that's just me. Hard to teach an old dog new tricks. I like a syntax that means something to me, and the ONLY way to get out of any routine involves working out new routines and while it requires a tremendous amount of effort, I find I can accomplish this sometimes. I have a hard time with Regular Expressions and PERL because they literally are whole knew languages and use alot of symbolics (well at least the Regular Expression syntax is). Anyways, in Randy's case, I think HTML achieves the pictures and such, as well as provides probably the most universal access to a widest variety of content, not only pictures, but videos, audio, and maybe one day we'll get an HTML encoding which can emit a fart in the direction of the people we don't like. Hope this helps. Jim Carlock Post replies to the group.
From: James Daughtry on 7 Apr 2006 19:15 randyhyde(a)earthlink.net wrote: > That box was thought outside of a long time ago. Keep in mind, people > actually *used* to do what you're proposing. It didn't work out. > Perhaps you are so arrogant as to think you can convince the world to > adopt your "out of the box" style when it's been rejected before? You > never can tell, extreme programming has convinced a lot of people that > they don't need to comment their code. :-) No, though I'm certainly arrogant enough to think that I can convince the world that the accepted "best practices" aren't concrete rules, but general guidelines. If you apply a general guideline globally then it's just as bad as not following it at all. > > I'm going to write a long article explaining exactly why I'm > > right and everyone else is wrong by quoting from a book and making > > comments on it. The book is well respected, so in turn, my approving > > comments of the book should also be respected. > > Versus you writing a long article claiming that I'm wrong because I > quoted from a well-respected and highly-popular book on the subject? The difference here is that you started it. ;-) > Again, if you want to argue against McConnell's work, be my guest. I argue where I disagree. For example, McConnell advocates aligning assignments for related variables: EmployeeName = InputName EmployeeSalary = InputSalary EmployeeBirthdate = InputBirthdate I don't agree with that style, nor do I agree with his recommendation for a "readable, maintainable standard indention" for routine headers. The book is good, and McConnell has obviously done his homework. That doesn't mean that his conclusions are correct, especially when you consider that both of the recommendations I mentioned above are rarely used in the majority of the C code out there. You can find similar instances throughout the book. > I'm still waiting for a definition of what "correct use of MSPL" means. > I've asked for that from you in the other thread, you've not provided > this. I've done so elsethread, I suppose it was a different one: L0: cmp a,b | jne L1> ; Body of the loop here L1: Or if there are multiple conditions, a blank line is used: L0: cmp a,b | jne L1> cmp c,d | jne L1> ; Body of the loop here L1: > > As for a single scheme, how do you explain that any good code will use > > both blank lines *and* indention for logical grouping? > > They're using whitespace in either case. Dig out your copy of Code > Complete and re-read chapter 18 ("Layout and Style"). McConnell makes > some very good cases for the use of indentation and blank lines. Ah, so multiple schemes are acceptable when someone advocates them in a popular book or you can rationalize their use? So what's wrong with a third scheme that also uses whitespace (horizontal rather than vertical) in some cases? That's a rhetorical question by the way, you've already stated your case several times, and I was already familiar with the arguments before that. I wouldn't want to cause you carpal tunnel by making you think you need to re-iterate your position again. > > Well, in theory this sounds good, but let's consider the '<test> > > <jump>' MSPL idea. Sure, you could factor that into a subroutine...hmm, > > or not, because that's the epitome of silliness. A macro could work, > > but you would need to pass the label as an argument. You would also > > need to pass the test as an argument as well, or write multiple macros > > that do different tests. Wait, why even bother? Oh, right, so you don't > > repeat yourself. O_o > > bge value1, value2, label > > Doesn't seem that silly to me. It does when you have as many macros as you do instructions, and the macros are more verbose and cause people familiar with the instructions to pause for a moment to figure out your macros. But when I was talking about silly, I was thinking of pushing and popping a stack frame for the sole purpose of wrapping a pair of instructions (for the subroutine suggestion). > HLL-like control structures (macros) are a good thing in assembly. > Something like > > if( value1 < value2 ) then > ... > endif > > is quite a bit more readable to most people than something like > > cmp value1, value2 | jge >L0 > ... > L0: > > Particularly when there are multiple instances of L0 floating around in > the source file. I agree. But in this case, when faced with the choice of using RosAsm's macro set for HLL control structures, and rolling my own with straight assembly, I'll choose the latter. I imagine you can figure out why. ;-) > > The fact of the matter is that where MSPL works, refactoring doesn't. > > It's either impractical or illogical. Often, where MSPL works, blank > > lines don't help readability quite as much, in my opinion (even though > > it's close). > > Ah, but here's an important point. In those instances where you can > make a *valid* claim that MSPL works better than blank lines, blank > lines still come close. So is it really worth the inconsitencies and > other problems that come from using MSPL. That's a decision that can only be made on a case by case basis. > > Blank lines and MSPL are simply two tools that you can > > use. You use them, or not, as you deem them necessary. > > Again, you're missing the point of writing readable code. It isn't what > *you* deem necessary (or whatever), but what other people expect. Perhaps I wasn't clear, my appologies. I meant necessary for readability, which certainly takes into account other people reading the code as well as the original author. If you're writing code only for yourself then, aside from the usual arguments of good code getting reused, this whole debate is moot. > > Just because most people choose not to use MSPL in their code doesn't > > mean they think it's bad. > > Most people don't think about it at all. Until they see it, that is. > And then they typically say "what is this?" It's not what they expect, > and that's a *bad* thing. Yes, but if what they don't expect is *consistently* what they don't expect, they should be able to adapt. That's why one of the primary tenets of any programming style is consistency, even though every style guideline document you read is unique in the details. > > Will the book help? > > Quite likely. Is it an absolute necessity for success in the field? No. > > I guess it all depends on what you consider success. If you're > constantly writing code that other people find unreadable, because > you've refused to learn the basic of good programming style, I wouldn't > consider that to be the apogee of professional development. And yet, you can learn the basics of good programming style without reading the books, or taking the classes, or anything "formal" in the traditional sense. Of course, it's possible that being mostly self taught, I have a different perspective than a formal instructor, such as yourself. > > Your little P.S. adds to the stench of "I'm better than you" that your > > entire article (except for the quote) reeks of. > > Go back and read your post. And as the saying goes, "physician, heal > thyself". Claiming I'm an "arrogant prick" really reeks of "I'm better > than you are..." I'm blessed with a very strong sense of self-importance, so I'll think that I *am* better than you are until you conclusively prove that you're worth being my equal. And when you manage that, I'll do my best not to see you as anything greater than my equal. Normally I can hide that arrogance behind a wall of "nice-guy", but in reality I'm a conceited egomaniac. :-)
From: JGCASEY on 7 Apr 2006 19:19
Jim Carlock wrote: ... > I have difficulties switching between languages. And it is even harder if you only program for fun. It usually results in a lot of syntax errors. For example when I first started C it was forgetting the semi colon. When changing from 68000 to 8086 it was rts instead of ret. > I'm sure that's just me. Hard to teach an old dog new tricks. Because I have little time to spend learning how to do the new tricks that is certainly the case with me. It is the biggest obstacle I found with RosAsm. Extra things I have to learn over and above programming for Windows. There are better keyboard layouts then the qwerty board but not for an old dog. Best to stick to what you know. -- JC |