make CGEN a less moving target?

make CGEN a less moving target?

[Johan Rydberg]

Hi fellow CGEN-hackers.

From what I've seen it seems that CGEN have matured to the point
where it maybe is time to write a list of what should be included
in a CPU description, and where.  Maybe list all keywords and such.

The reason for this is that maybe someone would like to write a parser
for .cpu-files, and not use the Scheme-sources provided by Red Hat, Inc.

(define-insn ...) and similar seems pretty "stable", but there seem
to be a lot of confusion regarding the (define-isa ...) fields.

brgds,
johan

make CGEN a less moving target?

[Doug Evans]

Johan Rydberg writes:
 > From what I've seen it seems that CGEN have matured to the point
 > where it maybe is time to write a list of what should be included
 > in a CPU description, and where.  Maybe list all keywords and such.

That's a good idea.

 > The reason for this is that maybe someone would like to write a parser
 > for .cpu-files, and not use the Scheme-sources provided by Red Hat, Inc.
 > 
 > (define-insn ...) and similar seems pretty "stable", but there seem
 > to be a lot of confusion regarding the (define-isa ...) fields.

Off the top of my head, there are at least 3 big things still to be done.

- The model description needs a complete rewrite.  This has always been
  planned.  What's there now is a quick hack to get something to play with.

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

- Support for compilers.
  While supporting gcc is a nice pie-in-the-sky-ish idea, there are other
  forms of compilers that cgen should be able to support
  (e.g. dynamic compilers).

While I can understand someone wanting a parser written in C[/C++],
I always thought forcing people to learn Scheme was a good thing! :-)
Or are there other reasons for wanting to write your own parser?

Re: make CGEN a less moving target?

[Johan Rydberg]

On 2002.12.10 18:32 Doug Evans wrote:

: Off the top of my head, there are at least 3 big things still to be done.
: 
: [...]
: - I've always wanted to be able to handle the x86 ISA better.
:   [and ciscy isa's in general]

Yes, this is a big *must* I think.
  
: While I can understand someone wanting a parser written in C[/C++],
: I always thought forcing people to learn Scheme was a good thing! :-)
: Or are there other reasons for wanting to write your own parser?

Well, trying to make the CGEN cpu descriptions a less moving target
is not a bad thing, even if the reason is not to writing your own parser.

My goal, of course, is to write my own parser.  My reasons may be 
strange though.  (one of them being me not wanting to learn Scheme right now.)

brgds,
johan

Re: make CGEN a less moving target?

[Manuel Kessler]

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. 

Re: make CGEN a less moving target?

[Frank Ch. Eigler]

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

Re: make CGEN a less moving target?

[Doug Evans]

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.

Re: make CGEN a less moving target?

[Doug Evans]

Frank Ch. Eigler writes:
 > 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.

If the definition of base-insn-size has been changed to this that's a bummer.
When did this go in?

Re: make CGEN a less moving target?

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Hi -

>  > 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.  [...]
> 
> If the definition of base-insn-size has been changed to this that's a bummer.
> When did this go in?

I believe this is a practical description of what actually tends
to work with the opcodes/sim/sid runtimes, and does not relate to
any recent patches.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: make CGEN a less moving target?

[Doug Evans]

Frank Ch. Eigler writes:
 > Hi -
 > 
 > >  > 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.  [...]
 > > 
 > > If the definition of base-insn-size has been changed to this that's a bummer.
 > > When did this go in?
 > 
 > I believe this is a practical description of what actually tends
 > to work with the opcodes/sim/sid runtimes, and does not relate to
 > any recent patches.

So how about rephrase it as:
This is what the h/w first fetches to decode an insn.
For non-liw architectures this is the size of the smallest instruction.

Re: make CGEN a less moving target?

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

Hi -


dje wrote:
> So how about rephrase it as:
> This is what the h/w first fetches to decode an insn.

Dunno about that.

> For non-liw architectures this is the size of the smallest instruction.

If by "non-liw" you mean "RISC", then all instructions have the same size
and this is trivial.
For variable-length instruction sets, things just seem to work best when 
base-insn-size includes all the non-operand bits of the longest instruction.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: make CGEN a less moving target?

[Doug Evans]

Frank Ch. Eigler writes:
 > dje wrote:
 > > So how about rephrase it as:
 > > This is what the h/w first fetches to decode an insn.
 > 
 > Dunno about that.
 > 
 > > For non-liw architectures this is the size of the smallest instruction.
 > 
 > If by "non-liw" you mean "RISC", then all instructions have the same size
 > and this is trivial.
 > For variable-length instruction sets, things just seem to work best when 
 > base-insn-size includes all the non-operand bits of the longest instruction.

By liw (*1) I mean things like m32r and ia64 (and crusoe! :-).
Each instruction (or "molecule") actually contains one or more
individual instructions (or "atoms") each executed in parallel.

Thus non-liw = the other guys.

examples of liw = m32r, ia64, crusoe,
examples of non-liw = sparc, mips, ia32, m68k, ppc, yadda yadda yadda

For me, for non-liw variable length ISAs, if base-insn-bitsize isn't
the length of the smallest insn (*2) then there's a problem.

(*1) or epic or vliw or ...  Got a prefered term?
I've never put much effort into the pedantically correct use of terms.

(*2) modulo some weird ISA I'm not aware of