cgen/gas: some support for funny-endian instruction sets

cgen/gas: some support for funny-endian instruction sets

[Frank Ch. Eigler]

Hi -

The patch below gives an interpretation to the hitherto-unused
cgen "word-bitsize" CPU parameter.  It is interpreted to mean
the chunking size for endianness conversions when processing
long instructions.  When this parameter is set smaller than
"base-insn-size" or happens to be smaller than the length of an
instruction, then the instruction bytes are chunked into
"word-bitsize" units, and individually endianness-converted.

For example:  word-bitsize=16, base-insn-size=32
insn-word=0x76543210 -EB=>0x76 0x54 0x32 0x10 -EL=>0x54 0x76 0x10 0x32
insn-word=0x3210     -EB=>0x32 0x10           -EL=>0x10 0x32

The support for this is incomplete.  Among the missing:
* simulator support (insn fetch/decode)
* non-INT_INSN_P target support
but it's a first step.

The patch is not intended to affect existing ports; I tested a bunch
of them both with and without opcodes/ regeneration.

In the absence of objections, I plan to commit this shortly.

- FChE


[cgen/ChangeLog]
2001-07-09  Frank Ch. Eigler  <fche@redhat.com>

	* desc-cpu.scm (-gen-mach-table-defns): Emit fourth field: the
	mach->cpu word-bitsize.
	(-gen-cpu-open): In @arch@_cgen_rebuild_tables, process above new
	field toward CGEN_CPU_TABLE->word_bitsize.

[opcodes/ChangeLog]
Index: ChangeLog
2001-07-09  Frank Ch. Eigler  <fche@redhat.com>

	* cgen-dis.in (print_insn): Use cgen_get_insn_value instead of
	bfd_get_bits.
	* cgen-opc.c (cgen_get_insn_value, cgen_put_insn_value): Respect
	non-zero CGEN_CPU_DESC->word_bitsize.

[include/opcodes/ChangeLog]
2001-07-09  Frank Ch. Eigler  <fche@redhat.com>

	* cgen.h (CGEN_MACH): Add word_bitsize field at end.



Index: cgen/desc-cpu.scm
===================================================================
--- cgen/desc-cpu.scm	2001/03/20 18:20:06	1.27
+++ cgen/desc-cpu.scm	2001/07/09 14:39:35
@@ -70,11 +70,12 @@
 		       (string-append "  { "
 				      "\"" (obj:name mach) "\", "
 				      "\"" (mach-bfd-name mach) "\", "
-				      (mach-enum mach)
+				      (mach-enum mach) ", "
+				      (number->string (cpu-word-bitsize (mach-cpu mach)))
 				      " },\n")))
 		    (current-mach-list))
    "\
-  { 0, 0, 0 }
+  { 0, 0, 0, 0 }
 };
 \n"
    )
@@ -635,11 +636,9 @@
 @arch@_cgen_rebuild_tables (cd)
      CGEN_CPU_TABLE *cd;
 {
-  int i,n_isas;
+  int i;
   unsigned int isas = cd->isas;
-#if 0
   unsigned int machs = cd->machs;
-#endif
 
   cd->int_insn_p = CGEN_INT_INSN_P;
 
@@ -677,20 +676,26 @@
 	  cd->min_insn_bitsize = isa->min_insn_bitsize;
 	if (isa->max_insn_bitsize > cd->max_insn_bitsize)
 	  cd->max_insn_bitsize = isa->max_insn_bitsize;
-
-	++n_isas;
       }
 
-#if 0 /* Does nothing?? */
   /* Data derived from the mach spec.  */
   for (i = 0; i < MAX_MACHS; ++i)
     if (((1 << i) & machs) != 0)
       {
 	const CGEN_MACH *mach = & @arch@_cgen_mach_table[i];
+
+	if (mach->word_bitsize != 0)
+	{
+	  if (cd->word_bitsize != 0 && cd->word_bitsize != mach->word_bitsize)
+	    {
+	      fprintf (stderr, \"@arch@_cgen_rebuild_tables: conflicting word-bitsize values: `%d' vs. `%d'\\n\",
+		       cd->word_bitsize, mach->word_bitsize);
+	      abort ();
+	    }
 
-	++n_machs;
+ 	  cd->word_bitsize = mach->word_bitsize;
+	}
       }
-#endif
 
   /* Determine which hw elements are used by MACH.  */
   build_hw_table (cd);



Index: cgen-dis.in
===================================================================
RCS file: /cvs/cvsfiles/devo/opcodes/cgen-dis.in,v
retrieving revision 1.37
diff -u -2 -0 -r1.37 cgen-dis.in
--- cgen-dis.in	2001/05/15 18:08:19	1.37
+++ cgen-dis.in	2001/07/09 14:42:39
@@ -212,46 +212,46 @@
   ex_info->insn_bytes = buf;
 
   *insn_value = bfd_get_bits (buf, buflen * 8, info->endian == BFD_ENDIAN_BIG);
   return 0;
 }
 
 /* Utility to print an insn.
    BUF is the base part of the insn, target byte order, BUFLEN bytes long.
    The result is the size of the insn in bytes or zero for an unknown insn
    or -1 if an error occurs fetching data (memory_error_func will have
    been called).  */
 
 static int
 print_insn (cd, pc, info, buf, buflen)
      CGEN_CPU_DESC cd;
      bfd_vma pc;
      disassemble_info *info;
      char *buf;
      int buflen;
 {
-  unsigned long insn_value;
+  CGEN_INSN_INT insn_value;
   const CGEN_INSN_LIST *insn_list;
   CGEN_EXTRACT_INFO ex_info;
 
   /* Extract base part of instruction, just in case CGEN_DIS_* uses it. */
-  insn_value = bfd_get_bits (buf, buflen * 8, info->endian == BFD_ENDIAN_BIG);
+  insn_value = cgen_get_insn_value (cd, buf, buflen * 8);
 
   /* Fill in ex_info fields like read_insn would.  Don't actually call
      read_insn, since the incoming buffer is already read (and possibly
      modified a la m32r).  */
   ex_info.valid = (1 << buflen) - 1;
   ex_info.dis_info = info;
   ex_info.insn_bytes = buf;
 
   /* The instructions are stored in hash lists.
      Pick the first one and keep trying until we find the right one.  */
 
   insn_list = CGEN_DIS_LOOKUP_INSN (cd, buf, insn_value);
   while (insn_list != NULL)
     {
       const CGEN_INSN *insn = insn_list->insn;
       CGEN_FIELDS fields;
       int length;
       unsigned long insn_value_cropped;
 
 #ifdef CGEN_VALIDATE_INSN_SUPPORTED 
Index: cgen-opc.c
===================================================================
RCS file: /cvs/cvsfiles/devo/opcodes/cgen-opc.c,v
retrieving revision 1.29
diff -u -2 -0 -r1.29 cgen-opc.c
--- cgen-opc.c	2001/06/29 00:10:04	1.29
+++ cgen-opc.c	2001/07/09 14:42:39
@@ -374,54 +374,105 @@
 cgen_macro_insn_count (cd)
      CGEN_CPU_DESC cd;
 {
   int count = cd->macro_insn_table.num_init_entries;
   CGEN_INSN_LIST *rt_insns = cd->macro_insn_table.new_entries;
 
   for ( ; rt_insns != NULL; rt_insns = rt_insns->next)
     ++count;
 
   return count;
 }
 
 /* Cover function to read and properly byteswap an insn value.  */
 
 CGEN_INSN_INT
 cgen_get_insn_value (cd, buf, length)
      CGEN_CPU_DESC cd;
      unsigned char *buf;
      int length;
 {
-  return bfd_get_bits (buf, length, cd->insn_endian == CGEN_ENDIAN_BIG);
+  int big_p = (cd->insn_endian == CGEN_ENDIAN_BIG);
+  int word_bitsize = cd->word_bitsize;
+  CGEN_INSN_INT value = 0;
+
+  if (word_bitsize != 0 && word_bitsize < length)
+    {
+      /* We need to divide up the incoming value into word_bitsize-length
+	 segments, and endian-convert them, one at a time. */
+      int i;
+
+      /* Enforce divisibility. */ 
+      if ((length % word_bitsize) != 0)
+	abort ();
+
+      for (i = 0; i < length; i += word_bitsize) /* NB: i == bits */
+	{
+	  int index;
+	  bfd_vma this_value;
+	  index = i; /* NB: not dependent on endianness; opposite of cgen_put_insn_value! */
+	  this_value = bfd_get_bits (& buf[index / 8], word_bitsize, big_p);
+	  value = (value << word_bitsize) | this_value;
+	}
+    }
+  else
+    {
+      value = bfd_get_bits (buf, length, cd->insn_endian == CGEN_ENDIAN_BIG);
+    }
+
+  return value;
 }
 
 /* Cover function to store an insn value properly byteswapped.  */
 
 void
 cgen_put_insn_value (cd, buf, length, value)
      CGEN_CPU_DESC cd;
      unsigned char *buf;
      int length;
      CGEN_INSN_INT value;
 {
-  bfd_put_bits ((bfd_vma) value, buf, length,
-		cd->insn_endian == CGEN_ENDIAN_BIG);
+  int big_p = (cd->insn_endian == CGEN_ENDIAN_BIG);
+  int word_bitsize = cd->word_bitsize;
+
+  if (word_bitsize != 0 && word_bitsize < length)
+    {
+      /* We need to divide up the incoming value into word_bitsize-length
+	 segments, and endian-convert them, one at a time. */
+      int i;
+
+      /* Enforce divisibility. */ 
+      if ((length % word_bitsize) != 0)
+	abort ();
+
+      for (i = 0; i < length; i += word_bitsize) /* NB: i == bits */
+	{
+	  int index;
+	  index = (length - word_bitsize - i); /* NB: not dependent on endianness! */
+	  bfd_put_bits ((bfd_vma) value, & buf[index / 8], word_bitsize, big_p);
+	  value >>= word_bitsize;
+	}
+    }
+  else
+    {
+      bfd_put_bits ((bfd_vma) value, buf, length, big_p);
+    }
 }
 \f
 /* Look up instruction INSN_*_VALUE and extract its fields.
    INSN_INT_VALUE is used if CGEN_INT_INSN_P.
    Otherwise INSN_BYTES_VALUE is used.
    INSN, if non-null, is the insn table entry.
    Otherwise INSN_*_VALUE is examined to compute it.
    LENGTH is the bit length of INSN_*_VALUE if known, otherwise 0.
    0 is only valid if `insn == NULL && ! CGEN_INT_INSN_P'.
    If INSN != NULL, LENGTH must be valid.
    ALIAS_P is non-zero if alias insns are to be included in the search.
 
    The result is a pointer to the insn table entry, or NULL if the instruction
    wasn't recognized.  */
 
 /* ??? Will need to be revisited for VLIW architectures.  */
 
 const CGEN_INSN *
 cgen_lookup_insn (cd, insn, insn_int_value, insn_bytes_value, length, fields,
 		  alias_p)




Index: cgen.h
===================================================================
RCS file: /cvs/cvsfiles/devo/include/opcode/cgen.h,v
retrieving revision 1.59
diff -u -5 -r1.59 cgen.h
--- cgen.h	2001/06/16 15:22:00	1.59
+++ cgen.h	2001/07/09 14:42:53
@@ -197,10 +197,12 @@
   const char *name;
   /* The argument to bfd_arch_info->scan.  */
   const char *bfd_name;
   /* one of enum mach_attr */
   int num;
+  /* parameter from mach->cpu */
+  unsigned int word_bitsize;
 } CGEN_MACH;
 \f
 /* Parse result (also extraction result).
 
    The result of parsing an insn is stored here.

cgen/gas: some support for funny-endian instruction sets

[Doug Evans]

Frank Ch. Eigler writes:
 > The patch below gives an interpretation to the hitherto-unused
 > cgen "word-bitsize" CPU parameter.  It is interpreted to mean
 > the chunking size for endianness conversions when processing
 > long instructions.

This isn't the definition of "word-bitsize" that a gcc hacker
would expect.  I think a lot of other people would also find this confusing.

What's "word-bitsize" on sparc64?  If it's not 64, you've got problems.

Setting aside the naming problem,

 > When this parameter is set smaller than
 > "base-insn-size" or happens to be smaller than the length of an
 > instruction, then the instruction bytes are chunked into
 > "word-bitsize" units, and individually endianness-converted.

As I'm sure you know, you can't uniformly chunk up an insn
in the general case.

What problem are you trying to solve?

Re: cgen/gas: some support for funny-endian instruction sets

[Frank Ch. Eigler]

Hi -

On Mon, Jul 09, 2001 at 09:12:04AM -0700, Doug Evans wrote:
: [...]
: This isn't the definition of "word-bitsize" that a gcc hacker
: would expect.  I think a lot of other people would also find this confusing.
: What's "word-bitsize" on sparc64?  If it's not 64, you've got problems.

The gcc meaning might be relevant, if only the word-bitsize parameter
was actually used for something in cgen in a similar way than it might
be in gcc.  Yes, a differently named parameter would be nice, but so
would elimination of unused parameters.


: [...]
: As I'm sure you know, you can't uniformly chunk up an insn
: in the general case.

Yes, the idea is to extend support to a larger class of processors.


: What problem are you trying to solve?

Specifically the example I posted: a bi-endian processor with a narrow
data bus that imposes the basic endianness, and multi-word instructions.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Sd5OVZbdDOm/ZT0RAq3IAJ9jParVNs5HAea0czRfyfJWKlV7owCeJcfV
NtI859lfbNJwlBXJFbv602o=
=3gxW
-----END PGP SIGNATURE-----

cgen/gas: some support for funny-endian instruction sets

[Doug Evans]

Frank Ch. Eigler writes:
 > The patch below gives an interpretation to the hitherto-unused
 > cgen "word-bitsize" CPU parameter.  It is interpreted to mean
 > the chunking size for endianness conversions when processing
 > long instructions.  When this parameter is set smaller than
 > "base-insn-size" or happens to be smaller than the length of an
 > instruction, then the instruction bytes are chunked into
 > "word-bitsize" units, and individually endianness-converted.
 > 
 > For example:  word-bitsize=16, base-insn-size=32
 > insn-word=0x76543210 -EB=>0x76 0x54 0x32 0x10 -EL=>0x54 0x76 0x10 0x32
 > insn-word=0x3210     -EB=>0x32 0x10           -EL=>0x10 0x32
 > 
 > The support for this is incomplete.  Among the missing:
 > * simulator support (insn fetch/decode)
 > * non-INT_INSN_P target support
 > but it's a first step.
 > 
 > The patch is not intended to affect existing ports; I tested a bunch
 > of them both with and without opcodes/ regeneration.
 > 
 > In the absence of objections, I plan to commit this shortly.

Some more thoughts ...

In the beginning I played with whether or not to explicitly
specify instruction formats.  Once you know an instruction's format,
you know how to chunk up its elements.
I think the jury is still out but cgen has gotten by without
explicitly specifying them this far.  In the beginning an architecture
may have a few simple formats, but it often doesn't stay that way.
And when writing .cpu files having to match an instruction with its
format is cumbersome (aka error prone).  Thus they're currently
machine generated.

So some questions:
Setting aside the issue of how instruction formats
are specified, if you had access to the instruction's format,
would that assist in solving your problem?  Do you think a
more appropriate solution would be found by going down this path?

Re: cgen/gas: some support for funny-endian instruction sets

[Doug Evans]

Frank Ch. Eigler writes:
 > On Mon, Jul 09, 2001 at 09:12:04AM -0700, Doug Evans wrote:
 > : [...]
 > : This isn't the definition of "word-bitsize" that a gcc hacker
 > : would expect.  I think a lot of other people would also find this confusing.
 > : What's "word-bitsize" on sparc64?  If it's not 64, you've got problems.
 > 
 > The gcc meaning might be relevant, if only the word-bitsize parameter
 > was actually used for something in cgen in a similar way than it might
 > be in gcc.  Yes, a differently named parameter would be nice, but so
 > would elimination of unused parameters.

There's a tug-of-war between not specifying things that aren't used
and providing basic support and/or guidance to future uses of cgen.
Just because some attribute of an architecture isn't used by current
applications of cgen is _not_ a priori reason enough to not specify it.
In this case I think the presence of word-bitsize is useful.

Re: cgen/gas: some support for funny-endian instruction sets

[Frank Ch. Eigler]

dje wrote:

:  > The gcc meaning might be relevant, if only the word-bitsize parameter
:  > was actually used for something in cgen in a similar way than it might
:  > be in gcc.  Yes, a differently named parameter would be nice, but so
:  > would elimination of unused parameters.
: 
: There's a tug-of-war between not specifying things that aren't used
: and providing basic support and/or guidance to future uses of cgen.

That's true, though I wish guidance was less cast in code and more in
documentation or comments.  (I also wish I would take this
consideration into account with my own code more consistently :-)

: Just because some attribute of an architecture isn't used by current
: applications of cgen is _not_ a priori reason enough to not specify it.
: In this case I think the presence of word-bitsize is useful.

I quite disagree: to *specify*?  If parameters are not used (and there
are a bunch), IMO it is harmful to specify them.  They are untestable
decorations.  They lead to blind copying from port to port, there
being WIP documentation, no useful definition, no apparent harm
... until cgen starts supporting it.  Then, instead of a
cgen-generation-time error ("missing parameter"), one gets a silently
buggy toolchain.


: Some more thoughts ...
: 
: In the beginning I played with whether or not to explicitly specify
: instruction formats.  Once you know an instruction's format, you
: know how to chunk up its elements.

Well, that's only true if it's circular: if the insn format
representation accounts for chunking, then yes, it does.  It doesn't
have to.  Several insn format lists I have seen in processor
documentation don't cover this, treating endianness/chunking as a
separate matter elsewhere (since it's an aspect of the processor's
physical data bus).


: I think the jury is still out but cgen has gotten by without
: explicitly specifying them this far.  [...]

Well, more challenging targets have only started arriving in the
last year or so. :-)


: [...]  Do you think a more appropriate solution would be found by
: [providing concrete insn format abstractions]?

Certainly, but there are so many fish to fry.


- FChE

Re: cgen/gas: some support for funny-endian instruction sets

[Doug Evans]

Frank Ch. Eigler writes:
 > If parameters are not used (and there
 > are a bunch), IMO it is harmful to specify them.  They are untestable
 > decorations.  They lead to blind copying from port to port, there
 > being WIP documentation, no useful definition, no apparent harm
 > ... until cgen starts supporting it.  Then, instead of a
 > cgen-generation-time error ("missing parameter"), one gets a silently
 > buggy toolchain.

One recognizes this going in.  But in the context of word-bitsize
I can't quite get that anal over it.  In the context of something more
complex I'd tend to agree.

 > : Some more thoughts ...
 > : 
 > : In the beginning I played with whether or not to explicitly specify
 > : instruction formats.  Once you know an instruction's format, you
 > : know how to chunk up its elements.
 > 
 > Well, that's only true if it's circular: if the insn format
 > representation accounts for chunking, then yes, it does.  It doesn't
 > have to.  Several insn format lists I have seen in processor
 > documentation don't cover this, treating endianness/chunking as a
 > separate matter elsewhere (since it's an aspect of the processor's
 > physical data bus).

Ah.  Then I don't have a problem with the patch _providing_
word[-_]bitsize is renamed (say insn[-_]word[-_]bitsize).

 > For example:  word-bitsize=16, base-insn-size=32
 > insn-word=0x76543210 -EB=>0x76 0x54 0x32 0x10 -EL=>0x54 0x76 0x10 0x32
 > insn-word=0x3210     -EB=>0x32 0x10           -EL=>0x10 0x32

Why isn't base-insn-size 16?

Re: cgen/gas: some support for funny-endian instruction sets

[Frank Ch. Eigler]

Hi -

On Mon, Jul 09, 2001 at 03:53:08PM -0700, Doug Evans wrote:
: [...]  Then I don't have a problem with the patch _providing_
: word[-_]bitsize is renamed (say insn[-_]word[-_]bitsize).

Okay, I'll see if that's easy.


:  > For example:  word-bitsize=16, base-insn-size=32
:  > insn-word=0x76543210 -EB=>0x76 0x54 0x32 0x10 -EL=>0x54 0x76 0x10 0x32
:  > insn-word=0x3210     -EB=>0x32 0x10           -EL=>0x10 0x32
: 
: Why isn't base-insn-size 16?

It's because the bytes past the initial two can contain
decodable, fixed bits which disambiguate among longer
instructions (not just operands).  I've been making
changes to cgen & opcodes over the last few months to
support this case.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7SjcnVZbdDOm/ZT0RAqkUAJ90zpYZTflyU1vyFvG6yoW+2NsRIwCfeNcH
weNZ/HpumRvF42AtcNqM98s=
=GsJf
-----END PGP SIGNATURE-----