Re: thin linking: "file is not of required architecture"
Re: thin linking: "file is not of required architecture"
- Subject: Re: thin linking: "file is not of required architecture"
- From: Steve Checkoway <email@hidden>
- Date: Tue, 22 Apr 2008 14:49:42 -0700
This has strayed far afield from the topic, but some notes on your
reactions follow.
Philip Hölzenspies wrote:
I didn't actually say "bsd *calling* conventions," but pointed out that
we use BSD conventions to clarify why we use .so files. I just wanted to
get rid of the dylib discussion which was, in my opinion, irrelevant to
the question I was asking.
Ah, but you did say ANSI-C calling conventions, which to the best of my
knowledge does not exist.
Simon has already pointed out that there are indeed things like a Pascal
and a C calling convention, both of which have little to do with the
architecture (they're defined in an architecture independent manner, but
will have some different implications for different architectures, e.g.
the language conventions state whether the caller or the callee is
responsible for saving the contents of some registers; which registers
are actually preserved "through" a call is determined - to my knowledge
- by the architecture's calling convention).
I took a quick glance through the Pascal standard and saw nothing
mentioning a stack or calling conventions or parameter clean up
<http://www.moorecad.com/standardpascal/iso7185.html>. I'm almost
positive that the C standard also says nothing about those as well.
I'm unaware of any portable, high-level language that says anything at
all about caller or callee saved registers or even talks about registers
at all (C's register keyword notwithstanding). The fact that the people
who implemented the Pascal compilers went against the hardware's stated
conventions seems wrong to me. (It also hurts interoperability as the
previous comments about __stdcall and __cdecl demonstrate.)
--
Steve Checkoway
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden