unsure of ASM line

[wangpeng]

I came across a line in some ASM code:

MOVB 4(di), *36

a) Is that 4(di) just simple multiplication? I know that NASM takes 4*di, but I'm not sure what compiler the guy was using (doesn't look like TASM tho)

b) What is that star doing in front of the 36?

Can someone help an ASM n00b?

[Perica]

..

[wangpeng]

Well, I can't tell you what compiler it's from, because I don't know, but the context of the line is:

/*
*   Many BIOS's default disk parameter tables will not
*   recognize multi-sector reads beyond the maximum sector number
*   specified in the default diskette parameter tables - this may
*   mean 7 sectors in some cases.
*
*   Since single sector reads are slow and out of the question,
*   we must take care of this by creating new parameter tables
*   (for the first disk) in RAM. We will set the maximum sector
*   count to 36 - the most we will encounter on an ED 2.88.
*
*   High doesn't hurt. Low does.
*
*   Segments are as follows: ds=es=ss=cs - INITSEG,
*      fs = 0, gs is unused.
*/

! cx contains 0 from rep movsw above

   mov   fs,cx
   mov   bx,#0x78      ! fs:bx is parameter table address
   push   ds
   seg fs
   lds   si,(bx)         ! ds:si is source

   mov   cl,#6         ! copy 12 bytes
   cld
   push   di

   rep
   movsw

   pop   di
   pop   ds

   movb   4(di),*36      ! patch sector count

   seg fs
   mov   (bx),di
   seg fs
   mov   2(bx),es

That formatted bad, so the link to the page is:
http://www.nondot.org/sabre/os/files/Bo ... ector.html

It is the Linux 2.0 bootsector (I know I should probably ask this in OS, now that included context).

[Schol-R-LEA]

I came across a line in some ASM code:

MOVB 4(di), *36

a) Is that 4(di) just simple multiplication? I know that NASM takes 4*di, but I'm not sure what compiler the guy was using (doesn't look like TASM tho)

b) What is that star doing in front of the 36?

Can someone help an ASM n00b?

Simple. This is most likely AT&T style code, probably written for gas (GNU assembler). AT&T syntax was originally designed for radically different processor, and is quite different from theat which Intel designed. Assuming that I am reading this correctly, then in the more common Intel syntax, it would be expressed as:

Code: Select all

MOV [36], byte [DI + 4]

(Source: the DJGPP FAQ, section 17.1)

The 'b' at the end of the instruction indicates a byte operand. The asterisk ('*') indicates that it should be read as an absolute address. the idiom %reg(offset) or offset(%reg) indicate that it should be read as an index.

That's still an odd line of code, though. First off, in AT&T syntax, registers are always prefixed with a percent sign ('%'); as you have it written, it would seem that 'DI' refers to a label, not the Destination Index register. I don't believe that such a memory-relative index would work, offhand, but I'd have to check. Are you sure there wasn't a percent sign there?

Second, it seems to be moving the value into absolute address 36 decimal, which the 9th entry in the IVT, but it is loading a byte rather than a double word. This is extremely odd, to say the least, and again, I suspect that there's something wrong with how you have it written down.

Where did you find this line of code, anyway? It may clarify the intention of it.

[wangpeng]

Well, as I mentioned before it's Linus Torvald's Linux 2.0 boot sector...and as for why the line doesn't have % for registers I dunno (as I said I'm pretty much bound to NASM which doesn't do that). I think I may be able to figure it out now...I hope...

That DI question is *very* odd, the code is reproduced exactly (c&p) and I'd assume whoever posted the bootsector code posted a working version...

[Schol-R-LEA]

I see you posted it while I was looking up stuff. OK. Yeah, this is actually written for as86, a special 16-bit assembler primarily used for generating the Linux boot loader. That explains the anomalies - it's syntax is something of a mix of the AT&T and Intel syntaxes. I don't know much about it beynd that, though.

[stonedzealot]

AHA! That's why I couldn't figure it out! I looked everywhere! Thanks so much, I can stop obsessing about the thing. Whew*

Thanks alot!