Re: 16-bit i386 code support in GAS

Re: 16-bit i386 code support in GAS

[H.J. Lu]

> 
> (Sorry if this isn't the right place to ask this question;
> I couldn't find any better address in the GAS documentation...)
> 
> How difficult would it be to add a feature to the i386 version
> of GAS to allow it to generate 16-bit i386 code?  It seems like
> it should be a trivial change - just add a directive that inverts
> the decision of whether or not to add size prefixes to each
> instruction, right?  Such a feature would make it possible to
> avoid the icky old inverted-syntax, non-cross-compiling as86 and
> ld86 programs for writing boot-related code in Mach (Hurd/Lites)
> and Linux.
> 
> So, could someone either add this feature, or point me to the
> right parts of gas-i386 so I can do it myself, or tell me why
> it isn't so simple?
> 

Please take a look at my CC field.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: 16-bit i386 code support in GAS

[Ken Raeburn]

   > (Sorry if this isn't the right place to ask this question;
   > I couldn't find any better address in the GAS documentation...)

Probably bug-gnu-utils is the best publicly advertised place.  The gas2
list at Cygnus is a less advertised one, intended mainly for developers.

   > How difficult would it be to add a feature to the i386 version
   > of GAS to allow it to generate 16-bit i386 code?  It seems like
   > it should be a trivial change - just add a directive that inverts
   > the decision of whether or not to add size prefixes to each
   > instruction, right?  Such a feature would make it possible to
   > avoid the icky old inverted-syntax, non-cross-compiling as86 and
   > ld86 programs for writing boot-related code in Mach (Hurd/Lites)
   > and Linux.
   >
   > So, could someone either add this feature, or point me to the
   > right parts of gas-i386 so I can do it myself, or tell me why
   > it isn't so simple?

No "decision" is being made, at least at run time.  The opcode table has
the prefixes already present for the 16-bit versions of instructions that
need them and absent for the 32-bit versions.  So "addw" would be a
two-byte instruction and "addl" a one-byte instruction.

One way to approach this might be to make the opcode table indicate which
operand size an instruction indicates, independently of the value of the
opcode itself, and add the prefix when a larger-than-byte operand size is
needed and it doesn't match the "current" mode.

Another is to check for 16-bit mode and strip off a size prefix if
present, or add one if the instruction would need one, using some kludge
to figure out whether an instruction's operands are 8- or 32-bit sized.

I'd like to see this work done (but cleanly!), for precisely the reasons
you mention.  Anyone doing kernel or stand-alone program development
currently has to have as86 and ld86 as well as the GNU tools for the
32-bit code.  That's just silly.

For consistent results, you'd probably want the disassembler to work in
16-bit mode too.  Un(?)fortunately, they use separate copies of the opcode
table, laid out in different formats.


I'd also like to have a general overhaul of the i386 back end done.  It's
got lots of other problems, especially some dealing with segment
registers.  I've been thinking about doing some of this work myself, but
if you've got a strong overall understanding of the quirks of the i386
instruction set, and a lot of spare time you want to donate, let me
know...

Re: 16-bit i386 code support in GAS

[Bryan Ford]

>   > (Sorry if this isn't the right place to ask this question;
>   > I couldn't find any better address in the GAS documentation...)
>
>Probably bug-gnu-utils is the best publicly advertised place.  The gas2
>list at Cygnus is a less advertised one, intended mainly for developers.

I've sent messages (including bug _fixes_, not just reports)
to bug-gnu-utils several times before, and have never gotten any
kind of response whatsoever - my mail just disappears into the void. :-)

>[...16 bit support...]
>I'd like to see this work done (but cleanly!), for precisely the reasons
>you mention.  Anyone doing kernel or stand-alone program development
>currently has to have as86 and ld86 as well as the GNU tools for the
>32-bit code.  That's just silly.
>
>I'd also like to have a general overhaul of the i386 back end done.  It's
>got lots of other problems, especially some dealing with segment
>registers.  I've been thinking about doing some of this work myself, but
>if you've got a strong overall understanding of the quirks of the i386
>instruction set, and a lot of spare time you want to donate, let me
>know...

I have a pretty good understanding of the 386 instruction set,
but no experience in the GAS source code, and practically no free time.
I was thinking of adding the 16-bit support myself if it was fairly trivial,
but it sounds as if it isn't.  I still might be able to, but not any time soon...

Thanks...

				Bryan

Re: 16-bit i386 code support in GAS

[Rick Sladkey]

> From: Ken Raeburn <raeburn@cygnus.com>
> Subject: Re: 16-bit i386 code support in GAS
> Date: Wed, 9 Nov 1994 13:49:07 -0500

> For consistent results, you'd probably want the disassembler to work
> in 16-bit mode too.  Un(?)fortunately, they use separate copies of
> the opcode table, laid out in different formats.

Here is i386 16-bit disassembler code which was started by Eric
Youngdale and finished by myself.  We never got around to submitting it.
This code was originally motivated by Wine, the Windows emulator.

These changes are relative to an old version of gdb but they patch
without problems into the latest sources.
-----
Wed Nov  9 22:05:40 1994  Rick Sladkey  <jrs@world.std.com>

	* bfd/archures.c (bfd_architecture docs): add bfd_mach_i286
	and bfd_mach_i386 processors with family.
	* bfd/bfd-in2.h (bfd_architecture): Likewise.

Wed Nov  9 22:05:40 1994  Rick Sladkey  <jrs@world.std.com>

	* opcodes/i386-dis.c (names_rmw): New vector to decode mod/rm
	fields unique to 16-bit mode instructions.
	(machine): New static variable specifying processor.
	(print_insn_i286_or_i386): Renamed from print_insn_i386.
	Remove hard-coding of 32-bit code and add special cases for 16-bit
        mode mod/rm fields.
	(print_insn_i286, print_insn_i386): New external entry points.
	* opcodes/disassemble.c (disassembler): Add i286 check.

*** gdb-940601/bfd/archures.c-dist	Tue Mar 15 10:08:54 1994
--- gdb-940601/bfd/archures.c	Sat Jun  4 20:42:25 1994
***************
*** 86,91 ****
--- 86,93 ----
  .  bfd_arch_sparc,     {* SPARC *}
  .  bfd_arch_mips,      {* MIPS Rxxxx *}
  .  bfd_arch_i386,      {* Intel 386 *}
+ .#define bfd_mach_i286   1
+ .#define bfd_mach_i386   2
  .  bfd_arch_we32k,     {* AT&T WE32xxx *}
  .  bfd_arch_tahoe,     {* CCI/Harris Tahoe *}
  .  bfd_arch_i860,      {* Intel 860 *}
*** gdb-940601/bfd/bfd-in2.h-dist	Wed Jun  1 17:10:34 1994
--- gdb-940601/bfd/bfd-in2.h	Sat Jun  4 20:42:26 1994
***************
*** 959,964 ****
--- 959,966 ----
    bfd_arch_sparc,      /* SPARC */
    bfd_arch_mips,       /* MIPS Rxxxx */
    bfd_arch_i386,       /* Intel 386 */
+ #define bfd_mach_i286   1
+ #define bfd_mach_i386   2
    bfd_arch_we32k,      /* AT&T WE32xxx */
    bfd_arch_tahoe,      /* CCI/Harris Tahoe */
    bfd_arch_i860,       /* Intel 860 */
*** gdb-940601/opcodes/i386-dis.c-dist	Wed Mar 30 04:17:53 1994
--- gdb-940601/opcodes/i386-dis.c	Sat Jun  4 20:42:26 1994
***************
*** 703,708 ****
--- 703,711 ----
  static char *names_seg[] = {
    "%es","%cs","%ss","%ds","%fs","%gs","%?","%?",
  };
+ static char *names_rmw[] = {
+   "%bx,%si","%bx,%di","%bp,%si","%bp,%di","%si","%di","%bp","%bx", 
+ };
  
  struct dis386 grps[][8] = {
    /* GRP1b */
***************
*** 950,957 ****
      }
  }
  
  static int dflag;
! static int aflag;		
  
  static char op1out[100], op2out[100], op3out[100];
  static int op_address[3], op_ad, op_index[3];
--- 953,961 ----
      }
  }
  
+ static int machine;
  static int dflag;
! static int aflag;
  
  static char op1out[100], op2out[100], op3out[100];
  static int op_address[3], op_ad, op_index[3];
***************
*** 966,974 ****
   *   be used to print the target address if this is a relative jump or call
   * The function returns the length of this instruction in bytes.
   */
! 
! int
! print_insn_i386 (pc, info)
       bfd_vma pc;
       disassemble_info *info;
  {
--- 970,977 ----
   *   be used to print the target address if this is a relative jump or call
   * The function returns the length of this instruction in bytes.
   */
! static int
! print_insn_i286_or_i386 (pc, info)
       bfd_vma pc;
       disassemble_info *info;
  {
***************
*** 1025,1034 ****
        return (1);
      }
    
-   /* these would be initialized to 0 if disassembling for 8086 or 286 */
-   dflag = 1;
-   aflag = 1;
-   
    if (prefixes & PREFIX_DATA)
      dflag ^= 1;
    
--- 1028,1033 ----
***************
*** 1140,1145 ****
--- 1139,1166 ----
    return (codep - inbuf);
  }
  
+ int
+ print_insn_i286 (pc, info)
+      bfd_vma pc;
+      disassemble_info *info;
+ {
+   machine = 286;
+   dflag = 0;
+   aflag = 0;
+   return print_insn_i286_or_i386 (pc, info);
+ }
+ 
+ int
+ print_insn_i386 (pc, info)
+      bfd_vma pc;
+      disassemble_info *info;
+ {
+   machine = 386;
+   dflag = 1;
+   aflag = 1;
+   return print_insn_i286_or_i386 (pc, info, 36);
+ }
+ 
  char *float_mem[] = {
    /* d8 */
    "fadds",
***************
*** 1539,1544 ****
--- 1560,1595 ----
      }
    
    append_prefix ();
+ 
+   if (machine == 286)
+     {
+       if (mod == 0 && rm == 6)
+ 	{
+ 	  sprintf (scratchbuf, "0x%04.4x", get16 ());
+ 	  oappend (scratchbuf);
+ 	  return 0;
+ 	}
+       
+       if (mod == 1)
+ 	{
+ 	  FETCH_DATA (the_info, codep + 1);
+ 	  disp = *(char *)codep++;
+ 	}
+       else if (mod == 2)
+ 	disp = get16 ();
+       else
+ 	disp = 0;
+       if (disp != 0)
+ 	{
+ 	  sprintf (scratchbuf, "0x%x", disp & 0xffff);
+ 	  oappend (scratchbuf);
+ 	}
+ 
+       sprintf (scratchbuf, "(%s)", names_rmw[rm]);
+       oappend (scratchbuf);
+       return 0;
+     }
+ 
    if (rm == 4)
      {
        havesib = 1;
*** gdb-940601/opcodes/disassemble.c-dist	Thu Apr 28 19:02:53 1994
--- gdb-940601/opcodes/disassemble.c	Sat Jun  4 20:42:26 1994
***************
*** 78,84 ****
  #endif
  #ifdef ARCH_i386
      case bfd_arch_i386:
!       disassemble = print_insn_i386;
        break;
  #endif
  #ifdef ARCH_i960
--- 78,87 ----
  #endif
  #ifdef ARCH_i386
      case bfd_arch_i386:
!       if (bfd_get_mach(abfd) == bfd_mach_i286)
! 	disassemble = print_insn_i286;
!       else
! 	disassemble = print_insn_i386;
        break;
  #endif
  #ifdef ARCH_i960
*** gdb-940601/include/dis-asm.h-dist	Thu Apr 28 19:07:33 1994
--- gdb-940601/include/dis-asm.h	Sat Jun  4 20:42:26 1994
***************
*** 96,101 ****
--- 96,102 ----
  
  extern int print_insn_big_mips		PARAMS ((bfd_vma, disassemble_info*));
  extern int print_insn_little_mips	PARAMS ((bfd_vma, disassemble_info*));
+ extern int print_insn_i286		PARAMS ((bfd_vma, disassemble_info*));
  extern int print_insn_i386		PARAMS ((bfd_vma, disassemble_info*));
  extern int print_insn_m68k		PARAMS ((bfd_vma, disassemble_info*));
  extern int print_insn_z8001		PARAMS ((bfd_vma, disassemble_info*));

Re: 16-bit i386 code support in GAS

[Ken Raeburn]

   Date: Wed, 09 Nov 94 12:06:51 MST
   From: Bryan Ford <baford@schirf.cs.utah.edu>


   I've sent messages (including bug _fixes_, not just reports)
   to bug-gnu-utils several times before, and have never gotten any
   kind of response whatsoever - my mail just disappears into the void. :-)

Yeah, I've been known to not respond very quickly, or sometimes at
all, depending on (among other things) the severity of the problem,
whether it's been reported before, whether I've responded to another
posting of the same bug on bug-gnu-utils already, whether I've got a
fix, how hard it looks to fix, how informative the bug report is, how
swamped I feel with work I'm doing for Cygnus customers, what I had
for breakfast, ...  I'm not especially organized or disciplined when
it comes to dealing with mail.

But I'll usually keep the message around unless I've got some reason
for thinking I won't need it -- for example, it describes a problem I
think is already fixed, or something -- and I don't see your message
among my saved mail.  How long ago was it?  Is the problem fixed in
binutils-2.5.2?  If it isn't, please resend it to me personally.

Re: 16-bit i386 code support in GAS

[Bryan Ford]

>   Date: Wed, 09 Nov 94 12:06:51 MST
>   From: Bryan Ford <baford@schirf.cs.utah.edu>
>
>
>   I've sent messages (including bug _fixes_, not just reports)
>   to bug-gnu-utils several times before, and have never gotten any
>   kind of response whatsoever - my mail just disappears into the void. :-)
>
>Yeah, I've been known to not respond very quickly, or sometimes at
>all, depending on (among other things) the severity of the problem,
>whether it's been reported before, whether I've responded to another
>posting of the same bug on bug-gnu-utils already, whether I've got a
>fix, how hard it looks to fix, how informative the bug report is, how
>swamped I feel with work I'm doing for Cygnus customers, what I had
>for breakfast, ...  I'm not especially organized or disciplined when
>it comes to dealing with mail.
>
>But I'll usually keep the message around unless I've got some reason
>for thinking I won't need it -- for example, it describes a problem I
>think is already fixed, or something -- and I don't see your message
>among my saved mail.  How long ago was it?  Is the problem fixed in
>binutils-2.5.2?  If it isn't, please resend it to me personally.

Actually, the messages I'm referring to weren't about GAS; they
concerned other GNU utilities whose maintainers also supposedly
live on the bug-gnu-utils list.  In particular, a while ago I sent
in a patch to the 'patch' program that makes it work with binary
files and binary diffs (diff -a).  Also, I sent in a patch to
autoconf-1.11 around the time when that was the most recent version,
to add a couple new features needed by the new Mach build environment.
Neither of these were bug "reports" needing hunting down and fixing;
they were actual patches that should only need a brief look-through
and a merge.  But as I said I never got any response to either.

Anyway, I expect neither of those are your problems; but it would
be helpful if _somebody_ was handling those other utilities. :-)

				Bryan

Re: 16-bit i386 code support in GAS

[Ken Raeburn]

Ah, okay.  No, diff and autoconf and the like aren't my problem...