Recent Posts1
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).
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).
) 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