> Hi,
> As I see the i386 bootsect code evaluates into 32 bit code.
> Could anybody explain me what is the reason ?
>
> 32-bit code is in most cases a bit larger (one byte per statement)
> but in the bootsector every byte is very valuable. Are there any problems
> with 16-bit code? (compilation? non-working on some machines?)
>
> 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
> (which is shorter), etc.
> I hope, nobody will joke saying it is faster ...
>
> Regards
> Andrzej
>
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
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.
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
If I am in 16-bit mode and want to assemble:
mov eax,ebx ; Intel
byte sequence is 0x66, 0x89, 0xd8
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
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.
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/