No, this is false, both at the high-level-language and assembly-language level:
http://en.wikipedia.org/wiki/X86_calling_conventions
A function call transparently returns to the point at which the call originated and resumes execution. A GOTO departs from the original location, never to return. That is a crucial difference.
> EDIT: you could more accurately replace each instance of "function call" in the above with "subroutine" as FORTRAN defines them, which is closer to what you get for free with gotos than a function call with an actual stack pointer.
Still wrong -- you're confusing two very different things. A function call, in both the assembly and high-level sense, is completely different from a GOTO instruction.
(combined with a global pointer to a stack, a few instructions and a jmp should be enough to reimplement functions, including storing the return jmp address somewhere, obviously. As I think I made clear, I believe we invented compilers so that we don't have to know how this stuff is actually implemented. I do realise that I'm never going to know more about assembly than the set of HN readers who will pounce on this kind of comment - I was just trying to show that I have heard of jmp, and that I know it is spat out by compilers to implement high level language features, and that any nontrivial compiled program will contain many jmp instructions. A bug from using goto where a switch or if/else statement would have worked is inexcusable, and also nothing to do with assembly instructions.)
[1] actually, iOS 7? I take that back.
Yes, and there's a reason -- chip design should reflect how computers are programmed at a higher level, and function calls produce code that's easier to understand, create and maintain. The reason is that function calls obey a logical hierarchy that often reflects the meaning of the algorithm being executed.
To see the point, try creating a recursive-descent parser that uses GOTO and avoids function calls.
This understanding isn't limited to an HN gaggle of nattering bystanders:
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...
> I was just trying to show that I have heard of jmp, and that I know it is spat out by compilers to implement high level language features, and that any nontrivial compiled program will contain many jmp instructions.
Yes, but what a compiler does, and what a high-level language does, are often completely different. As one example, many recursive algorithms are compiled into functionally equivalent loops, to make them more efficient and to keep from blowing up the stack.
My point is that a compiler's output doesn't have to be read by a human, so it can break every rule. Not so for a high-level code listing that might have to be understood and maintained over decades.
As with everything, gotos work just fine if you restrict yourself to a few specific uses. At that point, however, you've basically just invented function calls, switch statements, and maybe exceptions if your rules aren't strict enough, which can all be managed by a compiler which always generates the correct number of jmp's to do the job.
EDIT: you could more accurately replace each instance of "function call" in the above with "subroutine" as FORTRAN defines them, which is closer to what you get for free with gotos than a function call with an actual stack pointer.