Message-ID:	<329E2EDA.E76@gbrmpa.gov.au>
Date:	Fri, 29 Nov 1996 08:43:53 +0800
From:	Leath Muller <leathm AT gbrmpa DOT gov DOT au>
Reply-To:	leathm AT gbrmpa DOT gov DOT au
Organization:	Great Barrier Reef Marine Park Authority
MIME-Version:	1.0
To:	Glen Miner <gminer AT Newbridge DOT COM>
CC:	djgpp AT delorie DOT com
Subject:	Re: Optimization
References:	<57hg9b$or5 AT kannews DOT ca DOT newbridge DOT com> <329C4CD4 DOT 7474 AT cornell DOT edu> <Pine DOT SUN DOT 3 DOT 90 DOT 961127095705 DOT 25056B-100000 AT coop10> <329C62F6 DOT 23F6 AT stud DOT warande DOT ruu DOT nl> <57k1et$4od AT kannews DOT ca DOT newbridge DOT com>

> >I believe in 32-bit protected mode most dword register ops are faster
> >than the equivalent 16-bit ones on a 486 and above. Certainly on a P6
> >16-bit instructions are disproportionately slow.
> >In any case I haven't seen djgpp generate any optimizations which utilise
> >the byte registers; AFAIK it uses them only in straightforward byte ops.

> That is quite sad. I mean, in a register starved architecture, I can't do
> the compiler a favor by giving it byte sized data... Hmm. Someday I'll be
> able to afford a real processor...

Intel have overcome a lot of the problems associated with the lack of
registers.
But then, its still nowhere near as good as the ol' Motorola
lines...Mmmm,
8 32 bit data registers, 8 32 bit address registers... :)
 
> >I have no idea how good your C coding skills are, so don't be offended,
> >but careful C code can speed up a sloppy implementation by ~ 100%:
> >on the other hand, there are limits.
 
> I've been optimizing it under a different compiler for the better part of
> 6 months. :) The implementation is approaching perfection... I'm just
> trying to make sure that I'm doing everything I can to make the new
> compiler happy :)

What works under one compiler, doesn't always work on another.
Especially
with DJGPP... DJGPP is an excellent compiler... But once you learn how
to
use AT&T asm, your cruising...

Leathal.

- Raw text -