Re: make CGEN a less moving target?

[Doug Evans <dje at transmeta dot com>]

Manuel Kessler writes:
 > 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?

You're basically in new territory with any CISC port.

 > 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? 

Certainly some forms of non-contiguous fields are supported.
Examples would help us provide better answers.

 > 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.

CGEN will handle such cases properly.
[At least it has with other existing in-use ports with variable-sized
instruction sets.]

 > 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.

If you send me your .cpu file I can help with this part.
Clearly you want to get this resolved sooner rather than later.
The short answer is you have to treat the models with 16 bits
separately from the one with 24 bits.

 > 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?

For the time being what if you treat them as individual insns
(recognizing all the pitfalls) and see if you can make forward
progress on your port?  Ignore the error cases (e.g. illegal pairings)
for now.

Ultimately I think we need to extend cgen to handle them.
There's just too many in x86-land.  Handling them with the
current design is untenable.