This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Calling convention that gets frame pointer register clobbered


 --- Jim Wilson wrote: 
> On Mon, 2003-12-22 at 01:54, Etienne Lorrain wrote:
> >   The code is compiling if the structure is small enough to fit in
> >  a 32 bits register, not if it has to be in memory - I should have
> >  said it.
> > tmp.c:12: internal compiler error: in emit_move_insn, at expr.c:3159
> 
> The structure has a size larger than its alignment, so it is given
> BLKmode.  We can't copy BLKmode objects into registers, which gives the
> abort.

  I am not sure, but I think that GCC manage BLKmode objects in registers
 by having their _address_ in register.
 Just for my curiosity, a question you may know how to answer: When a
 function returns a structure (bigger than 32 bits) - does it return
 a BLKmode object?

> Using "=S" (*ebiosinfo) means load the entire structure into the S reg. 
> We can't fit a large structure into a 32-bit register, so what you are
> trying to do can not be made to work.

 I have re-written the code the way I have understood GCC likes it,
 I did not read GCC source code itself here. The structure is simplified,
 but just compare (with my previous message) how (*ebiosinfo) is
 passed to the asm().

--------------------------------------
typedef struct {
    unsigned short      buffersize;
    unsigned short      infobit;
    unsigned            nbcylinder;
    unsigned            nbhead;
    unsigned            nbsectorpertrack;
    unsigned long long  nbtotalsector;
    unsigned short      bytepersector;
    unsigned short signature0xBEDD;
    unsigned char  lendevicepath;
    unsigned char  reserved[3];
    unsigned char  bustype[4];
    unsigned char  Interface[8];
    union interface_path_u {
        struct {
            unsigned short addr;
            unsigned char pad[6];
            } __attribute__ ((packed)) isa;
        } bus;
    union device_path_u {
        struct {
            unsigned char slave;
            unsigned char pad[7];
            unsigned long long  reserved;
          } __attribute__ ((packed)) ata;
      } device;
    unsigned char zero;
    unsigned char bytechecksum;
    } __attribute__ ((packed)) ebiosinfo_t;

unsigned char
_EBIOSDISK_getparam (unsigned char disk, ebiosinfo_t *ebiosinfo,
                     unsigned char *status)
  {
  unsigned char carry;

  asm (
"       lea     %2,%%esi                                \n"
"       int     $0x13           # _EBIOSDISK_getparam   \n"
"       mov     %%ah,%1                                 \n"
"       setc    %0                                      \n"
        : "=qm" (carry), "=qm" (*status), "=g" (*ebiosinfo)
        : "a"((unsigned short)0x4800), "d" (disk)
        : "esi"
        );

  return carry;
  }
--------------------------------------

  This code does compile without warning - I still did not test
 the executable. It is not really clean to say "=g" and then
 do a lea (load effective address) into %esi but should work.

> You are trying to explain for alias analysis purposes that a structure
> is written by the asm.

  Yes.

> We don't have any explicit way to represent that other than by
> using "=m" (*ebiosinfo).

  "=g" also works, which could randomly select %esi register to pass
 the parameter...
 I think that "=m" would not cover a variable in the current stack
 frame - just a variable in memory - from some debugging I did
 quite long ago. The variables/structures in the current stack
 frame can be optimised further (even removed if not used).

> The asm syntax could perhaps be extended to do what you want.

  It is maybe already complex enought...

  Cheers,
  Etienne.


_________________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]