🚀 go-pugleaf

Stan Ryckman wrote:
> 
> 
> Well, that wouldn't work  :-)  For 80, you'd shift by 6 and 4 and
> add the results.  (80 == 64 + 16).
> 

Yes, you're right. I was half asleep when I wrote that you'd shift by 10 and 
8... Well, I'll try to pay more attention. Another thought about shifting just 
emerged. At one time I was writing a program that did something like this:

	short	n = 10, m;
	m = n << 8;
	...

That worked in a debug version, but when compiled using optimization, the 
compiler (MSC 7 for NT) produced incorrect code:

	MOV	AX,[n]
	MOV	AH,AL
	...

It decided MOV AH,AL would be faster than

	MOV	CL,8
	SHL	AX,CL

but it left out XOR AL,AL (ie. resetting the low byte). To get around this I 
used a variable:

	short	c = 8, n = 10, m;
	m = n << c;

Surprising enough, the compiler didn't optimize use of c out, but produced 
correct code (MOV CL,8 and SHL AX,CL).

> It's not that much harder to implement this in a compiler.  I used
> one on a 68000-based system that did all multiplies by constants
> in this manner, both for indexing and for expressions, and used
> the MUL instruction if it would be faster.  So, i*0x555 would use
> the MUL instruction, but i*0x7ff would use shifts (multiply by 0x800
> with a shift, then subtract the original).  It "knew" how expensive
> the instructions were, and used whatever it thought best.
> 

That's a clever compiler. I haven't come across one yet in the Intel world, 
though. It seems that the compiler writers here spend more time to add features 
that make your programs bulkier (like OOP) rather than make better optimizers. 
The optimizers have become a _little_ better nowadays, however. Maybe one day...

Later,
 AriL
-- 
All my opinions are mine and mine alone.