Re: optimizing compiler against iaverage assembly programmer.

jim-neil@digital.net (Jim Neil) writes:
>> I think the millions of users that must sit and wait for bloated
>> compiler generated code to execute time after time, day after day,
>> week after week, month after month, year after year, is MUCH more
>> valuable than a few extra months of effort spent by a few well trained
>> programmers.


<graham.hughes@resnet.ucsb.edu> wrote:
>I don't believe this at all. Why? Because unless the routine in
>question is executed extremely often, the difference between the
>assembler version and the HLL version will be on the order of
>milliseconds. Worse, both will be bounded by I/O time, which is
>simply immense compared to CPU time.
...
>Now, there are certainly a few very important applications for
>assembler. One of them is (obviously) compiler backends. Certain
>embedded systems demand to be coded in machine language (not even
>ASM). And I can't think of a more appropriate tool to bootstrap a
>machine with. For each of these, branch delay slots, registers, and
>intimate machine level details are immensely important.


Someone may have mentioned it already, but another place where
assembler programming may be desirable is OS microkernels. This is
for two reasons: (1) microkernel code is executed very often, so
should be fast and small, and (2) optimized microkernels are
inherently architecture dependent anyway. For example, the L4 kernel,
where they chose a completely different way to handle address spaces
on the Pentium vs. the 486, due to changes in the cost of various
operations, even though the machines had nearly the same instruction
set. So coding the microkernel in assembler doesn't lose anything in
portability, if you were going to customize at the algorithmic level
anyway.


Mach used to do interprocess procedure call (with address space
switch) in 100 microseconds, paying a large price for machine
independence. Hardware's gotten faster, granted, but L4 on a 433 MHz
Alpha is claimed to do it in around 0.1 microseconds (and less than 1
microsecond on a fast Pentium).


Paul
--

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