;        align   16
__chkstk_ms:
        push    rcx
        push    rax
        cmp     rax, PAGE_SIZE
        lea     rcx, [rsp + 24]
        jb      ._LessThanAPage
._MoreThanAPage:
        sub     rcx, PAGE_SIZE
        or      byte[rcx], 0
        sub     rax, PAGE_SIZE
        cmp     rax, PAGE_SIZE
        ja      ._MoreThanAPage
._LessThanAPage:
        sub     rcx, rax
        or      byte[rcx], 0
        pop     rax
        pop     rcx
        ret    

or byte[rsp-?], 0
or byte[rsp-??], 0    

macro _chkstk_ms stackpointer, size {
...
}    

        repeat (size + STACK_PAGE_SIZE - 1) / STACK_PAGE_SIZE
                cmp     byte[esp - % * STACK_PAGE_SIZE],al
        end repeat
        if size < STACK_PAGE_SIZE
                cmp     byte[esp - size],al
        end if    

; use this macro if you are too lazy to touch beforehand the required amount of stack
;  for functions that need more than 4K of stack space
; here we assume that the current stack pointer is in the committed range
; if size > 4096, [rsp-size] might be past the guard page
;  so touch the pages up to it
STACK_PAGE_SIZE = 4096
macro _chkstk_ms stackptr, size {
        repeat (size+8) / STACK_PAGE_SIZE
                cmp   al, byte[stackptr - % * STACK_PAGE_SIZE]
        end repeat
}
    

Code:

... we assume that the current stack pointer is in the commited range    

For the record I just want to add that stack touching at the procedure entry is a terrible idea. Much better to expand the stack once at startup and don't waste time touching a stack that already exists every time a function is subsequently called

use this macro if you are too lazy to touch beforehand the required amount of stack

I assume you actually mean the reserved range

__allocstk:
        sub rsp,rax
        assert bsr PAGE_SIZE = bsf PAGE_SIZE
        and rax,-PAGE_SIZE
        jz .return
.next_page:
        cmp [rsp+rax],edx     ;3 bytes only, avoids any kinds of partial register access stall
        sub rax,PAGE_SIZE
        jae  .next_page
.return:
        ret    

macro m_allocstk stackptr, size
{
    if size relativeto 0
    ;statically sized stack frame
        sub rsp,size
        repeat size / STACK_PAGE_SIZE
            mov byte[rsp + size / STACK_PAGE_SIZE - % * STACK_PAGE_SIZE]
        end repeat
    else
    ;dynamically sized stack frame
        if ~ size eq rax
            mov rax,size
        end if
        call __allocstk
    else
}    

There are many other ways in which the function is suboptimal

__allocstk:
        pop r10
        sub rsp,rax
        assert bsr PAGE_SIZE = bsf PAGE_SIZE
        and rax,-PAGE_SIZE
        jz .return
.next_page:
        cmp [rsp+rax],edx     ;3 bytes only, avoids any kinds of partial register access stall
        sub rax, PAGE_SIZE
        ja .next_page
.return:
        push r10
        ret    

macro m_allocstk size*
{
    local sz,off,..next_page
    if 0 relativeto size
        ;statically sized stack frame
        sz = ((size)+7) and (-8)
        assert bsr PAGE_SIZE = bsf PAGE_SIZE
        off = sz and (-PAGE_SIZE)
        if off < PAGE_SIZE*3 & ~sz = PAGE_SIZE*2
            sub rsp,sz
            times off/PAGE_SIZE+1 : cmp [rsp + off - (%-1)*PAGE_SIZE],edx
        else
            mov rax,off
            if sz = off
                sub rsp,rax
            else
                sub rsp,sz
            end if
            ..next_page:
                cmp [rsp+rax],edx
                sub rax,PAGE_SIZE
            jae ..next_page
        end if
    else
        ;dynamically sized stack frame
        if ~ rax eq size
            mov rax,size
        end if
        call __allocstk
    end if
}    

I actually expected tthsqe to disagree, because revolution's suggestion makes absolutely no sense (to me). Stack probing must be done at the procedure entry only, because in most cases the stack frame address at function execution time is not known beforehand. Moreover in most cases it's not even known, whether that specific stack-greedy function is gonna be called at all, and therefore the suggestion contradicts revolution's own point here. And even for stack locations known for sure to be used at runtime (guaranteed minimal stack consumption) preliminary stack probing makes no sense as well, because in this case one just needs to specify SizeOfStackCommit correctly and omit stack probing completely.

revolution wrote:

I assume you actually mean the reserved range

No, he actually correctly means commited range. Because only in this case following stack probing is guaranteed to not miss the guard page.

If you can't predict how much stack it will use then you can't guarantee that the touching will not fall outside the reserved range.

I don't think your link is not relevant

If it is already committed then there is no need to touch it

And if it is reserved then you'll be fine committing new pages with touching as long as you don't fall outside the reserved range.

tthsqe wrote:

Code:

... we assume that the current stack pointer is in the commited range    

I assume you actually mean the reserved range.

Yes - the names are confusing for me. I mean that accessing [rsp] will not cause a page fault (and is not the guard page)