*dest++ = *src++;

*dest++ == *src++;

for (ct = length - 1; ct >= 0; ct- -)
   *dest++ = *src++;

MOVE.W length, Dr
BRA *+4
MOVE.s (An)+, (Am)+
DBF Dr, *-2

My question is whether compilers for the 80X86 can equivalently compile and/or optimize such C code to use the built-in string and repeat or loop instructions.

This question, of course, derives from a running argument I have with a friend who believes Motorola processors do not handle strings efficiently. All of the iNTEL one-byte string instructions have two-byte, single instruction equivalents in the M680X0 instruction set (except for the rarely used down address mode of cmps, which takes two M680X0 instructions to implement). My impression is that the less general iNTEL string set is less accessible to programmers using high-level languages. Thus my question.

Joel Rees
South Salt Lake City, UT

A

Interesting question. I would say that it all depends on the compiler's optimization scheme. If you used a standard subroutine such as strcpy (), memcpy(), or strcmp (), the compiler manufacturer could easily write the function in assembly language to take advantage of the built-in operations. Intel's REPZ prefix in combination with CMPS (compare strings) and SCAS (scan strings) can work extremely fast. I doubt that a compiler would normally use these.

Using standard compiler functions to perform common operations permits it to use faster operations, even if they do not match the data type. For example, memory copying can be performed faster if the size of the data moved matches the bus width. A standard function could be "smart" and do half or a quarter of the move instructions plus maybe a few single character moves and come out faster than moving things singly.

Optimizations get to be really tricky business. The string instructions may be faster than a series of discrete instructions if there is no instruction cache in the processor. The memory fetches for the instructions would outweigh the extra memory cycles for the individual bytes. A large instruction cache would tend to make a set of discrete instructions faster, because no instruction fetches would be required after the initial ones.

You might have coded your example as

ct = length;
while (ct--)
   *dest++ = *src++;

Q

I have a couple of questions that I hope you can help me with. I have seen mention of them in various books, but frankly I can't remember where. The books did not really explain them anyway to the degree that I want.

main ()
   {
   code
   }
function 1
function 2
function 3

function 1
function 2
function 3
main ()
   {
   code
   }

I would like to hear some explanation of this subject in greater detail. I know that there isn't a lot of detail to give, but any would help.

By this I assume that how I list my variables is important. It seems I should do the following:

main ()
{
int     one,two,three,four;
float   eny,mine,mo;
char    first,second,third;

program
}

Lyle O. Haga
Englewood, CO

A

To the human, the order varies according to purpose. For example, many times I have main first. Other times I keep it in a separate file. Still other times it goes last, especially when it is surrounded by #ifdef DEBUGMAIN / #endif. I frequently put a main() function in files which contain functions that are used as my personal library. The main function contains calls that test the operations of the functions. When I am testing the functions, DEBUGMAIN is #defined. When I am using them in other programs, DEBUGMAIN is not #defined.

On some processors, if the data item is 2 bytes, it must reside at an even address. If the data item is 4 bytes it must reside at an address divisible by 4.

For individual data items, the processor keeps these stored at whatever alignment is required. Unless you compare the actual addresses, you have no indication of their alignment.

With structures, alignment does pose some interesting problems. For processors that require alignment, the compiler puts filler or packing bytes between members to ensure that alignment is proper. If you print the sizeof of a structure, it may be larger than the total of its members.

On the PC, which has no alignment requirements, some compilers using packing bytes, some do not, and some give an option to go either way.

int compare(const void *, const void *);

typedef int (*_QSORT_CMP_)(const void *, const void *);

....
qsort(array, nelem, elemsize, (_QSORT_CMP_)user_function);
....

int user_function(unsigned char **a, unsigned char **b)
    {
    return( strcmp(*a, *b) );
    }

This typecasting can be useful when dealing with search functions such as bsearch. Imagine a structure defined as:

typedef struct {
   int len;
   int ID;
    int year;
    ....;
   } DATA;

#define NELEM(array)
(sizeof(array)/sizeof(array [0]))

DATA data_array[...];
int i;

for ( i=0; i < NELEM(data array) ; i-- )
   initialize_data_array(&data array[i] );
qsort(&data_array [0],NELEM(data_array), \
   sizeof(DATA), (_QSORT_CMP_)usr_fn1);

int ID;
DATA *D;

D =  (DATA *) bsearch(&ID, &data_array[0], \
     NELEM(data_array), sizeof(DATA). \
     (_QSORT_CMP_)usr_fn2);

int usr_fn1(DATA *D1, DATA *D2)
{
return ( D1->ID - D2-> );
}

int usr_fn2(int *key, DATA *D)
   {
   return ( *key - D->ID );
   }

I tried the program out on my hypertext program, InfoNavigator. It works well. The results were

/* Original file */
LINKBTG EXE  238224
/* EXEPACK version */
BROWSER1 EXE  225672
/* Tinyprog version */
BROWSER EXE  146656