bootsect.S: 2 questions

bootsect.S: 2 questions

[Mad Hatter]

Hi,

I was looking through the linux (2.5.56) arch/i386/boot/bootsect.S and was
puzzled about a couple of things:

1. Near line 221 we have:
       sread:  .word 0             # sectors read of current track
       head:   .word 0             # current head
       track:  .word 0             # current track

   However, since a diskette can have at most 2 heads, 80 tracks and 36 sectors
   per track, why are these not bytes instead of words especially since space is
   at such a tight premium in this code ?

2. Near line 272 we have "movw    $7, %bx" but the documentation I've
    been able to find about the "int 0x10" BIOS call says that for service
    code 0xe (write character and advance cursor), it does not take an
    attribute byte input parameter but rather uses the existing attribute. Is
    this movw instruction superfluous ?

Thanks. 

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: bootsect.S: 2 questions

[Richard B. Johnson]

On Mon, 13 Jan 2003, Mad Hatter wrote:

> Hi,
> 
> I was looking through the linux (2.5.56) arch/i386/boot/bootsect.S and was
> puzzled about a couple of things:
> 
> 1. Near line 221 we have:
>        sread:  .word 0             # sectors read of current track
>        head:   .word 0             # current head
>        track:  .word 0             # current track
> 
>    However, since a diskette can have at most 2 heads, 80 tracks and 36 sectors
>    per track, why are these not bytes instead of words especially since space is
>    at such a tight premium in this code ?
>

Because, when they are used, they are ORed into word-sized registers.
The track and sector are are put into register CX and the head and drive
number are put into DX.

> 2. Near line 272 we have "movw    $7, %bx" but the documentation I've
>     been able to find about the "int 0x10" BIOS call says that for service
>     code 0xe (write character and advance cursor), it does not take an
>     attribute byte input parameter but rather uses the existing attribute. Is
>     this movw instruction superfluous ?
> 

On page 218, "System BIOS for IBM PC/XT/AT Computers", Phoenix
Technical Reference Series, ISBN 0-201-51806-6, the documentation
clearly states that BL contains the foreground color and BH the
active page. Therefore 0x0007 is the correct value to be put
into that register for the "Write Teletype to Active Page" function.

FYI, the startup functions are used once-per-boot. Any "improvements"
other than those necessary to "fix" something are useless in the
overall scheme of things.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: bootsect.S: 2 questions

[Randy.Dunlap]

Hi-

(mostly "what R. Johnson said")

On Mon, 13 Jan 2003, Mad Hatter wrote:

| I was looking through the linux (2.5.56) arch/i386/boot/bootsect.S and was
| puzzled about a couple of things:
|
| 1. Near line 221 we have:
|        sread:  .word 0             # sectors read of current track
|        head:   .word 0             # current head
|        track:  .word 0             # current track
|
|    However, since a diskette can have at most 2 heads, 80 tracks and 36 sectors
|    per track, why are these not bytes instead of words especially since space is
|    at such a tight premium in this code ?

If you change those to bytes to save 3 bytes of space, and then you
change all of the instructions that load or store those values to 16-bit
registers, do you have a net saving of space?
Or you load/store them to 8-bit registers and rewrite the code, what
happens?

| 2. Near line 272 we have "movw    $7, %bx" but the documentation I've
|     been able to find about the "int 0x10" BIOS call says that for service
|     code 0xe (write character and advance cursor), it does not take an
|     attribute byte input parameter but rather uses the existing attribute. Is
|     this movw instruction superfluous ?

Perhaps, or perhaps on some particular system it was found to be needed.
We don't have a fully indexed changelog history of each line AFAIK.
Ralf Brown's interrupt page for this function says:
  BH = page number
  BL = foreground color (graphics modes only)
(see http://www.ctyme.com/intr/rb-0106.htm)
Or it could be important to clear BH and setting BL to 7 was just safe.

-- 
~Randy

Re: bootsect.S: 2 questions

[Mad Hatter]

Thanks for the pointers to Ralf Brown's interrupt page.

--- "Richard B. Johnson" <root@chaos.analogic.com> wrote:

>FYI, the startup functions are used once-per-boot. Any "improvements"
>other than those necessary to "fix" something are useless in the
>overall scheme of things.

Sure. I'm a novice at both the x86 instruction set and the GNU assembler
and I'm just trying to understand the reason the code is written the way
it is.

--- "Randy.Dunlap" <rddunlap@osdl.org> wrote:
 
> If you change those to bytes to save 3 bytes of space, and then you
> change all of the instructions that load or store those values to 16-bit
> registers, do you have a net saving of space?
> Or you load/store them to 8-bit registers and rewrite the code, what
> happens?

I looked at one place where these words are used: the read_track routine.
Part of that code looks like this:
-------------------------------
	movw	4(%si), %dx		# 4(%si) = track
	movw	(%si), %cx		# (%si)  = sread
	incw	%cx
	movb	%dl, %ch
	movw	2(%si), %dx		# 2(%si) = head
	movb	%dl, %dh
	andw	$0x0100, %dx
	movb	$2, %ah
---------------------------------

If this code is rewritten to use byte instructions (and sread, head, track
are changed to .byte instead of .word) like so (the last two instructions
are unchanged):
-----------------------------------------------
	movb	(%si), %cl		# (%si)  = sread
	incb	%cl
	movb	2(%si), %ch		# 2(%si) = track
	movb	1(%si), %dh		# 1(%si) = head
	andw	$0x0100, %dx
	movb	$2, %ah
------------------------------------------------

there is a net saving of 6 bytes. (I compiled this with "gcc -c", linked
with "ld --oformat binary -Ttext 0x0" and compared the size of the results).

I'm not proposing this as a fix BTW; just an academic exercise, really.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com