Re: Optimizing in assembly language

Randall Hyde <rhyde@transdimension.com> wrote:


> 4) Very few people are good enough at assembly language to write the
> kind of code that can consistently beat compilers.


True.


> It *is* possible to write machine-specific optimized code in HLLs.
> The Berkeley strings library for C stands out as a prime example of
> code that does really well on 32-bit machines. However, the resulting
> code has nearly all the defects of assembly language (portability to a
> different CPU is about the only advantage). The optimizations may
> very well break with a new version of the compiler and they may also
> break with new CPUs.


*nods* C is a low level language.


> Basically, it boils down to this: compilers are really great at
> bookkeeping but lousy at dealing with the "big picture" (global
> optimizations not withstanding). Humans (the "assembly coder") are
> really great at the big picture and lousy with the details.


compilers compile programs from 'the inside', therefore they *can* be
beaten by a human who sees the code from a higher level.


> So here's my question: why can't we write an "optimizing assembler"
> that lets the programmer specify machine sequences and the assembler
> does the same kinds of "book keeping" that a HLL compiler would do.
> Sure, optimization is a bit more difficult at this level and you'd
> have to allow the programmer to disable the optimizations on a
> statement by statement basis (since sometimes the programmer really
> does know better). This would allow the programmer to do what they
> know best while taking advantage of the current state of the art in
> optimization technology.


I think a better approach and one that is currently used is to
put little *chunks* of hand optimized ASM into a higher level language.
This has many advantages over the scheme you suggest.
- coders on the whole can deal with a smaller number of lines of code
- they can focus their optimizations to key areas
- most of the code is very portable only the ASM bits are not
- small chunks of assembler are easier to understand than a whole program
at an intermediate level.
- the programmer can see what the compiler is doing by simply reverse
engineering their own HLL code.


In most cases speed is not so critical as to require *any* part of a
program to be reduced into ASM let alone all of it! The uses for ASM
that I have found have mainly been restricted to optimizing inner
loops that the CPU spends a huge ammount of time in. Here writing the
rest of the code in a higher level language and embedding blocks of
assembly for critical points is clearly the right solution.


Using ASM is a last resort, finding a better algorithm is always the
better way to go.


If *all* your code needs to be faster I would suggest you either:
- use a better algorith or
- raise the target spec of the machine to run it on


> Of course, the real problem is "who would be willing to write such a
> thing?" (and maintain it.) But the idea seems interesting to me. Let
> the machine choose the best instruction organization given a sequence
> in machine code. Let the machine rearrange registers in instructions
> to make better use of them (and move memory accesses into registers,
> if needed). Let the machine eliminate dead code. Let the machine do
> code movement to improve performance.


.. or compile the section of code your intrested in and reverse
engineer it, I have done this on several occasions.


> While some assembly programmers might find this whole process
> offensive ("I don't want a compiler touching my beautiful code."), it
> would allow "less than expert" assembly programmers to at least match,
> and usually better the code emitted by a typical HLL compiler.


less than expert assembly programmers are not likely to be writing
programs that need the extra speed. If they do then they should learn
optimized assembly, most people will never need to.


> Many of the software engineering problems would remain (do you really
> want to write a large amount of code in assembly?), but some of the
> issues, like the appearance of new CPUs with their own idiosyncrases,
> would diminish or go away entirely.


many of the software engineering problems would be *worse*, instead of
having mostly HLL with small ammounts of lower level languages mixed
in you now have a medium level soup. This could be very hard to
maintain.


It's a nice idea but I think what is currently done is more sensible.


Tom Shackell

Return to the comp.compilers page.
Search the comp.compilers archives again.