Re: Programming: Not stressful? Yeah, right...
- From: spinoza1111@xxxxxxxxx
- Date: 31 Oct 2005 01:35:49 -0800
Arthur J. O'Dwyer wrote:
> On Sun, 30 Oct 2005 spinoza1111@xxxxxxxxx wrote:
> ["Helpful" tips for assembly programming]
> >
> > (1) Think in terms of the goal of each set of instructions and hang a
> > comment to the right of each set (but don't comment every line).
>
> Good advice, except that I'd replace "to the right of" with "above."
> The problem with "to the right" comments is that as soon as you start
> putting comments and code on the same line, you have to face a tradeoff
> among having short lines, having readable comments, and having
> maintainable code formatting. Consider:
>
> movl (%ebx,%esi,4),%eax # If array[esi] is less than
> array[edi]...
> movl (%ebx,%edi,4),%edx
> cmpl %eax,%edx
> jnle @swapped # then swap the array elements and
> set our "swapped flag" ecx to 1
> mov %eax,(%ebx,%edi,4)
> mov %edx,(%ebx,%esi,4)
> mov $1,%ecx
> @swapped:
>
> versus
>
> movl (%ebx,%esi,4),%eax # If array[esi] is
> movl (%ebx,%edi,4),%edx # less than array[edi]...
> cmpl %eax,%edx
> jnle @swapped # then swap the array elements
> mov %eax,(%ebx,%edi,4) # and set our "swapped flag"
> mov %edx,(%ebx,%esi,4) # ecx to 1
> mov $1,%ecx
> @swapped:
>
> versus
>
> # If array[esi] is less than array[edi],
> # then swap the array elements and set our
> # "swapped flag" ecx to 1.
> movl (%ebx,%esi,4),%eax
> movl (%ebx,%edi,4),%edx
> cmpl %eax,%edx
> jnle @swapped
> mov %eax,(%ebx,%edi,4)
> mov %edx,(%ebx,%esi,4)
> mov $1,%ecx
> @swapped:
>
>
OK, but I would change the comment to something less procedural and
detailed. How about "Swap array elements that are out of sequence"?
Your comment seems to parrot the code which I think is not as useful.
> > (2) Use "virtually structured" style such that if you use go to, it
> > flows downward, not to instructions but to pseudo-instruction
> > placeholders defined only as the location of the next instruction
> > (often called EQ or EQUATE), or upward to a similar statement in a
> > structured loop.
>
> Huh? Does anyone know what Nilges is trying to say? It looks to me
> like his "pseudo-instructions" are what people these days call
> "labels."
>
Oops, I was thinking in terms of IBM mainframe assembler which unlike
modern assembler did NOT allow lines such as
LBL1:
which defines LBL1 as the address of the next "real" operation code.
In old IBM mainframe language one would use
LBL1 EQU *
My mistake, for ever since the appearance of assemblers for micros, the
assembler writers have preferred the first syntax and not the
"pseudo-instruction" EQU.
> > A "virtually structured" assembler program is one whose flowchart is
> > restricted to the Bohm-Jacopini structured constructs exclusively.
>
> (Some people would get rid of the word "virtually" in that sentence.
> I don't think it adds any useful meaning.)
>
I would keep it and it's what I called the style in an article long
ago, because unless the assembler or machine supports "real" structured
programming one must use GO TO to move among structured blocks.
> > (3) Make friends with the macro processor for common small sequences of
> > instructions. In C the corresponding preprocessor is mostly a waste of
> > time whereas in assembler it allows the symbolic representation of
> > otherwise generically named registers and facilities and processing
> > that depends upon conditions set at assembler time.
>
> Good advice.
>
> > (4) Use Hungarian notation
>
> Bad advice. Although I suppose it's possible to make a slightly better
> case for HN in some assembly languages than in high-level languages, where
> the typechecking is better --- still, HN should basically be avoided at
> all costs. Most assembly languages are obfuscated enough, without adding
> extra obfuscation to the names of the labels.
>
Nope. intIndex is LESS "obfuscated" and MORE informative than index.
OK, it restricts intIndex to a 32 bit quantity on modern platforms.
D'oh: use the editor to change it globally to lngIndex if you need more
bits or shrIndex (or bytIndex) if you need fewer.
Furthermore, requiring the assembler coder to use ptrToMung instead of
Mung or even toMung is good since each such untyped pointer to possibly
mungeable data is a danger.
It's possible to hide all pointers by using the macro processor like a
nut bar. The problem here is that the next guy inherits your Pure or
Reinen Theory of Using the Goddamn Macro Processor to Avoid Mung. This
can piss him off since then he has to master the Reinen Theory before
he can get any Work done.
I'd advise the assembler programmer to use a simple and clear approach
but this is simply and clearly not possible in assembler. Which is why
we gots in most cases dem optimizing compilers.
- Ed
.
- References:
- Programming: Not stressful? Yeah, right...
- From: Dave
- Re: Programming: Not stressful? Yeah, right...
- From: spinoza1111
- Re: Programming: Not stressful? Yeah, right...
- From: Arthur J. O'Dwyer
- Programming: Not stressful? Yeah, right...
- Prev by Date: Re: Java or C++?
- Next by Date: Re: Programming: Not stressful? Yeah, right...
- Previous by thread: Re: Programming: Not stressful? Yeah, right...
- Next by thread: Re: Programming: Not stressful? Yeah, right...
- Index(es):
Relevant Pages
|