Date: Fri, 29 May 92 16:56:00 CDT
From: csaba AT vuse DOT vanderbilt DOT edu (Csaba A. Biegl)
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: How Fast (??) part 2
Status: O


>> void main(int argc, char   *argv[])
>> {
>>	short		lineptr[MAXKERN];
>>	short		i, j, t;
>>	short		ix, nx, ny, nxh, nyh, np, *coefptr;
>>	short		ky, kx, nc, nxny, offset;
>	^^^^^
> If you only use small model (small amount of data) and short integers,
> gcc cannot make use of it's main advantage: (almost) unlimited space
> and 32bit int's.
>
> As gcc optimizes on an intermediate level -- not on CPU-instruction
> level as MSC does -- it cannot use the CPU resources as efficient as a
> hardware specific compiler can.
>
> So when the very same sources are compiled with gcc and with a native
> cc, the native cc usually wins. (It also does on this rs6000, eg.)
> Ok. Only if the native cc optimizes well, unlike TCC, eg.
>
> But as soon as you need 32bit int's, MSC will look rather poor.
> Usually, you cannot use the same sources for MSC or TCC, which you can
> use for gcc -- you will run into problems with 64K-segments, 16bit
> int's etc. Or at least with library functions on other Unix-cc's.

> (This was *the* problem of the gnu-ish project!)
>
> - Thomas
>
> greve AT rs1 DOT thch DOT uni-bonn DOT de
> unt145 AT dbnrhrz1

Actually, there are two more problems with using 16 bit shorts in
protected mode 32 bit 386 programs:

(1) The 386 encodes the operand size using only 1 bit
    of the opcode for the most commonly used instructions. In real and 16
    bit protected modes this bit selects between one and two byte operands.
    In 32 bit protected mode the bit selects between 1 byte (char) and
    4 byte (int, long) operands. The "other" non-single byte operand size
    is selected by an instruction prefix byte in both modes. The above code
    when compiled with a 32 bit compiler will contain a lot of these prefix
    bytes which increase code size and slow down execution.


(2) Most of the integer arithmetic in the code will be performed using
    the native "int" precision, i.e. 32 bits. Thus, the compiler will
    have to output conversion code whenever a 16 bit operand is fetched.


Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu