Re: [cc65] ca65 Z80 support

Hi,

On Sun, Dec 04, 2005 at 10:23:41PM +0100, Ullrich von Bassewitz wrote:
> > Ones with 'Z' are conditioned opcodes (Z is the condition here, other one
> > can stay here as well). At the level of CPU opcodes there are simply another
> > opcodes. Now how can I parse the source?
> 
> Determining the addressing mode is done in one of the ea... modules. You would
> have to write such a module for the Z80. Making the condition code specifiers
> reserved words in the scanner is possible, and probably the best idea.

I've simply created an instruction table for Z80, and used different handler
functions in InsDesc struct, totally ignores the addressing mode field (I
don't use it). I've started to code an EvalZ80() function which would parse
the rest of the line to get with the number of arguments (separated by
comma), and the type of them. Each handler would call this EvalZ80() first,
check number of params and types and then decide if it's valid and generate
code if so. I guess this is not it whould be done ;-) It works well for
instructions don't need any parameters (TokIsSep() can be used to detect
if have bogus params). However problem occures to write the real part of my
EvalZ80(). I would like to classify assembly source line (after opcode name
itself) in this way:

[label:]  opcode  [param1 [,param2]]
		  ^
		  we are here

where paramX can be for example:

(HL)		->   MODE_HLINDEXED
(IX+const)	->   MODE_IXPLUSCONSTINDEXED (and value of const stored somewhere
                                              well at least the expression which
			                      is enough to genrate signed byte
                                              offset needed here)
BC		->   MODE_REG_BC
(BC)		->   MODE_BCINDEXED
(const)		->   MODE_MEMORYLOC          (and value of expression for WORD
					      const stored)

and such ...
Then handlers can use these MODE_ constants to check if addressing mode
is valid and if it is what code should be generated (probably in the form
of having an array contain every valid combination of these constants,
type byte(s) should emit and the optional variable stuff value and type
(signed byte, word)).

Sorry for this mess, but because of my bad English I can't explain myself
easily ...


> > But I don't want to mess up the whole
> > source without asking first the "best" solution for the problem of support
> > of a totally different CPU from the already-well-supported 65xx ones int
> > ca65. Since Z80 differs from these CPUs a lot, I guess I've got quite big
> > change in tokenizer and such, and I don't want it, if you won't accept my
> > code because of its uglyness.
> 
> There are also 65xx CPUs that need other reserved identifiers, the 65CE02 for
> example has a Z register. If this is of any help, I can add the necessary
> hooks in the scanner for CPU dependent reserved identifiers.

My problem that I haven't had got an overview on the full ca65 yet. So I
stucked at my EvalZ80(). If you can explain (or even do) to add Z80 (and
possibly other if it's a general solution) specific stuffs into the scanner
then please do. Also I will check out the source a bit deeper, since I've
spent about quarter a hour to check the source no wonder that I don't
understand all of the source at once in the begining :) However as most
people I'm lazy, and I want everything fast :)

Thanks for your help in advance,

-- 
- Gábor
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.