> At power-up, the cpu is essentially emulating an 8086.  All registers
> are 16 bits.  All addresses are 20-bit segment:offset register pairs.
> 
> Anyway, the problem is, gas knows nothing about such a brain damaged
> mode of execution.  And when told to generate code for something like:
> 
>     movl        $0x42, %eax
> 
> generates the machine code for "execute a move immediate instruction
> using the natural word size of the machine (32-bits) with immediate
> data '0x00000042'"

This is mostly true...  The one part that's wrong is that "gas knows
nothing about ..."

To quote some mail sent by Bryan Ford <baford@snake.cs.utah.edu> to
another mailing list, a few days go:
> [ ... ]  Some time ago I added support for 16-bit x86 code
>to the GNU assembler, and it's been fully functional and integrated into
>the mainline Cygnus binutils distribution for quite a while now.  Just
>use the '.code16' directive to switch GAS into 16-bit mode, and all the
>instructions after that will be 16-bit instructions that can be executed
>in real mode or from 16-bit protected mode code segments or whatever.
>Use the '.code32' directive to switch back to 32-bit code generation.
>
>Furthermore, since the syntax doesn't change when GAS is in 16-bit mode,
>you can even write 16-bit small-model code using GCC.  Just place an
>asm(".code16"); at the beginning of your .c file, and the generated code
>will run fine in real mode on a 386 or better.  (It won't work on a 286
>or lower because the generated code contains lots of 32-bit instructions,
>since GCC still thinks it's generating 32-bit code.) 

In other words, a fair bit of the i386 bootblocks' 16 vs. 32 bit
nastiness is now unnecessary...


Of course, the version of GNU 'as' which is included in NetBSD is not
recent enough to include those changes...  (actually, i'm not sure
that they're in the mainline GNU sources, but they are in the cygnus
sources.)


cgd