Voting: Unterschied zwischen den Versionen
(OLoGENRIlWmk) |
(ypTCexMxUNEfrjyP) |
||
| Zeile 1: | Zeile 1: | ||
| − | + | The whole discussion pretades C or C++. It goes back to when someone came up with the idea of encapsulating and generalizing some code in such a way that that bit of code could use names for things supplied from the outside (the caller) to generalize the code thus encapsulated. They called them functions or subroutines or subfunctions or methods or whatever.These were the days of Dartmouth Basic, Fortran IV, Cobol and Lisp. Algol was a gleam in somebodies eye. PL/1 was new and Bell Labs made telephones. (Ok not exactly but close.)Early processors were invented before these functions were invented and the low-level (assembly, maybe) code to support them was something of a rube-goldberg affair. There was no stack. So this bunch of code was written in different ways by various compiler.And, too, they were just inventing structures or data blocks that contained pointers to other data blocks so that whole confusion didn't really matter.In one way to do it, that I saw on the CDC 6 00 mainframes for some language was to reserve some memory locations just before the memory location that held the 1st instruction of the function. Go back one and it was reserved for the return address. Back two held the return value and three and so on were the parameters themselves. An integer argument value could be put in the location back three from the entry point OR the address of some memory location holding an integer value could go there. It depended on the language at times. (Everything was the same size, mostly.) A call to the function, foo, consisted of code to store the return address at foo-1, store the parameters (or their addresses) at foo-3, foo-4, etc. followed by a goto foo itself. Code at the return address would copy the values from the argument block back to the variables when control returned to the caller. Or not. (That's why they cared about call by ref or value.)A return from the function consisted of storing the return value (if any) at foo-1, storing the argument values (maybe) back into foo-2 and above, grabbing the return address from foo-1 and jumping to it. (Recursion was not an option.)The whole handling of the arguments was just dependent on how you wrote the compiler.Later, someone came up with stack based processors. It was cool beyond belief. Recursion worked. You could do a sort of push on the stack to create a block of memory to hold parameters and local variables. And a return was simply pop the stack frame and return address and jump to the popped address.The mechanism of function calling was built into the instruction set.That limited the possibilities of how to call a function and made the whole argument of call by value or call by reference a matter of archeology. I say, Who cares? | |
Version vom 14. Dezember 2012, 14:26 Uhr
The whole discussion pretades C or C++. It goes back to when someone came up with the idea of encapsulating and generalizing some code in such a way that that bit of code could use names for things supplied from the outside (the caller) to generalize the code thus encapsulated. They called them functions or subroutines or subfunctions or methods or whatever.These were the days of Dartmouth Basic, Fortran IV, Cobol and Lisp. Algol was a gleam in somebodies eye. PL/1 was new and Bell Labs made telephones. (Ok not exactly but close.)Early processors were invented before these functions were invented and the low-level (assembly, maybe) code to support them was something of a rube-goldberg affair. There was no stack. So this bunch of code was written in different ways by various compiler.And, too, they were just inventing structures or data blocks that contained pointers to other data blocks so that whole confusion didn't really matter.In one way to do it, that I saw on the CDC 6 00 mainframes for some language was to reserve some memory locations just before the memory location that held the 1st instruction of the function. Go back one and it was reserved for the return address. Back two held the return value and three and so on were the parameters themselves. An integer argument value could be put in the location back three from the entry point OR the address of some memory location holding an integer value could go there. It depended on the language at times. (Everything was the same size, mostly.) A call to the function, foo, consisted of code to store the return address at foo-1, store the parameters (or their addresses) at foo-3, foo-4, etc. followed by a goto foo itself. Code at the return address would copy the values from the argument block back to the variables when control returned to the caller. Or not. (That's why they cared about call by ref or value.)A return from the function consisted of storing the return value (if any) at foo-1, storing the argument values (maybe) back into foo-2 and above, grabbing the return address from foo-1 and jumping to it. (Recursion was not an option.)The whole handling of the arguments was just dependent on how you wrote the compiler.Later, someone came up with stack based processors. It was cool beyond belief. Recursion worked. You could do a sort of push on the stack to create a block of memory to hold parameters and local variables. And a return was simply pop the stack frame and return address and jump to the popped address.The mechanism of function calling was built into the instruction set.That limited the possibilities of how to call a function and made the whole argument of call by value or call by reference a matter of archeology. I say, Who cares?
