From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Pereira Habkost Subject: Re: Compilers Date: Fri, 28 May 2004 11:47:00 -0300 Sender: linux-8086-owner@vger.kernel.org Message-ID: <20040528144700.GH21172@duckman.distro.conectiva> References: <200405281142.38116.dg@cowlark.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82evfD9Ogz2JrdWZ" Return-path: Content-Disposition: inline In-Reply-To: <200405281142.38116.dg@cowlark.com> List-Id: To: linux-8086@vger.kernel.org --82evfD9Ogz2JrdWZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, all, On Fri, May 28, 2004 at 11:42:38AM +0100, David Given wrote: >=20 > I've tried to compare the code produced by cc and bcc. I'm not entirely s= ure=20 > this is a fair comparison because I don't think I managed to invoke bcc's= =20 > optimiser correctly, but here you go anyway. Fixed-pitch font recommended. >=20 > The source: >=20 > ---snip--- > extern int printf(char* format, ...); >=20 > int fnord(int i) > { > int count =3D 0; >=20 > while (i) > count +=3D i--; > return count; > } >=20 > int main(int argc, char* argv[]) > { > printf("Hello, world!\n"); > printf("%d\n", fnord(argc)); > return 0; > } > ---snip--- >=20 > The output: >=20 Nice, I would like to compare with the code that gcc-8086 is producing currently, too. Please note that there could be hiddend bugs that I've seen yet. :) I've used -O3 for compilation: (GNU as AT&T syntax used) _fnord: push %bp mov %sp,%bp movw 2(%bp),%dx movw $0x0,%ax cmpw $0x0,%dx je .L15 =2EL13: addw %dx,%ax addw $0xffffffff,%dx cmpw $0x0,%dx jne .L13 =2EL15: leave ret Some things that can be noted: There is not 'dec' instruction, yet. It can be added. It is using 'leave' for function exit. IIRC, it is a 80186 instruction, so it is better have an option to use is better have an option for the user choosing to use it or not. One bug appeared: it is using 2(%bp) for getting the function parameter. It doesn't look correct. :) A -fno-frame-pointer option would be nice, too. I guess that most people wouldn't want them on ELKS, and it will make code smaller and use less stack space. > BCC CC >=20 > _fnord: _fnord: > push bp push bp > mov bp,sp mov bp,sp > dec sp push si > dec sp xor si,si > xor ax,ax .4: > mov -2[bp],ax cmp 4(bp),#0 > jmp .2 je .3 > .3: mov dx,4(bp) > mov ax,4[bp] mov cx,dx > dec ax dec cx > mov 4[bp],ax mov 4(bp),cx > inc ax > add ax,-2[bp] > mov -2[bp],ax add si,dx > .2: =20 > mov ax,4[bp] =20 > test ax,ax > jne .3 > .4: > .1: .3: > mov ax,-2[bp] mov ax,si > mov sp,bp > pop bp > ret jmp .sret >=20 > The main() function produced by both compilers is identical apart from mi= nor=20 > differences: cc likes using pop to do a stack retraction, where bcc does = a=20 > mov sp,bp instead. This means that cc produces smaller but slower code, b= ut=20 > bcc produces faster code. *shrug* >=20 > cc seems to have better register allocation and avoids using stack slots = when=20 > it doesn't need to. bcc has put the loop conditional at the bottom instea= d of=20 > the top; not sure why, it makes the code larger. >=20 > Given that currently the ELKS kernel is about 70kB of code, a little=20 > problematic given the 64kB limit, anything that will make the code smalle= r is=20 > good! Plus, cc is a real ANSI compiler. When I get some spare time I'll s= ee=20 > if I can have a look at building the ELKS kernel on Minix. Since the two= =20 > compilers use the same calling conventions I don't think it would be terr= ibly=20 > hard and I'd be interested in seeing what sort of differences there are i= n=20 > real code. >=20 > Incidentally, if you're interested in what ELKS might end up being, I str= ongly=20 > suggest you install a copy of Minix on something. It's fascinating just h= ow=20 > usable it is, on such limited hardware. >=20 --=20 Eduardo --82evfD9Ogz2JrdWZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAt1DkcaRJ66w1lWgRAsDXAJ9Ly3PgwxzOdUzwuNVjoJDb1cQRtACeNLDj ZKOf9iEsTlMsTkFNTHWI6+s= =IQSm -----END PGP SIGNATURE----- --82evfD9Ogz2JrdWZ--