* Re: 16-bit i386 code support in GAS [not found] <199411091455.HAA25021@schirf.cs.utah.edu> @ 1994-11-09 7:20 ` H.J. Lu 1994-11-09 10:49 ` Ken Raeburn 0 siblings, 1 reply; 7+ messages in thread From: H.J. Lu @ 1994-11-09 7:20 UTC (permalink / raw) To: Bryan Ford; +Cc: gas2, Ken Raeburn, Ian Lance Taylor > > (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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 16-bit i386 code support in GAS 1994-11-09 7:20 ` 16-bit i386 code support in GAS H.J. Lu @ 1994-11-09 10:49 ` Ken Raeburn 1994-11-09 11:06 ` Bryan Ford 1994-11-09 19:22 ` Rick Sladkey 0 siblings, 2 replies; 7+ messages in thread From: Ken Raeburn @ 1994-11-09 10:49 UTC (permalink / raw) To: Bryan Ford; +Cc: gas2 > (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... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 16-bit i386 code support in GAS 1994-11-09 10:49 ` Ken Raeburn @ 1994-11-09 11:06 ` Bryan Ford 1994-11-09 23:35 ` Ken Raeburn 1994-11-09 19:22 ` Rick Sladkey 1 sibling, 1 reply; 7+ messages in thread From: Bryan Ford @ 1994-11-09 11:06 UTC (permalink / raw) To: Ken Raeburn; +Cc: gas2 > > (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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 16-bit i386 code support in GAS 1994-11-09 11:06 ` Bryan Ford @ 1994-11-09 23:35 ` Ken Raeburn 1994-11-10 6:57 ` Bryan Ford 0 siblings, 1 reply; 7+ messages in thread From: Ken Raeburn @ 1994-11-09 23:35 UTC (permalink / raw) To: Bryan Ford; +Cc: gas2 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 16-bit i386 code support in GAS 1994-11-09 23:35 ` Ken Raeburn @ 1994-11-10 6:57 ` Bryan Ford 1994-11-10 11:51 ` Ken Raeburn 0 siblings, 1 reply; 7+ messages in thread From: Bryan Ford @ 1994-11-10 6:57 UTC (permalink / raw) To: Ken Raeburn; +Cc: gas2 > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 16-bit i386 code support in GAS 1994-11-10 6:57 ` Bryan Ford @ 1994-11-10 11:51 ` Ken Raeburn 0 siblings, 0 replies; 7+ messages in thread From: Ken Raeburn @ 1994-11-10 11:51 UTC (permalink / raw) To: Bryan Ford; +Cc: gas2 Ah, okay. No, diff and autoconf and the like aren't my problem... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 16-bit i386 code support in GAS 1994-11-09 10:49 ` Ken Raeburn 1994-11-09 11:06 ` Bryan Ford @ 1994-11-09 19:22 ` Rick Sladkey 1 sibling, 0 replies; 7+ messages in thread From: Rick Sladkey @ 1994-11-09 19:22 UTC (permalink / raw) To: Ken Raeburn; +Cc: gas2 > 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*)); ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1994-11-10 11:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199411091455.HAA25021@schirf.cs.utah.edu> 1994-11-09 7:20 ` 16-bit i386 code support in GAS H.J. Lu 1994-11-09 10:49 ` Ken Raeburn 1994-11-09 11:06 ` Bryan Ford 1994-11-09 23:35 ` Ken Raeburn 1994-11-10 6:57 ` Bryan Ford 1994-11-10 11:51 ` Ken Raeburn 1994-11-09 19:22 ` Rick Sladkey
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).