All the (current) new bootcode was written with the idea of "binary
level compatibility" firmly in mind. I had actually worked backward from
the original as86 output to come up with the equivalent gas instructions
when the assembly was questionable, simply because I knew that that encoding
worked. I did that with the idea that 'hey, if it compiles to the same
opcodes, were fine' -- that was the sole plan at the moment: to have a 2.4
kernel that doesn't need as86/ld86 to build.
Yes that makes the source wrong on a pure "syntax" level in quite a few
spots, but does it truly matter if (a) it assembles to the correct
opcodes, (b) gives some much needed testing and real life usage of gas,
so that it finally will do the right things when it comes to 16 bit asms,
and (c) is planned on being (for lack of a better word) "optimized" back
to correctness later on down the road (when everyone's using, or better
yet are forced to use, the latest binutils).
You bring up some valid points, but I feel the intent of the patch was
misjudged.
Just a few points on the latest binutils (which now might be a requirement
of the next 2.3): The changes to the bootcode were intended to be
included with a kernel that had a minimum binutils of 2.9.1.0.7, because
I didn't feel it was worth a binutils upgrade to 2.9.5 to each and every
person in order to have "syntactic perfection" (due to the fact that only
the *latest* binutils produce the most correct code for most every case).
I just wanted joe user to be able to still compile, but without the
dependency on as86.
I've heard we might go to binutils 2.9.5 now, and if it happens I will
happily rework the code to be more clearly, properly written.
Hope that explains my thoughts a bit.
Thanks for the feedback.
Chris Noe
(stiker@northlink.com)
-----Original Message-----
From: Richard B. Johnson [mailto:root@chaos.analogic.com]
Sent: Friday, October 15, 1999 7:57 AM
To: Andrzej Krzysztofowicz
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: bootsect.S changes
On Fri, 15 Oct 1999, Andrzej Krzysztofowicz wrote:
> > On Fri, 15 Oct 1999, Andrzej Krzysztofowicz wrote:
> > > What are the advantages of the following code:
> > > movw $128, %cx
> > > subw %si, %si
> > > subw %di, %di
> > > cld
> > > rep
> > > movsl <------- 32 bit
> > > instead of
> > > movw $256, %cx
> > > subw %si, %si
> > > subw %di, %di
> > > cld
> > > rep
> > > movsw <------- 16 bit
> >
> > You bring up a good point, but it's only the tip of the iceburg.
> > The boot code was changed to use GAS rather than AS86 assembler. I
> > don't know why. However, the resulting code is in may cases plain
>
> I think the reason: to use only one tool
> is clean.
>
> > wrong. I thought I would wait until somebody fixed GAS before I
> > looked at this stuff, but there is a problem requiring immediate
> > attention. The problem is that there doesn't seem to be any way
> > to tell GAS to assemble 16-bit, rather than 32-bit instructions.
>
> However, if the GAS is so buggy while handling 16-bit code
> it was not, IMHO, the right moment to do as86->GAS conversion.
>
> > It is _not_ just putting 'w' or 'l' after an instruction. To explain,
> > If I assemble code in 16-bit mode:
> > mov ax,bx ; Intel
> > byte sequence is 0x89, 0xd8
>
> It seems to be correct.
>
> > If I am in 16-bit mode and want to assemble:
> > mov eax,ebx ; Intel
> > byte sequence is 0x66, 0x89, 0xd8
>
> It also seems to be correct.
>
> > If I am in 32-bit mode and want to assemble:
> > mov eax,ebx ; Intel
> > byte sequence is 0x89, 0xd8 -- just like the 16-bit mov ax,bx
>
> Does it mean that GAS has problems in 32-bit mode ?
>
> > What has happened is that it looks as though source code was 'tweaked`
> > to get the correct binary from GAS. This makes the source-code wrong.
>
> Does this problem appear in all versions of GAS (binutils) or has already
> been corrected ?
>
I think this is still a 'work in progress'. I hope that somebody adds
a directive to gas that tells it to assemble 16-bit code so the source
code doesn't have to be wrong to get it to make 16-bit code. The
prefix 0x66 is a switch. It changes the default oprand size of the
processor. If the processor is in 32-bit mode, 0x66 is used to make
it do word, instead of longword operations. If the processor is
in 16-bit mode, 0x66 prefix makes it do longword instead of the default
word operations. Therefore, an assembler needs to 'know' when to
not use 0x66. In other words it needs to know the current operation
mode of the processor.
Maybe a switch like ".i-32" (Intel 32-bit) ".i-16" (Intel 16-bit)
needs to be added to GAS.
Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/