Re: [cc65] access order when doing int operation

Date view Thread view Subject view

From: Ullrich von Bassewitz (
Date: 2001-10-14 15:47:33


On Sun, Oct 14, 2001 at 02:07:08PM +0200, Spiro Trikaliotis wrote:
> Compiling this program shows that indeed, the low/high-byte order is
> preserved. Anyway, I ask myself if this is a *quaranteed* behaviour or if
> there are circumstances where this order may be reordered (for example, by
> the optimizer?), or if it might be something that might change in future
> revisions of CC65? If it is guaranteed, this might even be better since it's
> less likely that someone reverts the order in which the timer bytes are
> accessed.

No, this is not guaranteed and may change any time. The optimizer may even
remove one of the accesses completely, as in

   	int main( void )
   	    unsigned char a;
   	    a = (CIA1NEW.ta >> 12);
   	    return 0;

which is translated to

   	; a = (CIA1NEW.ta >> 12);
   		ldx     $DC04+1
   		lsr     a
   		lsr     a
   		lsr     a
   		lsr     a
   		ldy     #$00
   		sta     (sp),y

Since cases like this one, in which you need a specific order are quite rare,
it wouldn't be a good idea to make guarantees like the one you are talking
about. For one, there may be cases where a different memory access order is
needed, second, it would seriously limit the code generator and optimizer.

> Another question is if it might be that CC65 will support unnamed structs
> and unions in the future? If so, one might replace the definition of ta_lo
> and ta_hi in struct __6526 by

Unnamed structures are available in C++, but they are not part of the C
standard (maybe this has changed with C9x, I will have to check that). So yes,
having anonymous structures is a good idea, but it would violate the ISO
standard and would be a compiler extension not to be used for portable
programs. I will add it to my TODO list, let's see what is happening then:-)



Ullrich von Bassewitz                        
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:42 CET