What is the state of cgen for architectures like the IA-64?

What is the state of cgen for architectures like the IA-64?

[Michael Meissner]

I'm doing a port for a new machine that has instruction encoding where
instructions are logically of the format:

	+--+----------------------------------------------------+
	|A |B							|
	+--+----------------------------------------------------+

The instructions are then packed into a field of the form:

	+--+------------+---------------+---------------+
	|C |B1		|B2		|B3		|
	+--+------------+---------------+---------------+

where C is an encoding for A1, A2, and A3.  I believe this is similar to the
format used by the IA-64 (but I only have a passing familarily with the IA-64).
I tried building the ia64 opcodes, and it looks like it has bit-rotted (at
least on my x86 Linux Red Hat 9 system, using a 1.4.1 guile instead of the 1.6
guile that is supplied with Red Hat 9):

rm -f tmp-opc.h tmp-itab.c
rm -f tmp-asm.in tmp-dis.in tmp-ibld.h tmp-ibld.in
/home/meissner/install/guile-1.4.1/bin/guile -s /home/meissner/fsf-src/cgen/src/cgen/cgen-opc.scm \
-s /home/meissner/fsf-src/cgen/src/cgen \
-v \
-f " opinst" \
        -m all -a ia64 \
        -O tmp-opc.h -P tmp-opc.c -Q tmp-opinst.c \
        -B tmp-ibld.h -L tmp-ibld.in \
        -A tmp-asm.in -D tmp-dis.in
Skipping slib/sort, already loaded.
Skipping slib/random, already loaded.
cgen -s /home/meissner/fsf-src/cgen/src/cgen/cgen-opc.scm -s /home/meissner/fsf-src/cgen/src/cgen -v -f " opinst" -m all -a ia64 -O tmp-opc.h -P tmp-opc.c -Q tmp-opinst.c -B tmp-ibld.h -L tmp-ibld.in -A tmp-asm.in -D tmp-dis.in 
Setting option `opinst' to "".
Loading cpu description /home/meissner/fsf-src/cgen/src/cgen/cpu/ia64.cpu
Including file simplify.inc ...
ERROR: /home/meissner/fsf-src/cgen/src/cgen/cpu/ia64.cpu:55: unknown entry type:
 (eval (begin (set! INT (mode:add! (quote INT) (mode:lookup (quote DI)))) (set! UINT (mode:add! (quote UINT) (mode:lookup (quote UDI)))) (set! WI (mode:add! (quote WI) (mode:lookup (quote DI)))) (set! UWI (mode:add! (quote UWI) (mode:lookup (quote UDI)))) (set! AI (mode:add! (quote AI) (mode:lookup (quote UDI)))) (set! IAI (mode:add! (quote IAI) (mode:lookup (quote UDI))))))
No backtrace available.
make: *** [opcodes] Error 1

So is cgen currently up to handling such an architecture without significant
hacking?  If the IA-64 is not fleshed out, is there another target in the
public sources that would be more appropriate to look at?

I suspect if I'm going to have to do significant surgery to cgen to get it to
work, it will become less desirable to use it, and faster for me to do the port
the old fashioned way.

--
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org

Re: What is the state of cgen for architectures like the IA-64?

[Frank Ch. Eigler]

Hi, Mike -

> I'm doing a port for a new machine that has instruction encoding where
> instructions are logically of the format:
> 	|A |B							|
> The instructions are then packed into a field of the form:
> 	|C |B1		|B2		|B3		|
> where C is an encoding for A1, A2, and A3.  [...]
> So is cgen currently up to handling such an architecture without significant
> hacking?  [...]

I don't think you'll find much direct support for this.  However,
there are enough C hooks available to insert your own instruction
packing/unpacking routines into the opcodes or simulator.  With such
routines around the cgen-generated kernel, the job is reduced to
modelling only the logical format of the instructions in cgen.


- FChE

What is the state of cgen for architectures like the IA-64?

[Doug Evans]

Michael Meissner writes:
 > I tried building the ia64 opcodes, and it looks like it has bit-rotted

I believe what's there now is a work-in-progress / experiment.

 > So is cgen currently up to handling such an architecture without significant
 > hacking?

Dunno.  I think it'll require some work.
I suspect it's not significant surgery but then again I'll bet it's
far more than a Blue's Clues bandaid.
(parental humor there for those without kids :-)

 > If the IA-64 is not fleshed out, is there another target in the
 > public sources that would be more appropriate to look at?

You might try the m32r port, though its kind of instruction
packing is far simpler.

I have started something in the description language to use to
describe such architectures.  grep for frame in m32r.cpu.
It's not currently used by the m32r port though and the real work
is in using the data (it's not rocket science though).
It came after and I haven't had time to finish it.

 > faster for me to do the port
 > the old fashioned way.

That may well be true.  In the end I believe it'd be less fun though. :-)

And with a cgen description of the port, you open yourself up to
other kinds of things one might want to do.