__stdcall alternative

[Ian Collins]

Re: __stdcall alternative

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>Ian Collins wrote:

>>

>>>so it must be platform specific,
>>no, it isn't
>>>

>Eric's already shown you that is is.
>>

>
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you
>

Which are specific platforms, so?

what piss me off of this regulars is that when proved wrong
they insist
>

On what?

--
Ian Collins.

[jacob navia]

Re: __stdcall alternative

Ian Collins wrote:

Fool,

Well, You are a genius...

if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
>

You were attempting to help the original poster by
showing your ignorance.

Yes of course it helps him when you say you do not know the
subject matter.

Obviously, this proves that you are a genius.

>>It's not C,

>Of course it is. It is a common extension.
>>

Not on any platform I use, and that's quite a few.
>

Who cares?

It is supported by gcc and all the platforms gcc runs on,
supported by MSVC, supported by Watcom, Borland, lcc-win,
and what have you.

That is almost 100% of the market. Obviously you use
something else and never look into mainstream computing like
many regulars here.

Ignorance is a bliss!

I told you, you are a genius.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard Tobin]

Re: __stdcall alternative

In article <fuqtqi$dg2$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>If you use gcc you should

That sounds a bit platform-specific! But luckily I do use gcc.

>#ifndef STDCALL
>#define STDCALL __attribute__(( stdcall))
>#endif

I get:

foo.c:5: warning: 'stdcall' attribute directive ignored

Presumably this is an x86-only declaration.

-- Richard
--
:wq

[Bartc]

Re: __stdcall alternative

"jacob navia" <jacob@nospam.c omwrote in message
news:fuqs6p$7r2 $1@aioe.org...

Bartc wrote:

>But, __stdcall seems to assume that machine registers are saved by the
>called routine (as far as I can gather after a few hours messing with
>some strange behaviours especially with optimised C code).
>>

>
OBVIOUSLY you should save the registers ytour compiler thinks are
permanent
>
Under windows (where stdcall is commonly used) you should save
(I am assuming 64 bit CPU)
>
rsi
rdi
rbx
r12-r15
rbp

OK, for x86-32 then I have to worry about esi,edi,ebx.

you could just as well use the C calling convention. The registers to save
are THE SAME

The ASM is emitted by a compiler of mine from years back; I'm not going to
change it! I'll just stick in some bits of inline asm for now.

This is just a temporary measure until my project is 100% C. Or it will have
some ASM calling C which is a bit easier.

but you should just issue ret
and the called procedure adjusts the stack.

(That always seemed a crazy way to do things; one extra instruction /per
call/).

--
Bart

[Keith Thompson]

Re: __stdcall alternative

jacob navia <jacob@nospam.c omwrites:

Keith Thompson wrote:

>jacob navia <jacob@nospam.c omwrites:

>>Keith Thompson wrote:
>>>jacob navia <jacob@nospam.c omwrites:
>>>>Ian Collins wrote:
>>>>>Bartc wrote:
>>>>>>I'm mixing C and ASM, and for calling ASM from C, I just happened
>>>>>>to use the __stdcall convention (using C convention is not
>>>>>>practic al for other reasons).
>>>>>>>
>>>>>What is __stdcall?
>>>>What's the point of showing your ignorance as it was a quality?
>>>>>
>>>>You do not know the subject matter?
>>>>>
>>>>Just stay silent! Is that too complicated?
>>>>>
>>>>>It's not C,
>>>>Of course it is. It is a common extension.
>>>>>
>>>>>so it must be platform specific,
>>>>no, it isn't
>>>"_stdcall" isn't platform-specific? Seriously?
>>>>
>>#ifndef STDCALL
>>#define STDCALL __attribute__(( stdcall))
>>#endif

>>
>What does defining "STDCALL" have to do with "__stdcall" ? They're two
>different identifiers, you know.
>>
>I suppose your point is that gcc supports a feature that's similar to
>"__stdcall" , but uses the syntax "__attribute__( (stdcall))". So two
>different platforms support a similar feature using radically
>different syntax. If I were sufficiently motivated, I'm sure I could
>find another platform that either supports it with yet another
>different syntax, or doesn't support it at all.
>>
>"__stdcall" is platform-specific.
>>

>
What piss me off of this regulars is that when they are proved
wrong they insist

Either I'm missing something, or you haven't done anything that
resembles proving me wrong.

I say __stdcall is platform-specific. You say it isn't. Fine, then
convince me that you're right. If you do, then I'll gladly admit it
(I admit to my mistakes here on a fairly regular basis).

What do you mean by "platform-specific", and how does that concept
*not* apply to __stdcall? Is it supported on all platforms?

I asked about "__stdcall" ; you replied with macro named "STDCALL".
Are they intended to be the same thing?

Don't waste your time and ours by telling us that you're pissed off
because somebody disagrees with you. If you're right, demonstrate it.

(And by the way, this isn't about you; I'd say the same thing if
anyone else made the same claim.)

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Re: __stdcall alternative

Bartc wrote:

"jacob navia" <jacob@nospam.c omwrote in message
news:fuqs6p$7r2 $1@aioe.org...

>Bartc wrote:

>

>>But, __stdcall seems to assume that machine registers are saved by the
>>called routine (as far as I can gather after a few hours messing with
>>some strange behaviours especially with optimised C code).
>>>

>OBVIOUSLY you should save the registers ytour compiler thinks are
>permanent
>>
>Under windows (where stdcall is commonly used) you should save
>(I am assuming 64 bit CPU)
>>
>rsi
>rdi
>rbx
>r12-r15
>rbp

>
OK, for x86-32 then I have to worry about esi,edi,ebx.

AND EBP!!!

>

>you could just as well use the C calling convention. The registers to save
>are THE SAME

>
The ASM is emitted by a compiler of mine from years back; I'm not going to
change it! I'll just stick in some bits of inline asm for now.
>

If your compiler was able to interface with outside code, it surely
saved those. It is very simple

push esi
push ebx
push edi

....

pop edi
pop ebx
pop esi

and you are all set

This is just a temporary measure until my project is 100% C. Or it will have
some ASM calling C which is a bit easier.
>

>but you should just issue ret
>and the called procedure adjusts the stack.

>
(That always seemed a crazy way to do things; one extra instruction /per
call/).
>

It saves 5% code space, it is very efficient.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Walter Roberson]

Re: __stdcall alternative

In article <fur0av$mro$3@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>And I showed Eric and you and Thompson that is supported
>on gcc/MSVC/Lcc-win/Watcom/Borland and what have you

The searching I did indicated that the __stdcall ABI is used only
on Windows32 (and has some discrepancies between different compilers
and compilation modes even there.) I did not find any Unix type
platforms that support it, though I did find explicit statements
that it is -not- supported on Linux.

With regards to gcc,

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

The keyword __attribute__ allows you to specify special
attributes when making a declaration. This keyword is followed
by an attribute specification inside double parentheses. The
following attributes are currently defined for functions on all
targets: aligned, alloc_size, noreturn, returns_twice,
noinline, always_inline, flatten, pure, const, nothrow,
sentinel, format, format_arg, no_instrument_f unction, section,
constructor, destructor, used, unused, deprecated, weak,
malloc, alias, warn_unused_res ult, nonnull, gnu_inline,
externally_visi ble, hot, cold, artificial, error and warning.
Several other attributes are defined for functions on
particular target systems.

Notice that stdcall is not amongst the ones defined for all targets.

stdcall
On the Intel 386, the stdcall attribute causes the compiler to
assume that the called function will pop off the stack space
used to pass arguments, unless it takes a variable number of
arguments.

Notice the platform specification in the description.

I would have to dig further to find out what happens if you
use an attribute not supported for a particular platform. My
hypothesis at the moment is that the attribute is ignored.
That would make it legal in gcc to use the stdcall attribute
when compiling on Linux -- it would just have no effect.


And for those of us not using gcc and not compiling on Windows... ?

--
"I buy more from my grocer than he buys from me, and I bet it's
the same with you and your grocer. That means we have a trade
deficit with our grocers. Does our perpetual grocer trade deficit
portend doom?" -- Walter Williams

[jacob navia]

Re: __stdcall alternative

Richard Tobin wrote:

In article <fuqtqi$dg2$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:
>

>If you use gcc you should

>
That sounds a bit platform-specific! But luckily I do use gcc.
>

>#ifndef STDCALL
>#define STDCALL __attribute__(( stdcall))
>#endif

>
I get:
>
foo.c:5: warning: 'stdcall' attribute directive ignored
>
Presumably this is an x86-only declaration.
>
-- Richard

stdcall means that the called procedure cleans up the stack.
This is needed only when a series of push instructions are
issued when passing arguments. When the machine has a lot of
registers, normally the arguments are passed in registers
and the importance of stdcall is no longer so great.

It saves approx 5% of code space. At each call point, it
is no longer necessary to adjust the stack to compensate
all the push instructions.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

Re: __stdcall alternative

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>Ian Collins wrote:
>>>Bartc wrote:
>>>>I'm mixing C and ASM, and for calling ASM from C, I just happened to
>>>>use the __stdcall convention (using C convention is not practical for
>>>>other reasons).
>>>>>
>>>What is __stdcall?
>>>
>>Just stay silent! Is that too complicated?
>>>

>Fool, if you read the bit of my post you snipped - "try a group for your
>platform, you'll get more help there." - you would see I was attempting
>to help the OP.
>>

>>>It's not C,
>>Of course it is. It is a common extension.
>>>

>Not on any platform I use, and that's quite a few.
>>

>>>so it must be platform specific,
>>no, it isn't
>>>

>Eric's already shown you that is is.
>>

>
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you

No, you showed ("claimed," actually) something about
just one of these compilers, namely, that they support
__attribute__(( stdcall)). Even if we take your word for it,
there are still the problems

1) __attribute__(( stdcall)) is not __stdcall. Count
the keystrokes if you disagree.

2) The one compiler for which you made the claim, and
even the extended list for which you have "shown"
nothing at all, are not the totality of all platforms.
In particular, you still haven't shown how to use
__stdcall on the first compiler I tried it with.
(I don't need to identify the compiler for you,
because if __stdcall isn't platform-specific it will
work the same way on the unidentified compiler as on
any other.)

what piss me off of this regulars is that when proved wrong
they insist

.... on complete, coherent sentences leading to conclusions
that you find embarrassing?

--
Eric.Sosman@sun .com

[jacob navia]

Re: __stdcall alternative

Walter Roberson wrote:

In article <fur0av$mro$3@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:
>

>And I showed Eric and you and Thompson that is supported
>on gcc/MSVC/Lcc-win/Watcom/Borland and what have you

>
The searching I did indicated that the __stdcall ABI is used only
on Windows32 (and has some discrepancies between different compilers
and compilation modes even there.) I did not find any Unix type
platforms that support it, though I did find explicit statements
that it is -not- supported on Linux.
>
With regards to gcc,

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

>
The keyword __attribute__ allows you to specify special
attributes when making a declaration. This keyword is followed
by an attribute specification inside double parentheses. The
following attributes are currently defined for functions on all
targets: aligned, alloc_size, noreturn, returns_twice,
noinline, always_inline, flatten, pure, const, nothrow,
sentinel, format, format_arg, no_instrument_f unction, section,
constructor, destructor, used, unused, deprecated, weak,
malloc, alias, warn_unused_res ult, nonnull, gnu_inline,
externally_visi ble, hot, cold, artificial, error and warning.
Several other attributes are defined for functions on
particular target systems.
>
Notice that stdcall is not amongst the ones defined for all targets.
>
stdcall
On the Intel 386, the stdcall attribute causes the compiler to
assume that the called function will pop off the stack space
used to pass arguments, unless it takes a variable number of
arguments.
>
Notice the platform specification in the description.
>
I would have to dig further to find out what happens if you
use an attribute not supported for a particular platform. My
hypothesis at the moment is that the attribute is ignored.
That would make it legal in gcc to use the stdcall attribute
when compiling on Linux -- it would just have no effect.
>
>

stdcall means that the called procedure cleans up the stack.
This is needed only when a series of push instructions are
issued when passing arguments. When the machine has a lot of
registers, normally the arguments are passed in registers
and the importance of stdcall is no longer so great.

It saves approx 5% of code space. At each call point, it
is no longer necessary to adjust the stack to compensate
all the push instructions.

And for those of us not using gcc and not compiling on Windows... ?
>

Well, compile under linux if you wish, buy a MACintosh, run
your programs under Sony play station what do you want?

If you do not have stdcall probably you do not need it.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

Re: __stdcall alternative

jacob navia wrote:

Ian Collins wrote:
>

>if you read the bit of my post you snipped - "try a group for your
>platform, you'll get more help there." - you would see I was attempting
>to help the OP.
>>

>
You were attempting to help the original poster by
showing your ignorance.
>

You're either dense or being obtuse, what's wrong with redirecting a
question somewhere it is topical?

>>>It's not C,
>>Of course it is. It is a common extension.
>>>

>Not on any platform I use, and that's quite a few.
>>

Who cares?
>

Probably anyone not using windows.

It is supported by gcc and all the platforms gcc runs on,
supported by MSVC, supported by Watcom, Borland, lcc-win,
and what have you.
>
That is almost 100% of the market. Obviously you use
something else and never look into mainstream computing like
many regulars here.
>

Ah, the typical myopic rant of a windows programmer. Wake up, most of
the market for C is in the embedded world.

--
Ian Collins.

[Flash Gordon]

Re: __stdcall alternative

Keith Thompson wrote, On 24/04/08 22:51:

jacob navia <jacob@nospam.c omwrites:

>Keith Thompson wrote:

>>jacob navia <jacob@nospam.c omwrites:
>>>Ian Collins wrote:
>>>>Bartc wrote:
>>>>>I'm mixing C and ASM, and for calling ASM from C, I just happened
>>>>>to use the __stdcall convention (using C convention is not
>>>>>practica l for other reasons).
>>>>>>
>>>>What is __stdcall?
>>>What's the point of showing your ignorance as it was a quality?
>>>>
>>>You do not know the subject matter?
>>>>
>>>Just stay silent! Is that too complicated?
>>>>
>>>>It's not C,
>>>Of course it is. It is a common extension.
>>>>
>>>>so it must be platform specific,
>>>no, it isn't
>>"_stdcall" isn't platform-specific? Seriously?
>>>

>#ifndef STDCALL
>#define STDCALL __attribute__(( stdcall))
>#endif

>
What does defining "STDCALL" have to do with "__stdcall" ? They're two
different identifiers, you know.
>
I suppose your point is that gcc supports a feature that's similar to
"__stdcall" , but uses the syntax "__attribute__( (stdcall))". So two
different platforms support a similar feature using radically
different syntax. If I were sufficiently motivated, I'm sure I could
find another platform that either supports it with yet another
different syntax, or doesn't support it at all.
>
"__stdcall" is platform-specific.

markg@hal02 ~ $ cat t.c
#ifndef STDCALL
#define STDCALL __attribute__(( stdcall))
#endif
extern void STDCALL foo(void);
markg@hal02 ~ $ gcc -c t.c
t.c:4: warning: `stdcall' attribute directive ignored
markg@hal02 ~ $

Admittedly that is not an x86 based system. So just in case it is
specific to the processor type lets try on one of my x86 based systems...

On another system:
-bash-2.05b$ cc t.c
UX:i386acomp: ERROR: "t.c", line 4: error: Syntax error before or at: (
UX:i386acomp: ERROR: "t.c", line 4: error: cannot recover from previous
errors
-bash-2.05b$ cat tt.c
#ifndef STDCALL
#define STDCALL __stdcall
#endif
extern void STDCALL foo(void);
-bash-2.05b$ cc tt.c
UX:i386acomp: ERROR: "tt.c", line 4: error: syntax error, probably
missing ",", ";" or "="
UX:i386acomp: ERROR: "tt.c", line 4: error: Syntax error before or at: foo
UX:i386acomp: WARNING: "tt.c", line 4: warning: declaration missing
specifiers: assuming "int"
-bash-2.05b$


Nope, doesn't work on all x86 based systems either.

So Keith and Ian are correct to say it is platform specific.
--
Flash Gordon

[Kenny McCormack]

Re: __stdcall alternative

In article <87y773rlvi.fsf @kvetch.smov.or g>,
Keith Thompson <kst-u@mib.orgwrote:
....

>no, it isn't

>
>"_stdcall" isn't platform-specific? Seriously?
>

It depends on what you mean by "specific". On Usenet, where everybody
wants to be a standards jockey (not just here [clc], but clc is among the
worst), there is a tendency to use the phrase "platform specific" even
if the thing works on 99% (say) of all platforms. This is not a usage
of the word "specific" that maps to the real world, in any other sphere
of endeavor. One might go on to say that people who use it in this way
are insane.

In the real world, the word "specific" usually implies uniqueness -
i.e., we would say that something is "platform specific" if it worked on
exactly 1 platform (hence, specific to that platform).

[Jack Klein]

Re: __stdcall alternative

On Thu, 24 Apr 2008 22:59:10 +0200, jacob navia <jacob@nospam.c om>
wrote in comp.lang.c:

Ian Collins wrote:

Bartc wrote:

I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
>

What is __stdcall?

>
What's the point of showing your ignorance as it was a quality?
>
You do not know the subject matter?
>
Just stay silent! Is that too complicated?
>
>

It's not C,

>
Of course it is. It is a common extension.

Perhaps by your definition of "common". It doesn't exist on more than
90% of the current C compilers in existence, only on the half-a-dozen
or so for Windows.

so it must be platform specific,

>
no, it isn't

Yes, it is.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Jack Klein]

Re: __stdcall alternative

On Fri, 25 Apr 2008 00:07:23 +0200, jacob navia <jacob@nospam.c om>
wrote in comp.lang.c:

Ian Collins wrote:

jacob navia wrote:

Ian Collins wrote:
>Bartc wrote:
>>I'm mixing C and ASM, and for calling ASM from C, I just happened to
>>use the __stdcall convention (using C convention is not practical for
>>other reasons).
>>>
>What is __stdcall?
>
Just stay silent! Is that too complicated?
>

Fool, if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.

>It's not C,
Of course it is. It is a common extension.
>

Not on any platform I use, and that's quite a few.

>so it must be platform specific,
no, it isn't
>

Eric's already shown you that is is.

>
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you

OK, that's less than 5% of all the current C compilers in existence.
And all for one specific processor architecture. Anything that is
specific to one processor architecture is platform specific.

what piss me off of this regulars is that when proved wrong
they insist

What pisses me off about idiots like you is that when they are proven
wrong they just get belligerent and start insulting people.

Learn this definition:

Anything not available on every conforming C implementation is
platform specific.

Just supply me with the name of one compiler for all of the following
architectures that supports this stupidity:

- ARM

- MIPS

- Any TI DSP

- Any AD DSP

- 8051

....but what's the point of going on, no amount of common sense or
logic will ever penetrate your ego.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html