public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Ian Dall <dall@hfrd.dsto.gov.au>
To: raeburn@cygnus.com
Cc: gas2@cygnus.com
Subject: How best to put machine dependant bits in frags and fixes?
Date: Sun, 27 Aug 1995 20:48:00 -0000	[thread overview]
Message-ID: <199508280347.NAA00388@hfrd015.dsto.gov.au> (raw)
In-Reply-To: <199508220148.VAA28233@kr-laptop.cygnus.com>

I have working a new scheme where the ns32k backend uses fr_machdep to
attach a note, instead of having multiple machine dependant fields in
the frag structure. I removed the fr_pcrel_adjust and fr_bsr fields
which are only used by the ns32k port. The new ns32k scheme keeps a
pointer to the frag containing the relavant opcode and an offset in
that frag. From this, it is possible to calculate the address of the
opcode and hence the difference between the address of the opcode and
the address of the displacement field (which is the correct amount to
adjust the pcrel amount by). This works even though frags may grow or
shrink or change fr_address during the relax phase.

A similar thing needs to be done for fixes. I attached a note to the
tc_fix_data field in the fix structure which contains a pointer to the
opcode frag and the offset in that frag. I also have tried folding
various machine dependent fields in the fix structure into the
tc_fix_data. I grepped around to find out where these fields are used
and note that the comments against these fields weren't always correct.

Anyway, one certainly can do the folding, but it isn't a clear win.

The relevant fields seems to be:

fx_pcrel_adjust is used by i860, i960, m68k. (No longer used by the
ns32k).

fx_im_disp is used by i860, i960 and ns32k. i860 asserts it is always
zero, i960 and ns32k sometimes put 2 in here which wont fit in 1
bit. This was one bit unless building for TC_NS32K in which case it
was 2 bits.  However, it should be two bits or else not needed at
all.

fx_bsr  used by i960, ns32k (sequent only).

fx_tcbit ?

fx_bit_fixP i860, i960-coff and ns32k use this. i960-coff stores an
integer.  This could be folded into tc_fix_data, except there is
machine independent code in write.c which refers to it.

It is a pity the fx_bit_fixP is referenced in write.c. I guess one
could use some new TC_... macro to do return the required info, but if
it is just TC_BITFIXP, then this doesn't seem like a win in terms of
decluttering the machine independent code.

Folding the small fields into tc_fix_data doesn't save any space on
most machines because of the alignment restrictions. Also there is
some penalty in accessing them (an extra dereference plus typically
code to test for the case of tc_fix_data == 0.

One goal is to not waste space for fields a particular machine does not
need. Another goal would be to eliminate machine dependent code
in the machine independant parts. Finally, one could want to select
the target machine at run time. I don't see the last goal as being very
relevant (multiple simultaneous target support is a long way off if
ever).

The first two goals could be supported by having (optional) target
dependent macros to do the *declaration* and initialization of the
target dependent fix fields. The macros might be called
TC_FIX_DECL_SMALL (for target dependent bitfields), TC_FIX_DECL (for
other fields), and TC_FIX_INIT which would be called whenever a new
fix is created, just after the machine independant initialization. The
only bad thing about this is that having a macro containing just
declarations of fields within a structure is a bit unusual and might
trip up programmers.

For example, the fix struct would become:

    struct fix
    {
      unsigned fx_pcrel : 1;
      unsigned fx_plt : 1;

      unsigned fx_done : 1;

    #ifdef TC_FIX_DECL_SMALL
      TC_FIX_DECL_SMALL;
    #else
    #ifdef TC_NS32K
      unsigned fx_im_disp : 2;
    #else
      unsigned fx_im_disp : 1;
    #endif
      unsigned fx_bsr : 1;

      unsigned fx_tcbit : 1;

      char fx_pcrel_adjust;
    #endif /* TC_FIX_DECL_SMALL */

      unsigned fx_no_overflow : 1;

      short int fx_size;

      fragS *fx_frag;

      long fx_where;

      symbolS *fx_addsy;

      symbolS *fx_subsy;

      valueT fx_offset;

      struct fix *fx_next;

      bit_fixS *fx_bit_fixP;

    #ifdef BFD_ASSEMBLER
      bfd_reloc_code_real_type fx_r_type;
    #else
    #ifdef NEED_FX_R_TYPE
      int fx_r_type;
    #endif
    #endif

      valueT fx_addnumber;

      char *fx_file;
      unsigned fx_line;

    #ifdef TC_FIX_DECL
      TC_FIX_DECL;
    #else
      PTR tc_fix_data;
    #endif /* TC_FIX_DECL */
    };



I'd be happy to make the changes to write.h, write.c and the ns32k backend
if you think it is on the right track.

Ian











           reply	other threads:[~1995-08-27 20:48 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <199508220148.VAA28233@kr-laptop.cygnus.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199508280347.NAA00388@hfrd015.dsto.gov.au \
    --to=dall@hfrd.dsto.gov.au \
    --cc=gas2@cygnus.com \
    --cc=raeburn@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).