From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-09-11 11:52:25
On Wed, Sep 10, 2003 at 05:26:50AM +0200, Groepaz wrote:
> two things here... 1) i think the immediate eor after immediate lda should
> really be catched by the optimizer :)
There's always a situation where the compiler won't spot a chance to improve
the code.
> 2) it maybe a nice possible
> optimisation to use a branch/increment type of code for the highbyte when
> adding an unsigned char to an unsigned short.
There is no separate code generation for characters in most cases. According
to the C rules, for arithmetic operations on integers, the usual integer
promotions apply, which means that the addition works with integers, not with
chars. The compiler is not smart enough to find possible exceptions. The
optimizer will sometimes remove high byte operations, but since the compiler
doesn't build a parse tree in memory, but generates code on the fly, there's
no chance to spot this in the parser.
> 1) for the heck of it, i cant find out how to make the branch work :=P neither
> a local label, nor a "*+3" or anything else i could think of would do the
> trick...any ideas? :) (sth to generate a unique local label could be a
> solution)
There is no easy way to work around this, and I don't think it's really worth
the effort.
> 2) if any of the arguments passed to the macro are register variables, the
> resulting code will be all wrong - it generates references to bogus memory
> locations instead of the register variables :=P
Fixed, thanks!
> 1) additional pseudo-variables for the X and Y registers so that kinda macro
> can be written more efficiantly
This will not work in most cases, which means that people will start to
complain. Because the 6502 has very limited registers, and all registers
besides the accu are special purpose, loading the Y and X registers will in
most cases destroy A and vice versa. Code like
void f (char b)
{
char c;
....
__Y__ = b;
__A__ = c;
....
}
will not work, the same is true for
void f (char b)
{
char c;
....
__A__ = b;
__Y__ = c;
....
}
There is simply no way for the compiler to load one register without a high
chance for using some other. This is the reason why there are no __Y__ and
__X__ pseudo variables.
> 2) i am wondering why the optimizer doesnt change the lda/tay into ldy
Maybe because it's not perfect:-)
> - what impact does it have if i write inline-macros and i dont load parameters
> using the __AX__ pseudo-variable but directly like in the uaddsc macro above?
> i think it shouldnt make a difference except that using __AX__ will help the
> optimizer to eg remove the lda/ldx alltogether if the value is in a/x
> currently anyway....but maybe there is more :)
The use of __AX__ in macros together with the comma operator means that you
can use this macro in expressions. If you don't do it this way, it will also
work, but the compiler may not accept the macro in an expression. Since all
optimzations take place in the back end, removal of unused code does not
depend on using __AX__ vs. inline assembly.
> - i'd like to page-align some global arrays (since that saves some cycles for
> free on 0x100 byte tables, avoiding crossing page-boundaries) ... is that
> possible in C somehow?
Nope.
> - how much do the c64 libraries depend on the system interupt, ie $ea31 beeing
> called frequently? will it for example affect the clock() call if i use my
> own interupt handler? (i'd like to skip the kernel stuff alltogether and just
> do some simple joystick stuff)...i need a working clock/time for syncing :)
It will affect the clock, the mouse, the rs232 interface and maybe some
others. You can work around that by not using the mouse, and others and
updating the clock stuff in your own interrupt handler.
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 : 2003-09-11 11:53:30 CEST