Re: make CGEN a less moving target?

[Manuel Kessler <mlkessle at cip dot physik dot uni-wuerzburg dot de>]

Hello list,

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). You may find it, if
interested, at http://savannah.nongnu.org/projects/m16c/. Unfortunately,
it is a quite CISC like architecture, for which support in CGEN is, uhhm,
improvable. No offense intended certainly. 
Probably part of my problem is a lack of decent fluency in Scheme, but I
promise to better myself.

On Tue, 10 Dec 2002, Doug Evans wrote:

[...]
> 
> - I've always wanted to be able to handle the x86 ISA better.
>   [and ciscy isa's in general]
> 
[...]

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.
After some problems with my own M16C port when defining non-contiguous
fields (define-multi-ifield) I tried the ia32.cpu description and got the
same error as in my case:

ERROR: In procedure map:
ERROR: Argument out of range: (0 0 2 5)

As said before, I am not (yet) capable of interpreting this error
correctly, 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? 

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. So 8 should be a reasonable value. However,
many instructions are 16 bits or longer. Therefore I have to spefify
several instruction fields (for example a second operand field) with bit
numbers above 8. Will CGEN detect such cases and behave properly? Well, I
tried and it does generate some code, but as I am not yet at the stage of
building a complete application as gas or objdump, I can't really tell
whether the result is correct.

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), as described in the manual, section 3.15 (Modes). 
However, this was rejected as "mode AI not supported". Is this just an
oversight, not supported or am I simply off track here? For now, I
replaced it with SI and mask the superfluous bits, but AI would be more
descriptive and accurate.

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. Clear? Is there any
chance to specify this addressing-fiddling with prefixes in CGEN?

Thank you very much for this fine piece of software and of course for
reading down this far, considering my sort of newbie questions.

Ciao,

	Manuel

PS: Oh well, I am using snapshot-20023011, and yes, I have read the manual
several times.