Confused about x86 64-bit conventions

[Tony]

I have read the information at the MSDN site on 64-bit software conventions, but
can't figure out what is Microsoft-specific, or VC++-specific, or Windows-
specific, vs. x64 in general. Here is the site link:

http://msdn.microsoft.com/en-us/library/tawsa7cb.aspx

In particular, passages like the following make me nervous:

"Every function that allocates stack space, calls other functions, saves
nonvolatile registers, or uses exception handling must have a prolog whose
address limits are described in the unwind data associated with the respective
function table entry (see Exception Handling (x64)). The prolog saves argument
registers in their home addresses if required, pushes nonvolatile registers on
the stack, allocates the fixed part of the stack for locals and temporaries, and
optionally establishes a frame pointer. The associated unwind data must describe
the action of the prolog and must provide the information necessary to undo the
effect of the prolog code."

I thought one of the things that was lucrative about assembly language is that
you can create your own calling conventions if you wanted to and not be limited
to cdecl, stdcall, and the like.

I was feeling all warm and fuzzy having developed some facility this past year
in using assembly language and then I read that! Argh! Can I still write
assembly language code pretty much like I am able to on x32, on x64? Is all the
crap about unwinding and such only if I am developing a program which includes
SEH or linked with C++ object code which used it? Am I to believe from the above
that ALL x64 code must implement all that unwind machinery and such?

On another site, I found a threaded discussion on table-based vs. frame-based
exception handling, and they seemed to be discussing it like that's the way
assembly language software is now built, rather than being a choice on the
Windows platform.

Finally, I have read some assembler documentation (NASM or YASM, I forgot which)
and they have the ability in that assembler to generate table-based EH data,
etc.

All the above have me worried that I'm becoming locked-out of the x64 platform
or even "just" the important Windows environment. Can someone begin to clear
this all up for me? I'll have more questions for sure.

[Harold]

"Tony" <a...@some.org> wrote in message
news:MPG.2bdaa6a2d...@nntp.aioe.org...

You can ignore it completely. Things will get a little confused when there
is an exception (if you try to look at the stack at the point of the
exception, it will looks all weird and nonsensical), but you can choose not
to care about that. The rest of the program can still use SEH.
You can mostly ignore it but still technically conform: pretend the entire
program is one function. That costs a register to be the "frame pointer to
the first frame", and it's weird. But it does unwind without trouble (it
unwinds to a useless place, but it won't result in the "wtfstack").
You can make it unwind without conforming to the calling conventions: the
unwinding data is more flexible than the calling conventions - not a lot,
but still. In particular, the prolog and epilog don't need to be of the
specified form, as long as their effect is something you can describe with
unwinding data.
Or you can play by the rules. That wouldn't mean you'd be "locked-out", just
that you're following some rules.

[Robert Wessel]

On Fri, 19 Apr 2013 01:56:56 -0500, Tony <a...@some.org> wrote:

>
>I have read the information at the MSDN site on 64-bit software conventions, but
>can't figure out what is Microsoft-specific, or VC++-specific, or Windows-
>specific, vs. x64 in general. Here is the site link:

It's all MS/Windows specific. MSVC uses the standard ABI rules for
the platform its running on, the link you provided is the one for
x86-64.

You can ignore it completely so long as: you don't mess up the stack
frame on the way back out, you don't *throw* exceptions from your
assembler code, you don't *call* C/C++ (or whatever) code from your
assembler code that might throw an exception, you don't expect to be
able to catch exceptions in your code, and you don't mind that the
debugger might be confused by non-standard stack frames.

Basically the same rules apply in x86-32 code (although the details of
how to support exception handling are completely different).