Re: x86-64 and calling conventions

"Dave Parker" <daveparker@flamingthunder.com> wrote in message
> On May 11, 5:44 pm, "cr88192" <cr88...@hotmail.com> wrote:
>> now, what kind of convention would I be imagining:
>> well, basically, it would be a hybrid of the existing conventions, and
>> the
>> good old 32-bit x86 convention.
>>
>> in particular, arguments would be passed on the stack (in good old linear
>> right-to-left ordering).
>
> That's kind of what I did in the Flaming Thunder compiler (which
> supports the x86 and x86-64 versions of FreeBSD, Linux, Mac OS X and
> Windows).
>
> Some differences:
>
> The calling convention is left-to-right (since I was making my own
> calling convention, I figured I might as well fix the old right-to-
> left holdover and use the stack the way the stack should be used ---
> left-to-right). Left-to-right means the arguments are evaluated in
> the order that users expect them to be. If the function is vararg,
> then I push the argument count on the stack last.
>
> When I need to access a system service, I translate my stack layout to
> the Windows/Mac/Linux/FreeBSD/32/64 layout, then call the system.


yes, though possible, there is a biggie issue with this: it would be
rather painful in the case of mixed-compiler codebases.


Also, in my case for the time being I am limited to right-to-left
ordering, since that is what I am getting out of the upper compiler
(for x86, I more or less layed out all of the logic in a fixed
ordering, namely that of execution on x86, however this ordering does
not work so well for x86-64...).


Recently, I had started beating together code for internally using
SSA, but this does not look like it will be so easy. SSA seems, rather
awkward... a big issue is that one ends up with a graph, and rather
than being driven either imperatively, or simply by unwinding a tree,
requires (as it was turning out in my case at least) identifying
top-level expressions and stepping along the graph doing register
allocation and such.


Just as of writing this, I have had an interesting idea: it could be
possible to abandon my current RPN based representation, and
reimplement a lot of the machinery from the RPNIL compiler into a
modified form of the existing upper compiler.


The result would be replacing the big mass of fixed-form code
(basically, a structure driven purely by a central switch statement
and a big mass of function calls), with likely a much bigger mass of
XML processing (the current upper compiler being structured around
processing DOM trees).


This would likely imply adding another XML-based stage (likely,
working out all of the type mechanics, ...), the output of which would
then be converted directly to SSA.


A slight modification of this idea would be to use the DOM trees to
directly drive the low-level code generation (XML could likely serve a
similar role to what I am imagining with SSA, albeit there is little
to stop SSA from being represented is XML as well). in this case,
register allocation and codegen would be driven directly by the
process of flattening out these trees.


Never Mind that all this would imply discarding and rewriting almost
everything located between the parser and the low level code
generation (even as such, it could be less work than SSA+reworking the
RPN compiler to target SSA).


Another possible advantage is that, for the implied notable loss of
abstraction, it could make the whole compiler core a lot more open and
flexible (thus easing the addition of new features and possible non-C
languages).


In all this, pretty much everything above low-level code generation,
would become a big mass of transforms applied to globs of XML (I will
just have to deal some with the awkwardness and verbosity of XML
processing... XSLT almost looks tempting...).


possible layout:
parser (intact);
expression reduction, inlining, ... (heavily modified);
expression type propagation and decomposition (new);
tree flattening, register allocation (new, directly-drives next down);
low-level code generation (intact);
assembler, ...






more in general:


I tend to use my compiler right along with gcc, using gcc more as a
static compiler, and mine more as a dynamic compiler.


reasons:
though some code is likely to be highly volatile, other code is likely to be
mostly static;
compiling C code, especially large amounts of it, also tends not to be a
super fast process (sadly, my compiler is not the fastest option WRT
compiling speed...);
likewise, though there are many cases where my compiler does well, at
present gcc generally does better (in terms of general performance and
non-buggy output).


Thus It Is Effective To Compile Parts Of The App Statically, And Other
Parts Dynamically. some parts are linked into the executable, and
other parts are static libraries (however, at present, the entire
library tends to be linked in, wheras later it may be better to
demand-link missing symbols).


Later plans may involve caching and demand compilation (we have the
source, and automatically recompile those parts that have changed).


or such...

Return to the comp.compilers page.
Search the comp.compilers archives again.