From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-09-11 20:39:19
Hi!
On Thu, Sep 11, 2003 at 04:27:14PM +0200, Groepaz wrote:
> 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...
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.
> 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?
Yes.
> 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".
> 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.
> must be.... opt65 catches this one fine :o) (and its far from perfect too :=P)
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:-)
> yeah i noticed that already.... one time it was even smart enough to spot a
> "peephole" in my handwritten asm (shame on me :=P).
This happens to other people, too:-)
> however my main concern
> was if not using __AX__ could potentially break something, resulting in wrong
> code...
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__.
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 20:39:40 CEST