From mboxrd@z Thu Jan  1 00:00:00 1970
From: dj@stealth.ctron.com (DJ Delorie)
To: rms@gnu.ai.mit.edu
Cc: hjl@nynexst.com, gas2@cygnus.com, masaki@eie.minolta.co.jp, raeburn@cygnus.com
Subject: Re: [masaki@eie.monolta.co.jp: GAS bug and etc]
Date: Fri, 11 Nov 1994 10:46:00 -0000
Message-id: <9411111848.AA05929@delorie>
References: <9411111830.AA21125@mole.gnu.ai.mit.edu>
X-SW-Source: 1994/msg00192.html

> Supporting 16-bit mode assembly for the 386 is not harmful if it is
> easy, but if it takes up a lot of time, then it might be better off
> left out.  Do we need to have a program that runs in 16-bit mode for
> booting?  If so, how big a program would it have to be?  (I presume
> all it needs to do is switch to 32-bit mode.)  Might it be easier to
> hand assemble that program than to add and subsequently maintain this
> gas feature?

Even when in protected mode, the 386 and up processors support
variable width operations.  For example, when C calls for a "short",
the 386 uses a 16-bit register and thus needs 16-bit operations.  This
has nothing to do with the runtime mode of the CPU or the default size
of the segment (16 vs 32), and must be supported on all 386-based
systems, including Hurd.

The theory is that since gas must already support these 16-bit
instructions for the i386 anyway, it should be trivial to tell it that
the *default* size should be assumed different, so that it would
produce code that assumed it was running in a 16-bit segment instead
of a 32-bit segment.  Then, the only work that would need to be done
is to produce dos-style OMF output, which is also used for some 32-bit
systems.

As for the separate topic of bootstrapping 32-bit programs in the
16-bit world of DOS, we've got that covered already, so that you can
fully bootstrap djgpp 2.0 with nothing but GNU tools.  We wrote a VERY
simple 16-bit assembler with which to assemble the bootstrap code.

DJ