Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!oliveb!pyramid!versatc!peter
From: peter@versatc.UUCP (Peter Tapscott)
Newsgroups: comp.sys.mac
Subject: Re: New Mac Rumours
Message-ID: <15682@versatc.UUCP>
Date: 28 Feb 89 01:50:01 GMT
References: <IY0io5y00UgPAM2b4a@andrew.cmu.edu> <41a2364a.a590@mag.engin.umich.edu> <70755@ti-csl.csc.ti.com> <41aa5eaa.a590@mag.engin.umich.edu>
Reply-To: peter@versatc.UUCP (Peter Tapscott )
Organization: Versatec, Santa Clara, Ca.
Lines: 34

In article <41aa5eaa.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (billkatt) writes:
>In article <70755@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes:
>>Could you please explain how a processor
>>could be optimized for a specific high level language?
>
>Sure.  Some processors (the 68000 for example) are much better suited (and
>some designed) for the c calling conventions.

It is also possible to write the c-code to produce optimum execution speed.
For example, the following four lines of code execute 4X faster than
the two lines using a FOR loop:

Fast While Loop:
        i = char_count;
        while(i--)
            destn_buffer[i] = *(source_buffer + i);
        *destn_buffer = *source_buffer;  /* get the zeroth element */.

Slow For Loop:
		for (i = 0; i <= char_count; i++)
              destn_buffer[i] = *(source_buffer + i);

This is because the while loop makes use of the DBNE (decrement and
branch if not equal to zero) instruction of the 68020, so the disassembled
code shows fewer, faster instructions.

This disproves the popular misconception that writing the c-code in the
fewest lines is the same as optimizing the code.  In many cases it is
not faster and minimizes the readability.
-- 
|----------------------------------------------------------------------|
| Peter Tapscott          {pyramid|ames|sun|vsi1|leadsv}!versatc!peter |
| Versatec, 2805 Bowers Avenue, Santa Clara, Calif 95051 (408)982-4235 |
|----------------------------------------------------------------------|