Recent Posts

Pages: [1] 2 3 ... 10
1
Programming with NASM / Re: Shift stack pointer
« Last post by ig on August 10, 2020, 08:00:35 AM »
We're talking about Windows x64 platform here - so no, those RSP manipulations are not intended for SEH (SEH in x64 uses fixed tables and doesn't involve any instructions whatsoever to set up in the actual code).

The x64 calling convention says that you need to allocate a "shadow space" (20h bytes) before calling any function, see e.g. here:
https://retroscience.net/x64-assembly.html#fast-call-procedure-shadow-space-home-space
So that's what that sub rsp, 20h is about.

There is also a requirement for stack alignment - before calling any function, rsp has to be a multiple of 10h. However, that "and" instruction is most likely incorrect - especially if the original value of rsp wasn't stored anywhere, because after the "and" instruction you wouldn't be able to restore it back to the original value. Usually, since you already know the alignment in the current function (from the alignment requirement), you know if you need to subtract 8 bytes or not (to achieve the correct alignment for the called function), so the alignment is rarely done via "and".

As for the second question - in this particular case, it seems to me that the "pop eax" instruction is only used to fix the stack (i.e. to act as a counterpart of that "push r9") - so it should be possible to do only "add rsp, 48h", instead of "add rsp,40h" (and no pop).
2
Programming with NASM / Re: Shift stack pointer
« Last post by fredericopissarra on August 08, 2020, 12:54:06 PM »
You don't need to play with the stack to build a simple "hello, world" in ASM for Win64:
Code: [Select]
; Win64 hello.asm
;
; Compiling using NASM and minw64 (linux).
;
;   $ nasm -fwin64 -o hello.o hello.asm
;   $ x86_64-w64-mingw32-ld -s -e _start -o hello.exe hello.o \
;       -L /lib/x86_64-w64-mingw32/ -l:libkernel32.a
;

  bits 64
  default rel

STD_OUTPUT_HANDLE equ -11

  section .rodata

msg:  db  `hello\r\n`
msg_len equ $ - msg

  section .text

; Imported from libkernel32.a
extern __imp_GetStdHandle
extern __imp_WriteConsoleA
extern __imp_ExitProcess

; Entry point
  global _start
_start:
  mov   ecx,STD_OUTPUT_HANDLE
  call  qword [__imp_GetStdHandle]

  mov   rcx,rax
  lea   rdx,[msg]
  mov   r8d,msg_len
  xor   r9d,r9d
  push  r9                          ; 5th argument goes to stack.
  call  qword [__imp_WriteConsoleA] ; WriteConsoleA will cleanup the stack for you!

  xor   ecx,ecx
  jmp   qword [__imp_ExitProcess]
Those RSP manipulations are intended for SEH (Structured Exception Handling).
The first AND RSP,-10, and I suspect this is wrong, is intended to align RSP (but it is already aligned by the loader).
3
Programming with NASM / Shift stack pointer
« Last post by lostsky25 on August 07, 2020, 08:19:22 PM »
I have this code:
Code: [Select]
default REL
extern GetStdHandle
extern WriteFile
extern ExitProcess

section .data
true_msg db 'Yes', 0

true_msg_len equ $-true_msg

section .text
global _main

print_yes:
and rsp, -10h
sub rsp, 020h

mov rcx, -0Bh
call GetStdHandle

mov rcx, rax
mov rdx, true_msg
mov r8, true_msg_len
xor r9, r9
push r9
sub rsp, 20h
call WriteFile
add rsp, 40h
pop rax
    ret ;// essentially identical to: pop [register] -> jmp [register]

_main:
mov rcx, 2
cmp rcx, 2
jne false1

call print_yes

false1:

mov rcx, 0 ; RCX - first argument.
call ExitProcess

xor rax, rax
ret


Why I must do something like this:
Code: [Select]
and rsp, -10h
sub rsp, 020h
Thereafter, I can call 'GetStdHandle', then I want to use 'WriteFile' and I must do this:
Code: [Select]
sub rsp, 20h
1) Why? How can I find this value for other functions?

Also, I must write this:
Code: [Select]
add rsp, 40h
pop rax
    ret
In the first, I restore the original state of the stack pointer. In the second, 'pop rax' register. If I don't do this, my program will end. RIP will be zero?

2) I always 'pop rax' in other labels/functions?
4
Other Discussion / Re: Hello everyone, new member!
« Last post by skiters on August 03, 2020, 08:18:14 AM »
Holy smokes I stumbled on this site yesterday looking for a MASM alternative.




You guys are sick, this looks amazing.
From the manual:

So here, for your coding pleasure, is NASM.

No kidding haha, I look forward to playing with this. Many ideas in mind.
Thank you!

nice one!
5
Programming with NASM / Re: Print char to stdout
« Last post by Frank Kotler on July 12, 2020, 12:15:05 AM »
Hi Ben,

The last I wrote for Windows was for win98, but this is for Linux. The "int 80h" might have been a clue, but I should have specified.

Hope you are well. Be careful, but not fearful... everybody!

Best,
Frank

6
Programming with NASM / Re: Print char to stdout
« Last post by ben321 on July 11, 2020, 11:11:46 AM »
Not only does it not print to the console, it actually crashes. Running it in the debugger OllyDbg, I see it's getting the error "Access violation when reading (FFFFFFFF)". It would seem this may be part of Windows's protection system, blocking kernel-mode code from executing in user-mode programs. What was the target operating system here? Were you planning to use it in Windows 98 or something? It certainly is not working on Windows 10.
7
I think I am going to switch to mode 11h. It does not appear to be interlaced and appears to be a conventional size of 640x480.
640x200 seems a bit odd.

My question has been answered. The behavior I was experiencing was a mixture of the wrong size and interlacing.

I am marking the thread as solved.
EDIT:
There does not appear to be a way to mark a thread as solved. If I can't figure out how maybe I shouldn't be programming.  :D
8
Other Discussion / Re: Am I using the Graphics Buffer correctly?
« Last post by Johnpaul Humphrey on July 08, 2020, 03:34:53 PM »
Thanks for the help so far!
I will try to implement that, and if I come up with some cool macro, I will post it.
I think this solves my problem.
I
9
Other Discussion / Re: Am I using the Graphics Buffer correctly?
« Last post by ShaiHulud on July 07, 2020, 08:57:54 PM »
mode 13h comes recommended. If I just want/need monochrome, does a monochrome mode have any advantages, or are they primarily historical?

the first machine I played with was an IBM model PS2 (think Macintosh, monitor/motherboard/drives molded into one case, but with an 8086 and a hard drive, definitely not as pretty ;) ) which came with MCGA, that supported the monochrome and CGA modes (320x200 4 color), and the 320x200 256 color mode. Most other video chips of the time were EGA, which also supported the mono, cga and 16 color hires modes, but not the 256 color modes. Soon vga chips came after supporting the 256 color modes, then VESA kicked in and supervga cards started appearing. A lot of the machines of the time used the hires monochrome modes for word processing (google WordPerfect), CAD, paint software. It was rare for games to use the monochrome modes. I can think of only one I ever played that used it, the first SimCity. When 286 started hitting the market, a version of Geos (like the commodore 64 one!) was made, and truly used the protected mode on that chip, almost a proper multitasking system (i say almost...its hard to multitask anything decently at 25mhz). It ran in hires monochrome as well, and did a windowed gui much like macintosh or c64 geos. I only remember it because it had one of the best printing apps of the time, it made spectacular printouts with just a dot matrix printer ;)

A common trick that was used a lot for video routines: lookup tables. make an array of offsets into video memory, one entry per scanline for each row. Use the lookup to speed things up some in your loop, and you wont have to split your code up for the interlacing. if you're clever enough, you could make a macro that preinitializes it for you at compile time. And if i remember correctly, at 640x200, thats only 16k of memory...you should have enough video ram to do page flipping, aka double buffers. If you can manage to tweak the video regs, you could do some realtime stuff
10
Other Discussion / Re: Am I using the Graphics Buffer correctly?
« Last post by Johnpaul Humphrey on July 07, 2020, 06:23:54 PM »
I see what interlacing is. that would explain why my pixels were rectangular. They were double stacked. That means the behavior I observed was normal.
Eventually, I want to map a font on the screen. interlaced means more code, I think.
If I had a sprite stored at say 0xA000 That was 8 rows tall the fastest way I could think of mapping it would be, (assuming a BIT a character and an 8x8)
Code: [Select]
mov ebx, 0b8000h ;RBIL says B800, but B8000 seems to be correct.
mov si, 0xA000
mov cx, 4
halfA:
lodsb
mov byte [ebx], al
lodsb   ;skip row for interlacing
add ebx, 1
loop halfA
mov si, 0xA001
mov ebx, 0bcb00h ;half way if my calcs are correct.

halfB:
lodsb
mov byte [ebx], al
lodsb   ;skip row for interlacing
add ebx, 1
loop halfB

mode 13h comes recommended. If I just want/need monochrome, does a monochrome mode have any advantages, or are they primarily historical?
Pages: [1] 2 3 ... 10