public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Re: .code16gcc and "lea <32bit>(%eax),%edx"
@ 2000-06-22  7:19 Etienne Lorrain
  0 siblings, 0 replies; 3+ messages in thread
From: Etienne Lorrain @ 2000-06-22  7:19 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

  Hello Alan Modra,

  Thanks _again_ for such quick answers !

  It is working here on my project - I've just tested it,
 I hope to get this patch in 2.10.

  Etienne.


___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: .code16gcc and "lea <32bit>(%eax),%edx"
  2000-06-22  1:44 Etienne Lorrain
@ 2000-06-22  4:01 ` Alan Modra
  0 siblings, 0 replies; 3+ messages in thread
From: Alan Modra @ 2000-06-22  4:01 UTC (permalink / raw)
  To: Etienne Lorrain; +Cc: binutils

On Thu, 22 Jun 2000, [iso-8859-1] Etienne Lorrain wrote:

>    3                    .code16gcc
>    4 0006 67668D78      leal 4194428(%eax),%edi
>    4      7C

I squinted at this code when I made a similar fix for immediates on
2000-04-03, at the time deciding that displacements wouldn't be a problem
because the size is only affected by the mode and prefixes, which we've
already seen.  Forgot that i386_index_check might magically add a prefix
in...

Ah well.  Following patch installed.

-- 
Linuxcare.  Support for the Revolution.

gas/ChangeLog
	* config/tc-i386.c (i386_displacement): Don't assume a constant
	displacement is necessarily 16 bits when in 16 bit code mode.
	(md_assemble): Instead size the displacement here after we know
	for sure that a .code16gcc operand hasn't automatically added
	operand size prefixes.

Index: gas/config/tc-i386.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-i386.c,v
retrieving revision 1.55
diff -u -p -r1.55 tc-i386.c
--- tc-i386.c	2000/06/21 02:18:17	1.55
+++ tc-i386.c	2000/06/22 10:44:38
@@ -1461,6 +1461,31 @@ md_assemble (line)
 	    }
       }
 
+    if (i.disp_operands)
+      {
+	/* Try to use the smallest displacement type too.  */
+	int op;
+
+	for (op = i.operands; --op >= 0; )
+	  if ((i.types[op] & Disp)
+	      && i.op[op].imms->X_op == O_constant)
+	    {
+	      offsetT disp = i.op[op].disps->X_add_number;
+
+	      if (i.types[op] & Disp16)
+		{
+		  /* We know this operand is at most 16 bits, so
+		     convert to a signed 16 bit number before trying
+		     to see whether it will fit in an even smaller
+		     size.  */
+		  
+		  disp = (((disp & 0xffff) ^ 0x8000) - 0x8000);
+		}
+	      if (fits_in_signed_byte (disp))
+		i.types[op] |= Disp8;
+	    }
+      }
+
     overlap0 = 0;
     overlap1 = 0;
     overlap2 = 0;
@@ -2920,28 +2945,15 @@ i386_displacement (disp_start, disp_end)
       exp->X_op_symbol = (symbolS *) 0;
     }
 
-  if (exp->X_op == O_constant)
-    {
-      if (i.types[this_operand] & Disp16)
-	{
-	  /* We know this operand is at most 16 bits, so convert to a
-	     signed 16 bit number before trying to see whether it will
-	     fit in an even smaller size.  */
-	  exp->X_add_number =
-	    (((exp->X_add_number & 0xffff) ^ 0x8000) - 0x8000);
-	}
-      if (fits_in_signed_byte (exp->X_add_number))
-	i.types[this_operand] |= Disp8;
-    }
 #if (defined (OBJ_AOUT) || defined (OBJ_MAYBE_AOUT))
-  else if (
+  if (exp->X_op != O_constant
 #ifdef BFD_ASSEMBLER
-	   OUTPUT_FLAVOR == bfd_target_aout_flavour &&
+      && OUTPUT_FLAVOR == bfd_target_aout_flavour
 #endif
-	   exp_seg != text_section
-	   && exp_seg != data_section
-	   && exp_seg != bss_section
-	   && exp_seg != undefined_section)
+      && exp_seg != text_section
+      && exp_seg != data_section
+      && exp_seg != bss_section
+      && exp_seg != undefined_section)
     {
 #ifdef BFD_ASSEMBLER
       as_bad (_("unimplemented segment %s in operand"), exp_seg->name);

^ permalink raw reply	[flat|nested] 3+ messages in thread

* .code16gcc and "lea <32bit>(%eax),%edx"
@ 2000-06-22  1:44 Etienne Lorrain
  2000-06-22  4:01 ` Alan Modra
  0 siblings, 1 reply; 3+ messages in thread
From: Etienne Lorrain @ 2000-06-22  1:44 UTC (permalink / raw)
  To: binutils

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

  Hello,

[root@localhost gujin]# as -V
GNU assembler version 2.9.5 (i686-pc-linux-gnu) using BFD version 2.9.5.0.33
>>> (same result with 2.10)
[root@localhost gujin]# cat | as -al -
.code32
        leal 4194428(%eax),%edi
.code16gcc
        leal 4194428(%eax),%edi
>>> gives >>>
GAS LISTING                     page 1


   1                    .code32
   2 0000 8DB87C00      leal 4194428(%eax),%edi
   2      4000
   3                    .code16gcc
   4 0006 67668D78      leal 4194428(%eax),%edi
   4      7C
[root@localhost gujin]#

>>>
  I think the hexadecimal for the .code16gcc is too short,
 I would have waited simply (because of the two prefix):
  67 66 / 8D B8 / 7C 00 40 00
          ^^^^^^^^^^^^^^^^^^^ same as .code32

  Have a nice day,
  Etienne.

___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-06-22  7:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-22  7:19 .code16gcc and "lea <32bit>(%eax),%edx" Etienne Lorrain
  -- strict thread matches above, loose matches on Subject: below --
2000-06-22  1:44 Etienne Lorrain
2000-06-22  4:01 ` Alan Modra

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).