From: Groepaz (groepaz_at_gmx.net)
Date: 2003-09-11 16:27:14
On Thursday 11 September 2003 11:52, Ullrich von Bassewitz wrote:
> There's always a situation where the compiler won't spot a chance to
> improve the code.
well yes ofcoz, but thats no reason not to improve it :=P at this point i am
wondering that (and why) opt65 doesnt catch this one either ('coz its a
really simple one) - working on that :=P
> > 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.
mmmh.... bad :( need to find a solution to teach it to opt65 then :=P (my
pattern based approach catches it, but due to its brute-force nature its
kindof slowish :=P)
> > 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.
mmmmh... i've stumbled about a handful cases now where a branch could have
been really handy.... mmmh. could a possible workaround be using a macro like
this...
.macro inc_cc foo
.proc
bcs @l:
inc foo
@l:
.endproc
.endmacro
and then use that in my C inline macro? mmmh..... the question then would be,
how to include that macro in the generated asm without manually patching it?
whats the problem at this point anyway? i reckon that it does work with a
local label and with the macro used only once - so is it really just that?
shouldnt a simple feature to generate unique names for labels solve it then?
> > 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!
greaaat.... it'll help a lot with speeding up that thingy :)
> > 1) additional pseudo-variables for the X and Y registers so that kinda
> > macro can be written more efficiantly
> 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.
mmmmh :(
even something that loads AX with swapped byte order would be cool :=P (coz
when working with 8.8 fixedpoint, which is pretty common, you often need just
the highbyte for certain operations - and the optimizer seems to miss the now
needed ldx/txa sometimes (however it always removes the unneeded lda))
> > 2) i am wondering why the optimizer doesnt change the lda/tay into ldy
>
> Maybe because it's not perfect:-)
must be.... opt65 catches this one fine :o) (and its far from perfect too :=P)
> 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.
yeah i noticed that already.... one time it was even smart enough to spot a
"peephole" in my handwritten asm (shame on me :=P). however my main concern
was if not using __AX__ could potentially break something, resulting in wrong
code...
> > - 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.
tjam... it is :o) well not really, but the workaround i am using is like a)
declare those arrays "const" and b) align the .rodata segment properly -
works fine so far :) i'd like a somewhat cleaner solution though :=P
> > - 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.
mmmmh.... i'm planning to use the joystick stuff and the clock call, dont
think i need anything else there.... mmmmh gotta lock at it more closer :)
gpz
----------------------------------------------------------------------
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 19:18:33 CEST