From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-09-14 13:27:14
On Fri, Sep 12, 2003 at 01:38:38AM +0200, Groepaz wrote:
> a) everytime a macro expansion takes place a certain counter "local_prefix" is
> incremented
> b) inline asm gets a format-string added that works like this:
>
> __asm__("beq %l", 1); // generates labelnr=1
>
> the actual label is now formed as "@%4d%4d",local_prefix,labelnr
I've had a look at the preprocessor: What you're suggesting is rather
difficult to add to the current implementation[1]. But because of some other
problems with the current implementation, the preprocessor may get a rewrite
at some time, and then I may consider your proposal.
> that should allow labels in inline asm in both macros and functions with the
> following restrictions:
[...]
Here is one more: The concept does not allow generation of local labels
outside of macros, because it relies on a counter incremented when a macro is
expanded.
> its almost at that state actually :) i've made some minor modifications so it
> runs flawlessly on cc65 generated code, and currently try to teach it some
> more little details (eg removing immediate lda followed by immediate
> ora/and/eor)...
This and the load/transfer stuff is in the current snapshot, but I do somehow
regret adding it, because it saves just a few bytes, at least when compiling
the samples and libraries. For new peephole optimization proposals I would
suggest a few statistics highlighting the advantages/disadvantages.
> however, the main things that opt65 catches atm is a lot of unnessary lda/tax
> ldx/txa etc stuff (~400 lines removed on ~5000 lines of asm for the raycaster
> - although i have to make better figures here, the numbers seem to be
> somewhat large, there must be a bug in the linecounter in opt65 somewhere
> :=P)....
I do really, really doubt this number, at least for compiler generated code.
It may be true for inline asm or use of __AX__/__EAX__, but in this case it's
a problem if the asm code. Within the samples and library sources, there is
exactly ONE module that profits from the optimization - and the reason is that
this modules makes heavy use of the is... functions from ctype.h that are
inline assembly.
> this macro... (you reckon why asking for __X__/__Y__ eh? :=P)
[...]
> will result in wrong code (i think the condition was not checked at all,dont
> remember exactly sorry :=P), whereas
Yes, it's a bug, thanks for the report! When using the __AX__ pseudo variable,
the compiler doesn't make sure that the condition codes are set, which causes
the test to fail. It works in most cases, because a load will set the
condition codes right (which is the reason why the macros from ctype.h work),
but in your macro this is not the case because of the last ldx. The compiler
from the head branch does actually remove the complete code from the macro,
because it finds out that all the loads and stores are useless without the
final test:-)
BTW, your macro is a good example of code that will not work in certain cases
as pointed out by me in my last mail within this thread:
> #define getblock(_x,_y) (unsigned char) \
> ( \
> __AX__= (_y), \
> __asm__ ("txa"), \
> __asm__ ("tay"), \
> __AX__= (_x), \
> __asm__ ("lda %v,x", worldptr_lo ), \
> __asm__ ("sta ptr1"), \
> __asm__ ("lda %v,x", worldptr_hi ), \
> __asm__ ("sta ptr1+1"), \
> __asm__ ("lda (ptr1),y"), \
> __asm__ ("ldx #%b", 0), \
> __AX__)
The second assignment to __AX__ will destroy the Y register just loaded in all
but the most simplest cases (where _x is a global variable).
Regards
Uz
[1] The current preprocessor code loops until no more macros are found instead
of doing macro expansion recursively. This means that there is no easy way to
determine if the preprocessor is currently expanding a macro, which is the
cause of several problems. However, it works most of the time, so it's not
urgent to fix it.
--
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-14 13:28:13 CEST