Re: back online again...


"Rod Pemberton" <do_not_have@xxxxxxxxxxxxx> wrote in message
news:gk21bk$lo0$1@xxxxxxxxxxxxxxxxxxxxx

"cr88192" <cr88192@xxxxxxxxxxx> wrote in message
news:gk0vho$24m$1@xxxxxxxxxxxxxxxxxxxxx

yeah, but the problem then is that one has to know that the function is
not
just defined in some other module with this calling convention, and could
not just be called directly.

Do it the way others compilers do. Let the programmer label it.


I may do this eventually, but the great problem is that I am using masses of
pre-existing headers, which are, sadly, not labeled...

so, this would force either a long and tedious process of labeling every
declaration in every header, or leaving SysV as the default (and thus only
really "acceptable") convention.

so, in this particular case, labeling is not a very usable option...


MS and Linux use different 64-bit calling conventions, so you may have
need
to support more than just SysV in the future. A quick glance it seems the
AMD64 ABI, and MS x64 are similar in nature (similar registers,
integers/pointers in regs, floats/doubles in xmmx), but the AMD64 uses
twice
as many registers. How easy or difficult is it to convert MS x64 ABI to
AMD64 ABI? It looks like that is a bit of work... (additional post to
follow).

Some links:

Wikipedia CC
http://en.wikipedia.org/wiki/X86_calling_conventions

MS x64
http://msdn.microsoft.com/en-us/library/ms235286.aspx

AMD64 ABI
http://www.x86-64.org/documentation/abi.pdf

Raymond Chen on calling conventions
http://blogs.msdn.com/oldnewthing/search.aspx?q=The+history+of+calling+conventions&p=1

Sun on AMD64 ABI memory models etc.
http://developers.sun.com/solaris/articles/about_amd64_abi.html
http://developers.sun.com/solaris/articles/mmodel.html



the differences are in the details.

so, rather than considering which registers are used, consider this:
how things are laid out on the stack;
the relation between particular registers and arguments.

at this point, there is a big difference between the conventions...


and, there is another important difference:
the Win64 is designed in such a way that it could be targetted by a linear
stack machine (similar to, for example, cdecl and stdcall), but the design
of SysV is not really compatible with a linear stack model (it would require
a graph model and the ability to reorganize code, for example, to eliminate
there being any nested function calls, ...).


my custom "xcall" convention is designed in such a way that it is easier to
target with my compiler (may need a different name for this though, as the
name does clash with something).

in general, I designed it as a tradeoff between Win64, SysV, and something I
could actually get implemented...



linker ... automatically generate a stub to allow calling the
native function using the native convention

AH! You want a method to select between the "custom calling
convention"
for
internal C functions and the SysV calling convention for external C
functions. And, you're trying to determine a method to know which is
which
so the arguments and returns are properly setup for a different calling
convention when linked. Okay, your second post makes sense now... :)
Interesting... IIRC, I worked on a system where they needed to place
wrappers around a larger number of OS system functions. What they did
was
have the compiler captilize the names of the system functions. They
were
all external. Then, the linker linked to the wrapper library function
if
the function name was uppercase instead of the original OS library
functions, which it'd link to if it was lowercase. The wrapper did
some
stuff, called the original function, did some more stuff, then exited,
much
like a prolog and epilog.


yes

Do objects for your code also use a different object format? Could you
use
different object file formats? SysV in one format, custom in another?
Are
there some additional flags in the object format(s) you're using that
could
help?


most of this code is not likely to ever go to object files anyways...

but, what code does go into object files, will probably go into COFF files
(this would be the path of least effort...).

if really needed, I could mark the COFF files somehow.


thus far I have most of the 64-bit compiler logic written, and am still
beating at some of the issues. I just recently got the stack alignment
issues dealt with, but this required a number of tweaks to the compiler
logic, such as making every stack item in the compiler also carry its offset
with it so that it is possible to fudge with the alignment of items on the
stack without needing to add dummy items or similar.

so, now it is the case that often when popping and item, the stack will
re-align with the end of the last item, and when pushing items with certain
alignment requirements (such as SSE vectors), then the stack can be easily
aligned as needed.

if taken further, this could also allow items with smaller sizes as well
(such as ints and floats) which would then pack together nicely on the stack
(much like in a struct). but, this would much further complicate
everything...

note that item alignment does not counteract the ability to process things
linearly...


(it doesn't help that much that I don't that much trust my compiler logic,
it is all an ugly mess...).



Rod Pemberton





.

Relevant Pages

  • Re: x86-64 and calling conventions
    ... good old 32-bit x86 convention. ... arguments would be passed on the stack (in good old linear ... That's kind of what I did in the Flaming Thunder compiler (which ... The calling convention is left-to-right (since I was making my own ...
    (comp.compilers)
  • Re: Unused stack space
    ... > In a C module that I have compiled, it seems to generate object files ... > which waste stack space. ... This depends of the compiler, and mostly of the required optimisation ... replaced printf with puts) ...
    (comp.os.linux.development.apps)
  • Re: A Few Questions
    ... > subprograms and the stack) of Dr. Paul Carter's PC Assembly Language. ... > defined in and are stored in the data or bss segment. ... The compiler has 'scoping' rules that it ... > the convention but it would still work? ...
    (comp.lang.asm.x86)
  • Re: passing arguments to a function
    ... When i observed the stack, ... To be "standard" within the compiler. ... any order you wish as long as the receiving function knows ... the ARM Project Manager's calling convention ...
    (comp.lang.c)
  • Re: Function arguments
    ... The default calling convention for C is _cdecl. ... needs to clean up the stack. ... _stdcall is used for Win32 API functions. ... > arguments stored in stack always or it compiler specific and could be ...
    (comp.lang.c)