> > 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/