Some CGEN problems

Some CGEN problems

[Kai Henningsen]

I'm playing with CGEN for a virtual cpu.

Maybe the largest problem (after the rather sparse documentation) is
that the pmacro system seems to be much weaker than GCC's iterator
system.

I've yet to figure out a way to iterate over two variables (such as
"integer opcodes" and "modes for integer opcodes"), or a way to handle
what GCC does with iterator attributes (such as the mapping from RTL
operands to opcode names). Right now, the best way I can think of is
to generate CGEN input with a Perl script ... but surely the whole
point of CGEN is that I shouldn't need that?!

This (and the growing list of stuff that I find that CGEN doesn't even
try to handle) makes me wonder if it might be easier to not use CGEN.
Of course, binutils documentation isn't any better. I thought GCC
documentation was sparse, but compared with these two, it's positively
encyclopedic!

Re: Some CGEN problems

[Frank Ch. Eigler]

"Kai Henningsen" <kai.extern@googlemail.com> writes:

> Maybe the largest problem (after the rather sparse documentation) is
> that the pmacro system seems to be much weaker than GCC's iterator
> system.  [...] Right now, the best way I can think of is to generate
> CGEN input with a Perl script ... [...]

I agree, that is probably best.

> This (and the growing list of stuff that I find that CGEN doesn't
> even try to handle) makes me wonder if it might be easier to not use
> CGEN. [...]

Only you can judge that.  There is little cgen-oriented development
going on now, so any new features you need will need more
encouragement & assistance to make happen than a Marvinoid moan.

- FChE

Re: Some CGEN problems

[Kai Henningsen]

On Mon, Apr 21, 2008 at 5:51 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> "Kai Henningsen" <kai.extern@googlemail.com> writes:
>
>  > Maybe the largest problem (after the rather sparse documentation) is
>  > that the pmacro system seems to be much weaker than GCC's iterator
>  > system.  [...] Right now, the best way I can think of is to generate
>  > CGEN input with a Perl script ... [...]
>
>  I agree, that is probably best.
>
>
>  > This (and the growing list of stuff that I find that CGEN doesn't
>  > even try to handle) makes me wonder if it might be easier to not use
>  > CGEN. [...]
>
>  Only you can judge that.  There is little cgen-oriented development
>  going on now, so any new features you need will need more
>  encouragement & assistance to make happen than a Marvinoid moan.

So don't moan then.

Or in other words, rereading my mail I can't see anything even
remotely resembling a moan. What it mainly is is wondering what I
might have missed - it's hard to believe these particular problems
weren't apparent pretty much from the start, and thus it's hard to
believe nobody tried to solve them a long time ago.

And I'd like to hear how other people solved these kinds of problems -
or if they did.

Re: Some CGEN problems

[Frank Ch. Eigler]

Hi -

On Mon, Apr 21, 2008 at 09:06:08PM +0200, Kai Henningsen wrote:

> [...]  What it mainly is is wondering what I might have missed -
> it's hard to believe these particular problems weren't apparent
> pretty much from the start, and thus it's hard to believe nobody
> tried to solve them a long time ago. [...]

The architectures for which a cgen model had been built (and some of
them are pretty "far out") must not have needed the logical
completeness you envision.

- FChE

Re: Some CGEN problems

[Jim Blandy]

CGEN was designed for risc-like architectures, with few instruction
sizes.  CISC architectures are difficult to incorporate.

Re: Some CGEN problems

[Kai Henningsen]

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

On Tue, Apr 22, 2008 at 7:18 PM, Jim Blandy <jimb@red-bean.com> wrote:
> CGEN was designed for risc-like architectures, with few instruction
> sizes.  CISC architectures are difficult to incorporate.

I don't think it's that ...

Anyway, I think the following is simple enough that I'll just put it
in the public domain. It allows me to use perl in the .cpu file -
well, in the file that the .cpu file is generated from (or, for that
matter, in any other text file). One needs to escape characters that
are special in perl strings - mainly dollar.

Application looks as follows:

(... normal cgen stuff ...)
! for my $i (@list) {
!    for my $j (@otherlist) {
(... normal cgen stuff, with vatiables $i and $j ...)
!    }
! }
(... normal cgen stuff ...)


and then

domac.pl xxx.cpu.in xxx.cpu

Script attached.

[-- Attachment #2: domac.pl --]
[-- Type: application/x-perl, Size: 791 bytes --]