Re: make CGEN a less moving target?

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Wed, Dec 11, 2002 at 11:39:29AM +0100, Manuel Kessler wrote:
> [...]
> I am quite new to CGEN and started to write a new port of GNU binutils
> (and later on gdb, gcc, ???) for the Mitsubishi M16C family of
> microcontrollers (together with others, of course). [...]

Great!


> Is "better" the correct term here? Or is x86 supposed to be working (at
> least the partially implemented add instruction) at all, or to be seen as
> how to do a CISC example? All other cpus are more RISC like.

The x86.cpu file is, as far as I know, only meant as an example.
I believe actual generation of opcodes or simulators was never
attempted.


> [...]
> but it seems to me that non-contiguous ifields are currently
> not really supported. Is this correct, or how can I achieve the desired
> effect? 

Depending on whether these ifields contain operands or opcode
constants, different tricks may be necessary.  But CGEN can handle
several varieties of non-contiguous ifields.


> I am not quite sure how to correctly set the different *-bitsize values in
> define-isa. The architecture is 16 bits (little endian), but the smallest
> instruction is 8 bits long. [...]

The most important value is the base-insn-size.  This should be
large enough to include all opcode-like bits in the longest
instruction, so most likely 16 or even 32 for this chip.  Having
real instructions that are shorter than that is not a problem.


> [...]
> A more minor point: The architecture features some address registers,
> which may be 16 or 24 bits wide, depending on the model, otherwise being
> 16 bit. Therefore I tried to describe these in define-hardware as of mode
> AI (address integer) [... but that broke ...]

Right, some of these logical types are not usable everywhere,
sometimes for odd reasons.  Consider using HI or SI, depending on
architecture.  (It would sure be nice to generalize CGEN's type
system to represent N-bit types.)


> Finally: The architecture allows additional indirect addressing by using a
> special prefix byte, i.e. if you want to negate a register, you write
> neg.w r0
> but if you want to negate the memory value pointed to by the register
> neg.w [r0]
> the same opcode is used, prefixed by an additional byte marking the
> indirect addressing of the following instruction. [...]

One way to model this would be to consider the prefix byte part of the
opcode of the indirect-addressing variant of the instruction.  (You would
probably use a macro to generate the two variants.)  Other ways likely
include too much fiddling with C/C++ runtime flags and handmade parsers.


- FChE