Messages in this thread | | | Date | Fri, 15 Oct 1999 14:27:00 -0700 | From | "Chris Noe" <> | Subject | RE: bootsect.S changes |
| |
(hating to reply using Outlook, but forced :)
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/
| |