On Mon, Dec 6, 2010 at 10:41 AM, Ullrich von Bassewitz <uz@musoftware.de> wrote: > On Mon, Dec 06, 2010 at 09:49:08AM -0600, Dave Dribin wrote: >> I tried using inline assembler, and it still got optimized out: > > This is why I didn't write "inline assembler". You may want to use a separate > assembler module. Ah... I missed that distinction. ;-) > At least with the current structure, this is not possible, otherwise I would > have added this already. The optimizer traces uses of registers, loads and > stores. And if these information is lost, because parts of a function isn't > optimized, it is not possible to use optimization for the remainder. Keep in mind I don't know anything about the optimizer, would it be easier to optimize out a dummy variable? i.e. is it difficult for the optimizer to realize in this code that the pusha/incsp1 is unnecessary? 000000r 1 ; 000000r 1 ; { uint8_t dummy = IO_Read8(0x2002); } 000000r 1 ; 000000r 1 AD 02 20 lda $2002 000003r 1 20 rr rr jsr pusha 000006r 1 20 rr rr jsr incsp1 But.... I think I have found a good work around. Using inline assembly + the 'bit' instruction seems to work. For whatever reason, the 'bit' instruction does not get optimized out. For my code, I don't care if the result goes into A or not, yet it still causes the hardware register to be read: #define IO_ForceRead8(_A_) __asm__ ("bit %w", _A_); 000000r 1 .proc _foo: near 000000r 1 000000r 1 .segment "CODE" 000000r 1 000000r 1 ; 000000r 1 ; IO_ForceRead8(0x2002); 000000r 1 ; 000000r 1 2C 02 20 bit $2002 000003r 1 ; 000003r 1 ; IO_Write8(0x2006, 0x20); 000003r 1 ; 000003r 1 A9 20 lda #$20 000005r 1 8D 06 20 sta $2006 000008r 1 ; 000008r 1 ; IO_Write8(0x2006, 0x00); 000008r 1 ; 000008r 1 A9 00 lda #$00 00000Ar 1 8D 06 20 sta $2006 00000Dr 1 ; 00000Dr 1 ; } 00000Dr 1 ; 00000Dr 1 60 rts 00000Er 1 00000Er 1 .endproc -Dave ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Tue Dec 7 05:12:26 2010
This archive was generated by hypermail 2.1.8 : 2010-12-07 05:12:29 CET