|
Yeah, I tried that and other pages with official, and unofficial instructions. Nothing worked for a while. Finally, manually got the url to the download, wget'd the file, and manually set it up. Got it working now. Took forever to build a hello-world app. I guess the processor is too slow for build/compilation. 
|
|
|
|
|
Finally got VS Code installed too. It's really slow. This is not how it's meant to be used. I just wanted to see how it'd look like on the Pi.
|
|
|
|
|
You are most welcome. Glad you're enjoying it Nish!
|
|
|
|
|
What is the theory behind making the default calling convention cdecl?
It leads to larger code and it's fundamentally incompatible with OS APIs.
What were they thinking?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Just googled your subject, did not read it: Calling Conventions Demystified[^]
And btw: I don't care about this additional Bytes caused by cdecl vs. others. In case I use a math lib (dll) from where I use most probably only 2% of it I "waste" much more Bytes
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Thank you for your opinion.
It's good to hear from someone more knowledgeable on this subject than I.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Quote: It's good to hear from someone more knowledgeable on this subject than I.
Please use sarcasm-- 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Why? Might be bias or random.
But one could say that if it was thought about then perhaps because it was much more likely, when it was originally specified, that one would be calling a library that used exactly that calling convention. Probably almost always.
But since it wasn't 100% they needed to account for the other cases.
|
|
|
|
|
Probably, backward compatibility.
There was a huge reservoir of C libraries back than, and since C++ wasn't a "new language" per se but a superset of C it would have made sense to design it to work with existing code.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's a very interesting point, because I just assumed that C's default convention was stdapi. The reason I assumed that is that when you want to export a function from a C++ DLL, you usually enclose the declaration in extern "C".
But I never considered that C's default convention was cdecl.
Well played.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: But I never considered that C's default convention was cdecl.
Hence the name, "cdecl"
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: Hence the name, "cdecl"
And that's why I come to this board! I always learn something interesting.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
extern "C" indicates that C++ name mangling should not be used - just the plain function name, not decorated with the types of the function arguments for overload resolution.
|
|
|
|
|
Your partly correct, indeed it indicates that C++ name mangling should not be used. But this does not mean plain function names. It's mangling the way c get's mangled. For example a function returning a 32 bit int would be something like function@4 and if u take stdcall c function by a microsoft vc compiler u often get even more mangling on the function name.
|
|
|
|
|
It is the opposite, *they* did the OS the wrong way.
|
|
|
|
|
The reasons are mostly historical. The cdecl convention allows for variable-length parameter lists (as required by the printf and scanf families, etc.). For all I know, it may also have been more efficient on the PDP-8 and -11, which were first used to run C.
In order to maintain binary compatibility with C libraries, many C++ compilers also adopted the cdecl convention as default.
Windows 1.0 was originally compiled to use the cdecl convention. Microsoft discovered that the executables would be smaller with the pascal convention (and, IIRC correctly, fit on one less diskette), so they switched.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: so they switched.
bad decision
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
When Windows 1.0 was released, most PCs used 8088s. A high-performance machine used an 80286, and the 80386 was just coming on the market. We looked for every possible way to eke out some extra performance. Microsoft's decision made sense at the time from both the technical and the production standpoints - saving three bytes and one instruction for each function call, and shipping Windows on one less diskette.
Windows was from the beginning designed to be programmed in C. Unless you were writing code in Assembly language (mostly device drivers), the difference between the calling conventions was handled by the compiler and so was transparent to the programmer. At the C level, it makes no more difference than big-endian vs. little-endian.
(Now, let the Religious Wars resume... )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Very good information!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Quote: Windows was from the beginning designed to be programmed in C.
That is true if you never opened a window before it became 32 bits.
The native calling convention of the original 16 bits Windows was the Pascal way of doing it.
|
|
|
|
|
- The Windows SDK was always published first in C. If any ports to other languages occurred (e.g. Borland's Borland Pascal), they were delayed by some months.
- As my OP said, the calling convention is handled by the C compiler, so unless you are programming in Assembly language, it is irrelevant.
I stand by my statement.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
C++ has no default calling convention; it is implementation defined.
MSDN states msvc uses cdecl by default. However, on x64, __fastcall is used unless there are variable number of arguments.
Also note that while Win32 uses __stdcall by default for it's APIs, this is not mandatory for operating systems.
|
|
|
|
|
I thought C++ preferred stdcall, whereas C was always cdecl.
Fast call is a head f*** though, using registers for the first arguments!
|
|
|
|
|
Read reply of every single one and it was nice that people still care about it. Just as you can drive either on Left side or on Right side of road, in computer world, there are two primary directions to read or write data from. For higher level languages, compiler encapsulates all this complexity and provides user a neat option to switch the calling conventions. C language adopted PDP convention as its de-facto and coined the term cdecl to encapsulate the idea. The original name for opposite calling convention was PASCAL and if you go thru some old Windows API books, you will find that word.
all over the place. cdecl convention allows variadic parameters very easily whereas PASCAL convention makes stack management easier.
Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
|
|
|
|
|
Quote: Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
x86 specific, RISC architectures probably have similar constraints for registers used to push arguments.
cdecl causes more code because the caller is responsible for cleaning up the pushed arguments.
Since cdecl allows variable argument count, only the caller knows how many arguments were actually pushed.
printf("Hello", unused1, unused2);
Hence the extra instruction mentioned on another post; after the call returns, the stack must be adjusted to remove the pushed arguments.
std call/Pascal is a fixed argument list and the callee can adjust the argument list.
On the x86 processers, "return from subroutine" has a form that allows for the stack to be adjusted to remove the pushed arguments. The std call/Pascal convention used this form to "return and adjust" as a single opcode + operand.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
