Re: [x86 setup 13/33] Header file to produce 16-bit code with gcc

From: Segher Boessenkool
Date: Tue Jul 10 2007 - 16:08:46 EST

gcc for i386 can be used with the assembly prefix ".code16gcc" to
generate
16-bit (real-mode) code. This header file provides the assembly
prefix.
This only works correctly with newer GCCs if you pass the
-fno-toplevel-reorder option (and it only works on older
GCC versions by accident).

And on older ones (gcc-3.3-hammer / 3.4 / 4.0 ) -fno-unit-at-a-time

Still it seems quite fragile to me agreed.

The alternative, of course, is to compile to an .s file and insert
.code16gcc into the .s file. This makes the Makefile uglier, but would
be more resilient against oddball gcc changes.

This would be even more fragile. The exact format of GCC's
assembler code output isn't defined at all, so in principle
this is a hopeless task. In practice just putting the
.code16gcc directive on the first line would likely work
though, GCC never generates a .code32 AFAIK, but it isn't
guaranteed that this will work (or will keep working).

I'm a bit surprised about the claim w.r.t. -fno-unit-at-a-time (although
I guess that is the default and one would thus typically not see this.)

-fno-unit-at-a-time is the default on three year old compilers,
yes. Newer compilers have unit-at-a-time enabled by default.

Got any pointers why that would cause a global asm() to be scrambled
around?

An asm() outside of a function is a top-level thing, just
like functions and file-scope variable definitions, and with
unit-at-a-time compilation all such blocks can be reordered
(or even omitted, or inlined, or whatever). Note that even
before unit-at-a-time was introduced there was no guarantee
of emitting everything in the order it appears in the source
file.


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/