C++

Forum

 
Assembly question

adam2016 (1529)
hi guys,

1
2
3
4
5
6
7
8
9
10
 

loop:
   
    jmp loop

  times 510-($-$$) db 0


  dw 0xaa55


I'm really not familiar with assembly, but the following code is supposed to write a simple boot sector, so I really don't know where to start here

I'm guessing loop: is analog to a higher level languages function/procedure named loop?

when the file gets executed we keep on jumping to loop,

so two main questions what does loop even do?? it looks blank to me

and more importantly how do we reach times 510-($-$$) db 0 and dw 0xaa55 if we repeatedly jump to the loop label?

I will give my brief understanding of the code again,

we define a function with the label loop: loop doesn't do anything, we jump to loop and we are stuck in an infinite jmp sequence( infinite loop ) so again do we ever hot the next couple of lines?

I mean if we compare this to C++

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 

   void loop(){

       // nothing
    }

    int main(){
      
       while(true)
         loop();
         // write to 510 bytes to a file?
         // write 0xaa55 to a file?
    
    }


on a side note, what are we writing to does dw specify a file name that we are writing to?

thanks

helios (17588)
loop: is analog to a higher level languages function/procedure named loop?
In Assembly languages, labels are simply jump destinations. Places that can be jumped to from other locations.

so two main questions what does loop even do?? it looks blank to me
That's correct. It's an infinite loop that doesn't do anything.

and more importantly how do we reach times 510-($-$$) db 0 and dw 0xaa55 if we repeatedly jump to the loop label?
You don't. Your boot sector consists of a single instruction. What would be the point of continuing to execute, even if the loop was capable of terminating?

I will give my brief understanding of the code again,

we define a function with the label loop: loop doesn't do anything, we jump to loop and we are stuck in an infinite jmp sequence( infinite loop ) so again do we ever hot the next couple of lines?

I mean if we compare this to C++
No, it's more like while (true);

on a side note, what are we writing to does dw specify a file name that we are writing to?
I don't know what you mean by "what are we writing to". "dw" means "data word". In other words, it tells the assembler "at this point in the binary I want these particular arbitrary values". By the way, "db" means "data byte", which is used to zero-fill the majority of the file.
adam2016 (1529)
Oh ok, so when we assemble the code above:

I'm guessing this is what happens when I have the binary at the first sector of a hard disk ofcourse or bootable medium( at least at a basic level ), the BIOS looks for a boot sector, it finds one as it comes across the magic number 0xaa55 on our bin file, which is just raw binary, the CPU then executes this boot sector and it hangs in an infinite loop,

I don't know what you mean by "what are we writing to". "dw" means "data word". In other words, it tells the assembler "at this point in the binary I want these particular arbitrary values". By the way, "db" means "data byte", which is used to zero-fill the majority of the file.


that makes sense, I'm confusing higher level constructs with assembly, we are actually writing
0xaa55 to the bin file itself with dw, so 0xaa55 will just be placed after 510 zeros right?

__________________________________________________________________________________

Another few things that kind of confuse me, I assembled the file using a nasm assembler and the file is 512 bytes (which it should be) but I fail to see how this file would only be 512 bytes, doesn't the jump instruction take a couple of bytes too?

so the jump instruction should be maybe 2 bytes, and then we write 510 zeroes followed by another 2 bytes 0xaa55 , so in total shouldn't this be 510 + 2 + 2(for jump instruction) = 514?

after I assembled the program with - nasm boot.asm -f bin -o boot.bin

I checked the size and strangely enough it's 512 bytes, so are the jump instructions not included?

*edit
After spending a couple of hours of researching I think I understand, times 510-($-$$) db 0

so ($-$$) will give us the current position AKA how many bytes we have written which in our case is 2, so we subtract 510 - 2 = 508, so we write 508 bytes followed by 0xaa55
 I think that's correct?


and lastly I again created a disk image and made a new vm and set the vdi to this new disk image ( from the bin file created with nasm ) and again it worked ( boot screen stuck in text mode ),

but I examined both bin files, the one I created manually the first time and the one I created second time around with nasm, they both do the same thing but for some reason the first couple of bytes differ.

in the first one the first three bytes are E9 FD FF followed by zeroes until the magic number.

and in the second bin file created from nasm only the first two bytes are set - EB FE followed by zeroes until the magic number,

so why does nasm produce different results and how come it essentially does the same thing?

Last edited on
jonnin (11444)
are you looking at the executable result?
Those are not one to one with the code -- there are some setup and other things needed by a executable program. Look at it in a hex editor sometime.
I dumped a random exe file and I get blah blah "this program cannot be run in dos" and presumably 16 bit statements to print that if you tried to run it in dos.
Last edited on
helios (17588)
This is a boot sector, man. Boot sectors don't have any structure, they just get loaded as they are and the CPU jumps directly to the first byte position.
jonnin (11444)
good point. Not sure what that looks like compiled, haven't taken one apart.
againtry (2313)
Topic archived. No new replies allowed.