The title says everything. I am talking about C/C++ specifically, because both consider this as "implementation issue". I think, defining a standard interface can ease building a module system on top of it, and many other good things.
What could C/C++ "lose" if they defined a standard ABI?
views:
374answers:
5
+18
A:
The freedom to implement things in the most natural way on each processor.
I imagine that c in particular has conforming implementations on more different architectures than any other language. Abiding by a ABI optimized for the currently common, high-end, general-purpose CPUs would require unnatural contortions on some the odder machines out there.
dmckee
2010-01-17 23:25:19
Very much agreed. On many platforms, you'd like to pass arguments in registers for speed, but you don't want to use all the registers for argument passing. But different platforms have different numbers of registers. Some platforms have no floating-point registers at all. Any completely general ABI would be suboptimal on nearly every platform.
Stephen Canon
2010-01-17 23:32:22
One of the reasons C became so popular was because it didn't specify a standard ABI (IIRC, Pascal did). Thus, compiler writers could do whatever worked best. Initially, everyone did pretty much the same thing in terms of stack framing, but later, for architectures like DSPs, they started to specify ways to pack function arguments into registers, greatly reducing the number of instructions and memory transactions needed for a function call.
Mike DeSimone
2010-01-17 23:44:31
I remember an architecture which had a 32-register file visible to the programmer, but implemented it in hardware as a 512-register block with a sliding window. r0-r7 were parameters passed to a called function, r8-r15 were function locals, r16-r23 were parameters passed in from the function's caller, and r24-r31 were globals, including the stack pointer. r24-31 would always point to the same place, but the others were mapped through a window that would slide down 16 registers with a function call (mapping the caller's r0-7 to the callee's r16-r23), then slide back 16 on return.
Mike DeSimone
2010-01-17 23:48:35
@Mike @Stephan: Great comments.
dmckee
2010-01-17 23:57:20
@Mike: That sounds very much like SPARC, but different generations had different amounts of HW registers before they spilled over to RAM.
MSalters
2010-01-18 08:13:05
+5
A:
Backwards compatibility on every platform except for the one whose ABI was chosen.
Stephen Canon
2010-01-17 23:26:17
Alternately, whoever standardizes this could refuse to choose any existing ABI (presumably because nobody could agree on a competitor's), and then nobody would have backward compatibility.
David Thornley
2010-01-17 23:33:12
We don't have backward compatibility now. Every time a compiler is updated you may be required to re-compile all your libs to conform to the new ABI it defines.
Martin York
2010-01-18 01:10:48
@Martin: If you have to do that, you have a malicious compiler vendor and you should stop giving them money for their product. There's no excuse for ABI breaking.
Stephen Canon
2010-01-18 02:19:28
@Stephen: GCC did 3 times in the previous version. 2.9x -> 3.0 (break: New ABI) 3.0 -> 3.1 (break Bug Fix) 3.1 -> 3.2 (break Something else)
Martin York
2010-01-18 02:24:36
I'm not saying it doesn't happen, I'm saying that it shouldn't. The reasons for doing it don't justify the complications of breaking compatibility.
Stephen Canon
2010-01-18 02:35:03
Yeah, that does make it a little harder to negotiate better behavior from the GCC maintainers =)
Stephen Canon
2010-01-18 03:23:44
There may have been problems in C++ with GCC, but I don't recall any problems with C.
Jonathan Leffler
2010-01-18 05:15:09
+3
A:
Execution speed would suffer drastically on a majority of platforms. So much so that it would likely no longer be reasonable to use the C language for a number of embedded platforms. The standards body could be liable for an antitrust suit brought by the makers of the various chips not compatible with the ABI.
Justin Smith
2010-01-17 23:34:32
+3
A:
Well, there wouldn't be one standard ABI, but about 1000. You would need one for every combination of OS and processor architecture.
Initially, nothing would be lost. But eventually, somebody would find some horrible bug and they would either fix it, breaking the ABI, or leave it, causing problems.
I think that the situation right now is fine. Any OS is free to define an ABI for itself (and they do), which makes sense. It should be the job of the OS to define its ABI, not the C/C++ standard.
Zifre
2010-01-17 23:45:48
Or the developer, for those developing code that runs without an OS.
Justin Smith
2010-01-17 23:49:40
+4
A:
Rather than a generic ABI for all platforms (which would be disastrous as it would only be optimal for only one platform). The standard's committee could say that each platform will conform to a specific ABI.
But: Who defines it (the first compiler through the door?). In which case they get an excessive competitive advantage. Or a committee after 5 years of compilers (which would be another horrible idea).
Also it does not give the compiler leaway to do further research into new optimization strategies, you would be stuck with the tricks available at the point where the standard was defined.
Martin York
2010-01-18 01:23:18