From: Spiro Trikaliotis (trik-news_at_gmx.de)
Date: 2001-10-14 14:07:08
Hello Uz,
I have a question regarding the use of int which I have not found documented
so far (correct me if I'm wrong).
Let's say, we have the following little test program that defines the TA und
TB as ints instead of 2 times 2 bytes:
#include <c64.h>
struct cia6526new {
unsigned char pra; /* Port register A */
unsigned char prb; /* Port register B */
unsigned char ddra; /* Data direction register A */
unsigned char ddrb; /* Data direction register B */
unsigned int ta; /* Timer A, low byte */
unsigned int tb; /* Timer B, high byte */
/* snipped */
};
#define CIA1NEW (*(struct cia6526new*)0xDC00)
int main( void )
{
int a = CIA1NEW.ta;
}
This can be read very nice by a human.
As we all (should) know, the 6526 latches the timer whenever the low byte is
read and releases the latch when the high byte is read, so it has to
accessed in low/high byte order.
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.
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
union {
unsigned int ta; /* Timer A */
struct {
unsigned char ta_lo; /* Timer A, low byte */
unsigned char ta_hi; /* Timer A, high byte */
};
};
which would allow int and byte access to the timers.
Just my EUR 0.02,
Spiro.
PS: I'm sorry that I haven't worked on the thing we talked about, but I'm
busy at the moment to do this big thing.
----------------------------------------------------------------------
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