Recent Posts

Pages: [1] 2 3 ... 10
Programming with NASM / Re: Sys_brk effects on stack
« Last post by munair on March 31, 2020, 06:08:06 AM »
Here is a nice link that demonstrates memory management in asm:
Programming with NASM / Re: Sys_brk effects on stack
« Last post by munair on March 31, 2020, 05:55:48 AM »
Hi encryptor256!

It is not that I don't trust malloc or anything like that :D Reason for my unwillingness to use malloc is the opportunity to learn by doing. It is extremely intriguing to try to figure out how to solve issues with memory management for example external and internal fragmentation of the heap.
While this is an old topic, I would like to add that I perfectly understand why someone prefers not to use C libraries in asm. I am currently developing asm routines for a compiler and mixing asm with C just doesn't feel right somehow. Of course, using C libs would be a quick short cut, but there is less/no satisfaction in doing that. In my particular case, I want a pure language (the compiler) with nasm / ld as backend without having to lean on C or any other high level language. I suppose it is really a matter of taste.
Other Discussion / Am I using the Graphics Buffer correctly?
« Last post by Johnpaul Humphrey on March 30, 2020, 04:11:03 AM »
Hi all,
I recently got into assembly again.
I started out using Linux system calls, but I felt distanced from the actual computer, so I decided to get into bare metal. I want to write programs for computers instead of operating systems.
I started out with text mode, and that went fairly smoothly. (smoothly means I was able to correct the errors in my code)
I have been writing my code in a text editor (vi)
Then assembling them with the following command
nasm -f bin boot.asm
Then running them on QEMU
qemu-system-i386 boot

So I decided to get into graphics.
My goal is very simple: create a checkerboard of black and white pixels.
Graphics Mode 6h seemed to suit my purpose. 320x200x2
I wrote the following code:
Code: [Select]
bits 16
org 0x7c00
        mov ah, 00h ;change graphics mode
        mov al, 06h ;320x200x2
        int 10h ;bios graphics service

        mov ebx, 0xb8000 ;start of video
        mov cl, 0 ;row counter
        cmp cl, 200
        je end
        add cl, 1 ; should this be 2 to compensate for two rows? I see no difference when running it at 2 or 1.
        mov ch, 0 ;colum counter
        .colsa: ;row one
        cmp ch, 80 ; 320 / 4 = 80
        je .colsb
        add ch, 1
        mov word [ebx], 0xaaaa
        add ebx, 1
        jmp .colsa
        .colsb: ;staggered row
        cmp ch, 160
        je rows
        add ch, 1
        mov word [ebx], 0x5555
        add ebx, 1
        jmp .colsb
end: jmp $ ;does this infinite loop run the risk of screen burn? sonce it is a virtual machine, I do not really care.
times 510-($-$$) db 0
dw 0xAA55 ;boot signature

When I run it in QEMU on Linux, I notice something interesting happens.
It does every other line, then comes back and fills in.
I was able to observe this by lowering the compare values.
I have observed the same behavior in Mode 4h.

Is this how the video buffer actually works, or is this a faulty implementation, or better yet, a programming oversight? (My programming is 90% oversight  :) )
Also, how is my coding style?
Is there a better platform to test on than QEMU?
If I should focus on one question per thread, it would be my first one.

I know this is not directly related to NASM. Is there a better forum to post this on?
I know that there is a lot of knowledge on this forum about things related to assembly, so I thought I would post.

Thanks in advance for any help,
Not really. They are a block of "data" that shouldn't be executed at all. To be clear... Nasm does not emit a long string of "add"s. Nasm does not emit any instruction mnemonics  at all. You and I provide those. Nasm converts them to nimbers. Ndisasm converts the numbers to mnemonics. But Ndisasm isn't very bright. Doesn't try to be. It attempts to disassemble everything - executable header, data, padding...

Agner Fog's "objconv" is much brighter! Look for it around "". I think you'll like it!


Programming with NASM / Re: Relocation for PIC code in NASM 64-bit
« Last post by kolargol on March 20, 2020, 09:32:10 PM »
i know i am late, 12 years later lol, but could you provide more translation from the gas code with the same variable name because there is no foo declared in the c source or gas  source making it a little hard to know which operation you refer to.

Hi, Frank,

Yes, I see.  Thanks for clearing that up.  Do those function like no-ops? 

 Hi pam127,

As you can see in the second column, those are zeros. I think you will see that they are not executed. I hope not!


I just used ndisasm to disassemble code I compiled with the NASM compiler.  I see several instances of long blocks where the instruction add [rax],al is repeated, like this:

00000425  0000              add [rax],al
00000427  0000              add [rax],al
00000429  0000              add [rax],al
0000042B  0000              add [rax],al
0000042D  0000              add [rax],al
0000042F  0000              add [rax],al
00000431  0000              add [rax],al
00000433  0000              add [rax],al
00000435  0000              add [rax],al

What do these sequences mean?  Wouldn't this be best reduced to fewer instructions? 

Website and Forum / Dead Links on 'Useful Links' page
« Last post by Jetfrog28 on March 17, 2020, 11:06:00 PM »
There are several dead links at :
Paul Carter's Tutorial ( ) page now appears to be a spam page.  He does seem to have a new page ( ), on which I was able to find the mentioned book.

The link to NASMX also 404s, though I wasn't able to find any recently updated homepage.  This SourceForge page, last updated in 2016, seems to be the project's homepage as far as I can tell: .
It sounds like a nasm bug if it assembles a 16/32/64 bit number into an 8-bit register. It shouldn't be possible.
Pages: [1] 2 3 ... 10