Re: [9fans] Plan9 Calling Convention (x86)

Re: [9fans] Plan9 Calling Convention (x86)

[Tassilo Philipp]

Thanks a ton, you are my hero!

Thanks,
Tassilo



> caller saves, so function is free to use any register.  params are put
> on the stack and then just uses a call instruction wich leaves the
> return pc on the stack.  function allocates space for its local
> variables on the stack and restores SP before return.  return value of
> a function is put in AX (for integers and pointers).  structures and
> 64bit vlongs are returned the way that the caller allocates it and
> passes a pointer to it as the first parameter (on the stack).  AX is
> then not used as return value and can be used freely in the callee.
>
> --
> cinap
>

Re: [9fans] Plan9 Calling Convention (x86)

[Steve Simon]

information on the compiler's implementation here:

http://plan9.bell-labs.com/sys/doc/compiler.pdf

-Steve

Re: [9fans] Plan9 Calling Convention (x86)

[Tassilo Philipp]

>> ...snip...
>> assumption might be wrong (maybe I didn't get how Plan9 works on the
>> machine-level, so far).
>
> I hope you don't mind me asking, but what do the prologue and epilogue
> normally do? With only a basic knowledge of C and assembler, I can't
> imagine what they might be for. Are they anything to do with dynamic
> linking?

Well, depending on the calling convention, processor, platform, etc. they
are usually used to setup the stack and the processor registers for use in
the function itself, and before returning, to restore it for the parent
function.
E.g. setting the stack pointer to a new address used by the called
function and before returning resetting it to the prior address, and so
on.

They can be written in many ways, as long as the stack is used accordingly
inside of the call.


>> I'm still new to Plan9, but it's quite mind-opening to discover
>> certain
>> aspects of the OS - especially after getting so (too) used to Unix/
>> Windows
>> OS design decisions and accepting them as the normal/right way to do
>> things...
>
> Oh tell me about it, I'm finding ...

Well, pretty much all communication being based on a protocol (9P) is the
way to go, instead of having to deal with hundreds of different APIs as
found in current systems, to handle things. Based on that, /net is
awesome, and after having discovered it, it just feels weird now that I
have to deal with another big bunch of different systems on mainstream
operating systems to implement things like NAT, VPN, or to simply hook up
file servers ... not to mention CPU servers, hehe...

Or let alone the fact, that UTF-8 is in the base - how much time got
wasted on other systems to implement decent localization, and well, we
still deal with encoding issues on a daily basis... ;)

What else...? Better portability right from the beginning, getting rid of
C preprocessor features that always got overused, etc.. on the flipside,
it makes it harder to port POSIX code to Plan9, though :/

There are so many great ideas, it's overwhelming - it's sometimes not easy
to find decent documentation, though.

Cheers

Re: [9fans] Plan9 Calling Convention (x86)

[cinap_lenrek]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

caller saves, so function is free to use any register.  params are put
on the stack and then just uses a call instruction wich leaves the
return pc on the stack.  function allocates space for its local
variables on the stack and restores SP before return.  return value of
a function is put in AX (for integers and pointers).  structures and
64bit vlongs are returned the way that the caller allocates it and
passes a pointer to it as the first parameter (on the stack).  AX is
then not used as return value and can be used freely in the callee.

--
cinap

[-- Attachment #2: Type: message/rfc822, Size: 3841 bytes --]

From: "Tassilo Philipp" <tphilipp@potion-studios.com>
To: 9fans@9fans.net
Subject: [9fans] Plan9 Calling Convention (x86)
Date: Mon, 26 Jul 2010 21:27:10 +0200
Message-ID: <899e1dd0ffcee329db7dc0b8faf0b201-EhVcXl1ERwBcRx0AAAwEUR8fGQlVS19cWF9EAV1EWEZaOl4PQVh/H1dXXkFeRExtXlhRQFlSWgxcXw==-webmailer2@server01.webmailer.hosteurope.de>

Hi,

I'm in the process of porting dyncall (http://dyncall.org) to Plan9, and I
was wondering if there are any documents about the calling convention used
by Plan9 - specifically for x86, for starters. I was unable to find any at
the time of writing, and well, hoped that it would be similar to the
SystemV calling convention(s) used by the *BSDs or Linux, etc., but that
doesn't seem to be the case.
The only information I found so far, is, that most of the compiled Plan9
functions don't seem to have any prologue/epilogue, however, this
assumption might be wrong (maybe I didn't get how Plan9 works on the
machine-level, so far).

I'm still new to Plan9, but it's quite mind-opening to discover certain
aspects of the OS - especially after getting so (too) used to Unix/Windows
OS design decisions and accepting them as the normal/right way to do
things...

Thanks,
Tassilo

Re: [9fans] Plan9 Calling Convention (x86)

[Ethan Grammatikidis]

On 26 Jul 2010, at 9:05, Ethan Grammatikidis wrote:

>
> On 26 Jul 2010, at 8:27, Tassilo Philipp wrote:
>
>>
>> I'm still new to Plan9, but it's quite mind-opening to discover
>> certain
>> aspects of the OS - especially after getting so (too) used to Unix/
>> Windows
>> OS design decisions and accepting them as the normal/right way to do
>> things...
>
> Oh tell me about it, I'm finding

Oy, I'm scatty tonight. Anyway, I was saying all sorts of things in
Plan 9, from deep system concepts to the window system and editors
mind-stretching.

>
>>
>> Thanks,
>> Tassilo
>>
>>
>
>

Re: [9fans] Plan9 Calling Convention (x86)

[Ethan Grammatikidis]

On 26 Jul 2010, at 8:27, Tassilo Philipp wrote:

> Hi,
>
> I'm in the process of porting dyncall (http://dyncall.org) to Plan9,
> and I
> was wondering if there are any documents about the calling
> convention used
> by Plan9 - specifically for x86, for starters. I was unable to find
> any at
> the time of writing, and well, hoped that it would be similar to the
> SystemV calling convention(s) used by the *BSDs or Linux, etc., but
> that
> doesn't seem to be the case.
> The only information I found so far, is, that most of the compiled
> Plan9
> functions don't seem to have any prologue/epilogue, however, this
> assumption might be wrong (maybe I didn't get how Plan9 works on the
> machine-level, so far).

I hope you don't mind me asking, but what do the prologue and epilogue
normally do? With only a basic knowledge of C and assembler, I can't
imagine what they might be for. Are they anything to do with dynamic
linking?

>
> I'm still new to Plan9, but it's quite mind-opening to discover
> certain
> aspects of the OS - especially after getting so (too) used to Unix/
> Windows
> OS design decisions and accepting them as the normal/right way to do
> things...

Oh tell me about it, I'm finding

>
> Thanks,
> Tassilo
>
>

[9fans] Plan9 Calling Convention (x86)

[Tassilo Philipp]

Hi,

I'm in the process of porting dyncall (http://dyncall.org) to Plan9, and I
was wondering if there are any documents about the calling convention used
by Plan9 - specifically for x86, for starters. I was unable to find any at
the time of writing, and well, hoped that it would be similar to the
SystemV calling convention(s) used by the *BSDs or Linux, etc., but that
doesn't seem to be the case.
The only information I found so far, is, that most of the compiled Plan9
functions don't seem to have any prologue/epilogue, however, this
assumption might be wrong (maybe I didn't get how Plan9 works on the
machine-level, so far).

I'm still new to Plan9, but it's quite mind-opening to discover certain
aspects of the OS - especially after getting so (too) used to Unix/Windows
OS design decisions and accepting them as the normal/right way to do
things...

Thanks,
Tassilo