Recent Posts

Pages: [1] 2 3 ... 10
1
Programming with NASM / Re: How many for loops are possible in nasm ?
« Last post by debs3759 on Today at 11:15:34 AM »
I would think that you can use as many loops as you want. It's down to the programmer to write appropriate code and algorithms.
2
Programming with NASM / How many for loops are possible in nasm ?
« Last post by Roddy MacPhee on May 22, 2024, 11:41:08 PM »
I know of at least 40 different variants, but i'm wondering how many are useful (possible).
3
Other Discussion / Re: sprintf_s plus printf
« Last post by alCoPaUL on May 15, 2024, 09:23:05 PM »
essential msvcrt.lib for win64asm...

4
Example Code / sprintf_s plus printf
« Last post by alCoPaUL on May 15, 2024, 09:22:14 PM »
Code: [Select]
;r9 //      sprintf_s + printf
;r8 //      by alCoPaUL [GIMO]
;rdx //         5/15/2024
;rcx //    Brigada Ocho [b8] Productions
;call // rax
global m
extern printf
extern sprintf_s
section .text
m:sub rsp,28h
lea r8,x
lea rdx,i
lea rcx,b
call sprintf_s
mov r8, rax
lea rdx,b
lea rcx,i
call printf
add rsp,28h
ret
section .data
x:db 'Revelation 13'
......
.....
....

Full file attached with the msvcrt.lib for win64asm..

5
Other Discussion / Re: sprintf_s plus printf
« Last post by alCoPaUL on May 15, 2024, 09:19:55 PM »
NASM Version

Code: [Select]
;r9 //      sprintf_s + printf
;r8 //      by alCoPaUL [GIMO]
;rdx //         5/15/2024
;rcx //    Brigada Ocho [b8] Productions
;call // rax
global m
extern printf
extern sprintf_s
section .text
m:sub rsp,28h
lea r8,x
lea rdx,i
lea rcx,b
call sprintf_s
mov r8, rax
lea rdx,b
lea rcx,i
call printf
add rsp,28h
ret
section .data
x:db 'Revelation 13'
....
....
....

full file attached..
6
Other Discussion / sprintf_s plus printf
« Last post by alCoPaUL on May 15, 2024, 06:06:02 PM »
imma translate this to NASM (should be ezpz) later coz i just finished this version for the other assembler..

snippet below

Code: [Select]
;r9 //      sprintf_s + printf
;r8 //      by alCoPaUL [GIMO]
;rdx //         5/15/2024
;rcx //    Brigada Ocho [b8] Productions
;call // rax
 
extrn printf:proc
extrn sprintf_s:proc
.code
main proc
sub rsp,28h
lea r8,[x]
lea rdx,[i]
lea rcx,[b]
call sprintf_s
mov r8, rax
lea rdx,[b]
lea rcx,[i]
call printf
add rsp,28h
ret
main endp
.data
x db 'Revelation 13'
........
........

full file attached..

enjoy..
7
Hello,

I just read about the new Intel Advanced Performance Extensions (Intel APX) that adds 16 more general purpose registers, new conditional move instructions, and other new features.  It requires support from the assembler.  16 more GP registers is extremely exciting, as are the other new features.  See https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

GNU Binutils, including gdb and ld, has already been updated to support it.  See https://sourceware.org/pipermail/binutils/2024-January/132213.html and https://www.phoronix.com/news/GNU-Binutils-2.42

Does NASM have plans to support it?   

Thanks very much.
8
The well-known Leibniz-formula to calculate "pi" with many iterations.
Surely, there are faster ways to calculate pi, and there may be the question WHY to calculate pi, but nevertheless...
We can practice here to deal with floating-point-numbers, and we see, how we can print floating-point-numbers (with help of the printf-routine of C.

Quote
; nasm -f elf64 calculatepi1.asm -o calculatepi1.o
; gcc -no-pie -m64 calculatepi1.o -o calculatepi1

; Leibniz says : pi/4 =1/1 - 1/3 + 1/5 - 1/7 + 1/9 - 1/11 + 1/13 .....


section .data
    var_oben  dq 1.0   ; Startwert Zaehler
    var_unten dq 1.0   ; Startwert Teiler
    var_0     dq 0.0   ; Null
    var_2     dq 2.0   ; Zwei
    var_minus1 dq -1.0  ; minus 1
    MSG_RESULT     db "pi = %0.18lf", 10, 0

section .text
   extern printf
    global main

main:
   push rbp
   mov rbp,rsp
    ; Set the number of iterations for the Leibniz formula
    mov rax, 200000

    movsd xmm2, qword [var_0]            ; xmm2 beginnt bei null und nimmt dann die Leibnizzahl als Viertel auf.

    ; Loop to calculate Pi using Leibniz formula
    leibniz_loop:
        ; Calculate next term
        movsd xmm0, qword [var_oben]
        movsd xmm1, qword [var_unten]
        divsd xmm0, xmm1
        addsd xmm2, xmm0               ; xmm2 hat das Viertel des Leibnizwertes!

        ; alternating sign
        movsd xmm3, qword[var_minus1]
        movsd xmm0, qword [var_oben]
        mulsd xmm0, xmm3
        movsd qword [var_oben], xmm0      

        ; Teiler zwei dazu...
        movsd xmm3, qword [var_unten]
        addsd xmm3, qword [var_2]
        movsd qword [var_unten], xmm3


        ; Decrement loop counter
        dec rax
        jnz leibniz_loop

    ; Multiply result by 4
 
   
    movsd xmm3, qword [var_2]
    mulsd xmm2, xmm3
    mulsd xmm2, xmm3
    movsd xmm0, xmm2


   mov      rdi, MSG_RESULT         ; set format for printf
   mov      rax,1         ; set one xmm registers
   call   printf         ; Call C function
   mov   rax,0            ; normal, no error, return value



   pop rbp
   
    mov rax, 60              ; System call number for sys_exit
    xor rdi, rdi             ; Exit code 0
    syscall


This is far from being optimized for speed or whatever.  It is written in a manner to understand easier what is going on.
9
Programming with NASM / Re: Things to do in _start
« Last post by fredericopissarra on March 09, 2024, 11:39:26 PM »
The reason why, no x86-64 mode, the stack usually is aligned to DQWORD (16 bytes) is because SSE. Since SSE/SSE2 is available to every x86-64 capable Intel/AMD microprocessor, floating point operations will use, by default, SSE/SSE2 and movaps instructions requires DQWORD alignment (otherwise you'll get an General Protection Fault).

So, yep, it is useful to keep the stack aligned by DQWORD.
10
Programming with NASM / Re: Things to do in _start
« Last post by decuser on March 09, 2024, 07:56:59 PM »
After thinking it through based on what you've said and seeing a lot of FUD type posts elsewhere about this topic, I have come to the conclusion that:

1. Stack alignment in Linux x64 programming is required by the API (to 16 byte addresses) if you are calling glibc functions (using main, linking with gcc) because the caller address is pushed onto the stack prior to the call and that address is 8 bytes causing the stack to be misaligned by 8 bytes, hence the push rbx (now it's realigned), mov rbx, rsp (save off the original sp), and sub rsp, -16 (realign).

2. It is probably a good idea to align the stack generally, if you plan to access items placed on the stack prior to your program start (such as ARGC and ARGV).

Otherwise, it's not ... required...

Does this sound reasonable?
Pages: [1] 2 3 ... 10