From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-10-14 15:47:33
Hi!
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
txa
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:-)
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:42 CET