Endianness and CGEN_INT_INSN_P

Endianness and CGEN_INT_INSN_P

[Richard Sandiford]

When CGEN_INT_INSN_P is true, the instruction gets written as a single
integer with the bytes arranged according to the target endianness.  This
only seems appropriate when every instruction is one word long.  Is this
right?  If so, would it be better to restrict CGEN_INT_INSN_P to that
case, or would it better to handle the multi-word case when
CGEN_INT_INSN_P is true?

Richard

Re: Endianness and CGEN_INT_INSN_P

[Dave Brolley]

 From what I understand, CGEN_INT_INSN_P will not be true if there is at 
least one insn which will not fit into the word.

Dave

Richard Sandiford wrote:

> When CGEN_INT_INSN_P is true, the instruction gets written as a single
> integer with the bytes arranged according to the target endianness.  This
> only seems appropriate when every instruction is one word long.  Is this
> right?  If so, would it be better to restrict CGEN_INT_INSN_P to that
> case, or would it better to handle the multi-word case when
> CGEN_INT_INSN_P is true?
> 
> Richard
> 
> 
> 
> 
> 

Re: Endianness and CGEN_INT_INSN_P

[Doug Evans]

Dave Brolley writes:
 >  From what I understand, CGEN_INT_INSN_P will not be true if there is at 
 > least one insn which will not fit into the word.

But suppose a word is 32 bits, the "base insn size" is 8 bits,
and the maximum insn size is 24 bits ...
How do you lay out an insn that, say, takes a 16 bit immediate?
If we call the insn bytes op, hi, lo (having the obvious meanings),
then big endian it could (though not necessarily - gotta watch out
for those pedants) be op,hi,lo; and for little endian it could be
op,lo,hi.

The supposition is (I'm guessing) that the code can't handle this if
CGEN_INT_INSN_P is true.

I suspect one could get that to work.  There should be enough info
in the description file to get it to work.  Whether one makes the
effort to get it to work (if it already doesn't) I don't have a strong
opinion on, modulo the result not being excessively complicated.

 > Richard Sandiford wrote:
 > 
 > > When CGEN_INT_INSN_P is true, the instruction gets written as a single
 > > integer with the bytes arranged according to the target endianness.  This
 > > only seems appropriate when every instruction is one word long.  Is this
 > > right?  If so, would it be better to restrict CGEN_INT_INSN_P to that
 > > case, or would it better to handle the multi-word case when
 > > CGEN_INT_INSN_P is true?

I'm guessing that when you said "multi-word" here you actually meant
a case like the above example, right?

Re: Endianness and CGEN_INT_INSN_P

[Richard Sandiford]

On Tue, 2 Jan 2001, Dave Brolley wrote:

>  From what I understand, CGEN_INT_INSN_P will not be true if there is at 
> least one insn which will not fit into the word.

Do you mean host or target word?  As it stands, the macro gets set to 1
whenever the longest instruction is 32 bits or less, i.e. whenever it can
fit into an int.  But the code that handles instructions as integers
seems to assume that every instruction can fit into one *target* word.
It builds the instruction as an int without considering endianness, then
it stores that integer in either big or little endian form, depending
on the target.  But, in a 16-bit arch, the two-word insn "AABB
CCDD" gets stored as "BB AA DD CC" when the macro is false and "DD CC BB 
AA" when it is true.

Richard

Re: Endianness and CGEN_INT_INSN_P

[Frank Ch. Eigler]

Hi -

On Tue, Jan 02, 2001 at 01:48:37PM +0000, Richard Sandiford wrote:
: When CGEN_INT_INSN_P is true, the instruction gets written as a single
: integer with the bytes arranged according to the target endianness.  This
: only seems appropriate when every instruction is one word long.  

The code checks for all instructions being at most one word (32 bits)
long, not exactly one word long.

I must admit that I would prefer to see a single general mechanism
(byte strings) as opposed to that PLUS a reasonable but tricky
optimization.  Doug, do you have any sense of how much processing
time the INT_INSN_P flag saves when present?


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

iD8DBQE6UgZ0VZbdDOm/ZT0RAvRIAJ9J9hv+EnaUZScnXmVfc2GBnbvPpQCbBGCe
rAT/dyavD0kGFVZXJP7uupo=
=L/4H
-----END PGP SIGNATURE-----

Re: Endianness and CGEN_INT_INSN_P

[Doug Evans]

Frank Ch. Eigler writes:
 > On Tue, Jan 02, 2001 at 01:48:37PM +0000, Richard Sandiford wrote:
 > : When CGEN_INT_INSN_P is true, the instruction gets written as a single
 > : integer with the bytes arranged according to the target endianness.  This
 > : only seems appropriate when every instruction is one word long.  
 > 
 > The code checks for all instructions being at most one word (32 bits)
 > long, not exactly one word long.
 > 
 > I must admit that I would prefer to see a single general mechanism
 > (byte strings) as opposed to that PLUS a reasonable but tricky
 > optimization.  Doug, do you have any sense of how much processing
 > time the INT_INSN_P flag saves when present?

The intent was in part to save processing time, but not of GAS per se.
Remember that this discussion can't be based on the premise
that we're only talking about GAS (at least that is how I'm
proceeding ...)

When I did INT_INSN_P I was thinking of the various RISC chips
that all have 32 bit insns, and I wanted cgen to be used in _all_ the
various apps where people were encoding and decoding insns
(not that that is the only intended use of cgen of course).
While I wasn't trying to make cgen a drop-in replacement,
I wanted to preserve the int-ness of the representation to not
close any doors.

One could present the case that such apps are separate apps and that
INT_INSN_P is a GAS only thing I suppose.  While one can continually
write source generators, I wanted libcgen to obviate the need to
always have to do that.

refresher: libcgen is a (still mythical) generalized and spiffed up libopcodes

Re: Endianness and CGEN_INT_INSN_P

[Frank Ch. Eigler]

Hi -

dje wrote:
:  [...]
:  > I must admit that I would prefer to see a single general mechanism
:  > (byte strings) as opposed to that PLUS a reasonable but tricky
:  > optimization.  Doug, do you have any sense of how much processing
:  > time the INT_INSN_P flag saves when present?
: 
: The intent was in part to save processing time, but not of GAS per se.

That's true -- the simulators also like to pass instruction words around.

: [...]
: When I did INT_INSN_P I was thinking of the various RISC chips
: that all have 32 bit insns, and I wanted cgen to be used in _all_ the
: various apps where people were encoding and decoding insns
: (not that that is the only intended use of cgen of course).

But none of these (future / mythical?) applications would be precluded
if byte-strings were the canonical representation, and the apps were to
use to/from-int32 conversions.

I'm arguing more from a software engineering perspective.  By having
the INT_INSN_P option, two forks of target support runtimes must be
kept functional with changes such as variable-length instructions.
Where the option is not a clear & convincing optimization that 
justifies the burden of dual maintenance, it should be deprecated.


: [...]
: refresher: libcgen is a (still mythical) generalized and spiffed up
: libopcodes

To me, an important requirement would be to support multiple targets
concurrently.  The fewer compile-time target-dependent macros (INT_INSN_P)
the better. :-)


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

iD8DBQE6UlGyVZbdDOm/ZT0RAnNqAJ9jTwFiEVUTKZPNeNh0ACafsU4o1gCdE92D
1Zn68BNG1If6oahSXPJCneY=
=hlg1
-----END PGP SIGNATURE-----