Re: [sdcc-devel] [ sdcc-Feature Requests-966755 ] only use direct assignment if it's faster

[Phuah Y. K. <yk....@ne...>]

Erik Petrich wrote:
> You are probably just a bit too quick for Sourceforge's cvs mirrors. The
> last I heard, there was up to a 5 hour (worst case, if nothing is
> broken) delay between the authenticated and anonymous cvs servers. The
> 1.71 revision is definately checked in.

Ah, thanks. Will try again tommorow. :)

>>Developers, please tell me what's next to do to get this commited. Thanks.
> 
> I think the patch does what you intend, but I'm not entirely convinced
> that the change in generated code is always better. At the very least, I
> think it should be limited to 8-bit operands, since literal assignment is
> always faster than increment/decrement for 16-bit and 32-bit operands on
> the 8-bit targets that SDCC currently supports.

Yeap, that hits me as well. But the mcs51 port does have a "inc dptr" 
opcode which increases a 16 bit operand.

On the other hand, I am also not sure whether all the ports have a 
"dec/inc" opcode. I just did a ramdom check on the pic/ port, seems that 
the line for doing genMinusDec is commented out.

Erik, mine explaining why my patch failed to z80 port, is that a bug in 
the z80 port? I have attempted to troubleshoot the problem, but given my 
zero-knowledge on the z80, failed terribly.

> Please don't feel that your patches are being rejected; I am just trying
> to understand the full consequences of the changes before applying them.

Don't worry. I just want to improve on the stuffs so you guys would not 
need to do much (like add comments) etc...

Again, I sensed a need for tests on optimization, to "understand the 
full consuquences of the changes", since I myself does not. Though, its 
beyond my capabilities to architect the regression tests for optimization.

Cheers,
Phuah Yee Keat