From: Groepaz (groepaz_at_gmx.net)
Date: 2003-09-12 01:38:38
On Thursday 11 September 2003 20:39, Ullrich von Bassewitz wrote:
> The inline assembler doesn't accept macro names. In fact, it accepts only
> valid 6502 opcodes, label names and nothing else (not even .byte or
> similar). This is a deliberate decision, since the code is translated into
> an abstract form so it can be handled by the optimizer later. Having
> unknown instructions would break the optimizer.
ok i see
> > shouldnt a simple feature to generate unique names for labels solve it
> > then?
>
> Yes - if you come up with something that makes this feature "simple".
mmmh.... ok.... let me just try to come up with something, it doesnt seem to
be super simple now i think of it (:=P) but it cant be really hard either (i
hope :))
so... first of all, since it works within one single macro invokation (or
better, within a single occurance in inline asm in general) there isnt a
general problem with emitting labels from within inline asm...
second, the real problem is not generating unique labels by itself, but the
problem is to let the inline asm know when to generate a new label and
when/where those labels are referenced....the main problem beeing here that
each single __asm__ statement must be looked at seperatly here...
mmmmh... so what about this... (this exploits that the preprocessor isnt
really a single pass but the input stream goes directly into the
compiler...uhm :))
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
that should allow labels in inline asm in both macros and functions with the
following restrictions:
- numbers of labels in macros can be used only once per macro (ofcoz! :=))
- also in a C functions several "chunks" of inline asm can not share the same
label numbers - UNLESS the asm occurs in macros!
- right after a macro expansion, label numbers used by the macro will clash
with label numbers in further inline assembly in the function outside a macro
(this could be solved by incrementing local_prefix AFTER each macro expansion
too....mmmh i think that could be kinda difficult though right? :=P)
mmmh...could that even work? :)
> > even something that loads AX with swapped byte order would be cool :=P
>
> I can see that you have a situation where this might be useful. But how
> generic is this and how many people are writing code making use of this
> feature? If I would sit here, bored and waiting for something to do then I
> would be happy to add all sorts of esoteric features. Unfort^WFortunately
> this is not the case, so I try to concentrate on the things that are more
> important, otherwise I don't get anything done.
*GGG* i'm just kidding :) actually i think that this sort of things should
also be "rearranged" by the optimizer.... __AX__ (and i think theres __EAX__
or sth too?! mmh :)) really is all the inline asm by itself should feature -
again, the concern is to possibly brake something by manually loading
stuff...fine if thats not the case :)
> Why not develop opt65 into a tool that can be run as an intermediate
> processor before running the assembler over the compiler generated code?
> This would ease the task of testing new peephole optimization stuff which
> can later go into the builtin cc65 backend. Hey, you can even write it in
> perl to make it unreadable:-)
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)... well and i hacked some rather dumb pattern based thingy thats
basically useful to test some peephole rule without actually coding much :)
(its dog slow in return :=P) ... i'll upload it all as soon as i dont see any
more room for optimizations left in that raycasting thingy (its surprising
13fps now with just a few snippets of asm in macros...really nice :))
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).... then my pattern based thingy removes some more (eg the highbyte add
on short+char).
however, optimizing the code with opt65 still gave only minor speed
improvements compared to what certain inline macros could gain :)
> No. The only thing that may happen is that the compiler refuses to
> translate the code, if it is no valid expression because of the missing
> __AX__.
ok thats good to hear....so i can improve some of those macros a bit more i
think :) .... cant await the snapshot with the macro stuff fixed :O)
one more thing though....
this macro... (you reckon why asking for __X__/__Y__ eh? :=P)
#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__)
used in an if-expression...like
if(getblock(x,y))
{ ...
will result in wrong code (i think the condition was not checked at all,dont
remember exactly sorry :=P), whereas
if(getblock(x,y)!=0)
{ ...
will just work as expected.
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-12 01:44:02 CEST