Re: the quality of assembly language code

Since I am one of the old folks, I just have to jump in. I started in
Honeywell 201 EasyCoder in 1972. I also did Cobol for a long time after
that assignment (USAF). I also wrote any assembler and other low level
language (BPL for Burroughs) when it was needed to do what Cobol could not
accomplish. Then I wrote code in CI's C in the 80's for PC/XT clones.

Last year Michael Abrash wrote a multipart article about using assembly and
optimizing it for games/video code. He wrote a sequence that was slower
when an unneeded multiple was removed. Not even Intel could tell him why
without running some special hardware/software that could emulate the CPU
and find out it was a pipe stall situation. Intel's compiler is supposed to
be the best of any on the market, but most of us have to use Microsoft's.

I like assembly, but I always like it more the less I am tasked to write in
it. I have found that I prefer 'C' and assembler roughly in inverse
proportion to how much my current tasks require their use. The IBM PC/XT
with the 8088 had a simple optimization algorithm. The shorter the code -
the faster it was. There were so many wait states on the memory that it was
the primary factor controlling speed.

I don't think that assembly will ever return in the world of PCs. I can
always hope. I would get code output with Cobol listings so I could
optimize the assembler code by using better statement sequences. I had
limits on time and especially size when writing code for the Air Force.
They had rules that batch jobs could not exceed specific sizes. I think
most of these limits were based upon what was easy to measure. Luckily we
know today that virtual memory computers don't care unless bad design or
implementations cause too many pages to be accessed too frequently.

Good design and good coding style provides two bonuses - better
maintainability and faster, smaller code. I don't think you can do good
design unless you really understand the hardware including the instruction
set.

"randyhyde@xxxxxxxxxxxxx" <spamtrap@xxxxxxxxxx> wrote in message
news:1113879432.237910.260870@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Ed Beroset wrote:
>> randyhyde@xxxxxxxxxxxxx wrote:
>>>
>> > Show me a compiler that produces great code under *ALL*
> circumstances.
>> > Your defense is exactly the problem I'm talking about. When
> confronted
>> > with examples of bad code generation, the apologists in the crowd
>> > always come back with "well, you're just using the wrong compiler"
>> > without giving an example of a compiler that works under all
>> > circumstances.
>>
>> I'd like to see the counterexample of a human assembly language
>> programmer that produces great code under *ALL* circumstances! I've
>> never met one yet.
>
> But here's the deal: compilers are basically deterministic. Feed 'em
> the same input and you're going to get the same output. Humans can
> adjust, IF NEED BE.
>
>>
>> > People need to know that they cannot rely on comments like
> "compilers
>> > generate better machine code than human beings."
>>
>> Actually, I find that compilers *do* tend to generate better machine
>> code than human beings writing raw assembly language.
>
> Having spent a fair amount of time analyzing compiler output recently,
> I would simply suggest that this statement is true *only* if you feed
> the compiler *very* good source code to begin with. The compiler is not
> going to make up for dubious programming techniques. Even when fed some
> pretty good input, I've seen commonly-used compilers produce some
> bone-headed code. As I've said in other posts: sometimes the code is
> brilliant, sometimes it is stupid. On the average, it's probably better
> than average, but a good assembly programmer can beat the code without
> resorting to cycle counting and what-not.
>
> The other disadvantage of a compiler is that it cannot make
> optimization decisions on a statement by statement basis (at least, not
> without a *lot* of work on the programmer's part and a great set of
> pragmas). A compiler, for example, is not going to know that in a
> certain section of the program it should optimize for space while in a
> different section of the program it needs to optimize for speed. Most
> optimization settings are global. And if you go in and tweak the system
> (e.g., via pragmas), the code is just as difficult to write and
> maintain, and is just as non-portable (to other compilers) as assembly
> code.
>
>
>> While the loops
>> may not be optimal, and the reuse of registers *could* be done better
>
>> than most compilers, I find that most assembly language programmers
>> *don't* actually do any better,
>
> Classic optimizations like register allocation, instruction scheduling,
> et. al., are almost *always* done better by machine. Yes, compilers
> will do a better job of this. This is not where an assembly language
> programmer wins out over a compiler. As you point out below, it is the
> holistic approach, that is "grokking the machine" that separates
> assembly programmers and compilers.
>
>> and further, most assembly language
>> programmers do a very poor job at error checking and error handling.
>
> And HLL programmers do a whole lot better? :-) Granted, some languages
> (like Pascal) help out a lot here, but then, for people who are
> interested in better error detection and recovery, consider using HLA.
>
> This is a different matter altogether. It's more a function of the fact
> that assembly programming is largely done today by hackers who have
> little respect for reasonable software engineering concepts. Look at
> all the people who try and claim that type checking doesn't belong in
> assembly language, for example. OTOH, most of the people who fall into
> this category don't quite make my list of programmers who produce
> better code than compilers.
>
>>
>> Rather than focusing in on a particular for loop that a particular
>> compiler doesn't handle well, it might be more useful to look at
>> programs more holistically and evaluate overall correctness,
>> functionality and usability as well as raw speed of individual
> components.
>
> Of course. And this is the place where assembly *wins big*. Counting
> cycles is anachronistic and compilers do a much better job of that. But
> HLL abstractions hide too much of the underlying machine and someone
> who is not well-versed in assembly language (so they understand what
> the compiler is doing with their HLL code) don't have a clue what HLL
> statements are good and bad when writing their code.
>
> Ed, you've programmed assembly for many years. You have the experience
> to know how to write good HLL code based on that knowledge. Whether
> it's concious or subconscious, your programming style takes into
> consideration the operation of the compiler. This is not something most
> newer programmers can do, as they've never learned (much less mastered)
> assembly language. They write terrible code that the compiler
> translates into equally terrible machine code. Yes, a great C
> programmer, who knows how compilers work, and produce a source file
> that a good compiler will translate into excellent machine code. That,
> however, is not the typical case in most of the C code I've evaluated
> on the internet.
>>
>> Assembly language has its place, but that place doesn't happen to be
>> every place.
>
> It's place is in the mind of every practicing programmer, so they know
> what the hell their compilers are doing with the HLL code they write
> :-).
> Once in a while, it's even useful for writing applications.
> Cheers,
> Randy Hyde
>


.

Relevant Pages

  • Re: ALDS cross-assembler and linker available
    ... linked with a linker to make an executable file, or the assembler output ... language was that there were no system "libraries" to link against. ... the assembly language to do the same thing for the ... If you had the Misosys C compiler, ...
    (comp.sys.tandy)
  • Re: Your opinion on the Agner fog manuals.
    ... Perhaps the fact that those "advanced assembly language programmers" ... Boy, you're really stuck on that *one sentence* in the documentation, ... Try searching for information about the LISA assembler sometime. ...
    (alt.lang.asm)
  • Structs in Assembly
    ... implementation in assembly language. ... support this facility. ... programmers who don't know much about assembly. ... Now if your assembler doesn't support structs, ...
    (alt.lang.asm)
  • Re: Interesting article by Randall Hyde
    ... as you are the compiler optimization "expert". ... of the work that has gone into creating optimizing compilers. ... > Compilers generate better code than *most* programmers all of the ... learn without needing to know anything about assembly language. ...
    (comp.lang.asm.x86)
  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... is that other programmers for C are easier to find. ...
    (comp.arch.embedded)