Does the in-code argument passing conventions used on PDP-11's have a name?Why did the PDP-11 include a JMP...
What is the oldest European royal house?
Precision notation for voltmeters
Professor forcing me to attend a conference, I can't afford even with 50% funding
What can I do if someone tampers with my SSH public key?
Was it really inappropriate to write a pull request for the company I interviewed with?
Did Amazon pay $0 in taxes last year?
Ultrafilters as a double dual
Who has more? Ireland or Iceland?
Insult for someone who "doesn't know anything"
An Undercover Army
Does an unused member variable take up memory?
A running toilet that stops itself
Is it a Cyclops number? "Nobody" knows!
How does learning spells work when leveling a multiclass character?
How to make sure I'm assertive enough in contact with subordinates?
Book where society has been split into 2 with a wall down the middle where one side embraced high tech whereas other side were totally against tech
Why is there an extra space when I type "ls" on the Desktop?
How to write a chaotic neutral protagonist and prevent my readers from thinking they are evil?
SHA 256 Algorithm
Instances in Shas where Tosfos quotes the Rambam?
What is the orbital boost acceleration of the ISS?
Other authors are notified except me, good or bad sign?
Does the US political system, in principle, allow for a no-party system?
What does it take to become a wilderness skills guide as a business?
Does the in-code argument passing conventions used on PDP-11's have a name?
Why did the PDP-11 include a JMP instruction?Was the PDP-11 coroutine instruction actually used?Timing and microcode in the PDP-11/40What is the starting address pointed by Stack Pointer in PDP 11?The baud rate of which serial card does the “stty” command returns in UNIX V7?What was the clock speed and ips for the original PDP-11?What is the history of the PDP-11 MARK instruction?PDP-11 JMP and JSR - how was the target specified?
Some subroutine calls on PDP-11 machines would be coded with the arguments appearing immediately after JSR or EMT instruction, something like this (apologies for not knowing the exact MACRO syntax):
jsr r5,WRITE_STRING
.byte 'This is some string'.'0'
continue:
; do stuff
rts pc
WRITE_STRING:
movb (r5)+,r0
beq done
.PRINT r0
br WRITE_STRING
done:
inc r5
bic #1,r5
jmp (r5)
The jsr instruction sets r5 to point to the beginning of an ASCIZ string that is located in-line in the code, right after the jsr. The WRITE_STRING subroutine then reads the bytes pointed to by r5 and prints them out until the terminating zero is found. r5 is then aligned property, and control is returned to the caller with jmp (r5).
There were variants of this calling conventions; for instance the arguments could be indirect, in which case pointers to the actual arguments would be inlined in code, rather than the arguments themselves.
Was there a name for this in-line argument technique?
pdp-11
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Some subroutine calls on PDP-11 machines would be coded with the arguments appearing immediately after JSR or EMT instruction, something like this (apologies for not knowing the exact MACRO syntax):
jsr r5,WRITE_STRING
.byte 'This is some string'.'0'
continue:
; do stuff
rts pc
WRITE_STRING:
movb (r5)+,r0
beq done
.PRINT r0
br WRITE_STRING
done:
inc r5
bic #1,r5
jmp (r5)
The jsr instruction sets r5 to point to the beginning of an ASCIZ string that is located in-line in the code, right after the jsr. The WRITE_STRING subroutine then reads the bytes pointed to by r5 and prints them out until the terminating zero is found. r5 is then aligned property, and control is returned to the caller with jmp (r5).
There were variants of this calling conventions; for instance the arguments could be indirect, in which case pointers to the actual arguments would be inlined in code, rather than the arguments themselves.
Was there a name for this in-line argument technique?
pdp-11
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
For common cases where code size would be more important than execution speed, including most uses variadic arguments, it would seem like code size could often have been reduced by having a generic "call function" function that would process encoded information stored immediately after the call itself which would describe the function and its arguments, reducing the size of code needed to supply them to the caller.
– supercat
yesterday
Note that on systems using split I/D address spaces, this calling convention may not work as expected, because the argument fetches will come from the Data space rather than from the Instruction space.
– Ken Gober
19 hours ago
add a comment |
Some subroutine calls on PDP-11 machines would be coded with the arguments appearing immediately after JSR or EMT instruction, something like this (apologies for not knowing the exact MACRO syntax):
jsr r5,WRITE_STRING
.byte 'This is some string'.'0'
continue:
; do stuff
rts pc
WRITE_STRING:
movb (r5)+,r0
beq done
.PRINT r0
br WRITE_STRING
done:
inc r5
bic #1,r5
jmp (r5)
The jsr instruction sets r5 to point to the beginning of an ASCIZ string that is located in-line in the code, right after the jsr. The WRITE_STRING subroutine then reads the bytes pointed to by r5 and prints them out until the terminating zero is found. r5 is then aligned property, and control is returned to the caller with jmp (r5).
There were variants of this calling conventions; for instance the arguments could be indirect, in which case pointers to the actual arguments would be inlined in code, rather than the arguments themselves.
Was there a name for this in-line argument technique?
pdp-11
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Some subroutine calls on PDP-11 machines would be coded with the arguments appearing immediately after JSR or EMT instruction, something like this (apologies for not knowing the exact MACRO syntax):
jsr r5,WRITE_STRING
.byte 'This is some string'.'0'
continue:
; do stuff
rts pc
WRITE_STRING:
movb (r5)+,r0
beq done
.PRINT r0
br WRITE_STRING
done:
inc r5
bic #1,r5
jmp (r5)
The jsr instruction sets r5 to point to the beginning of an ASCIZ string that is located in-line in the code, right after the jsr. The WRITE_STRING subroutine then reads the bytes pointed to by r5 and prints them out until the terminating zero is found. r5 is then aligned property, and control is returned to the caller with jmp (r5).
There were variants of this calling conventions; for instance the arguments could be indirect, in which case pointers to the actual arguments would be inlined in code, rather than the arguments themselves.
Was there a name for this in-line argument technique?
pdp-11
pdp-11
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
John KällénJohn Källén
1313
1313
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
John Källén is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
For common cases where code size would be more important than execution speed, including most uses variadic arguments, it would seem like code size could often have been reduced by having a generic "call function" function that would process encoded information stored immediately after the call itself which would describe the function and its arguments, reducing the size of code needed to supply them to the caller.
– supercat
yesterday
Note that on systems using split I/D address spaces, this calling convention may not work as expected, because the argument fetches will come from the Data space rather than from the Instruction space.
– Ken Gober
19 hours ago
add a comment |
For common cases where code size would be more important than execution speed, including most uses variadic arguments, it would seem like code size could often have been reduced by having a generic "call function" function that would process encoded information stored immediately after the call itself which would describe the function and its arguments, reducing the size of code needed to supply them to the caller.
– supercat
yesterday
Note that on systems using split I/D address spaces, this calling convention may not work as expected, because the argument fetches will come from the Data space rather than from the Instruction space.
– Ken Gober
19 hours ago
For common cases where code size would be more important than execution speed, including most uses variadic arguments, it would seem like code size could often have been reduced by having a generic "call function" function that would process encoded information stored immediately after the call itself which would describe the function and its arguments, reducing the size of code needed to supply them to the caller.
– supercat
yesterday
For common cases where code size would be more important than execution speed, including most uses variadic arguments, it would seem like code size could often have been reduced by having a generic "call function" function that would process encoded information stored immediately after the call itself which would describe the function and its arguments, reducing the size of code needed to supply them to the caller.
– supercat
yesterday
Note that on systems using split I/D address spaces, this calling convention may not work as expected, because the argument fetches will come from the Data space rather than from the Instruction space.
– Ken Gober
19 hours ago
Note that on systems using split I/D address spaces, this calling convention may not work as expected, because the argument fetches will come from the Data space rather than from the Instruction space.
– Ken Gober
19 hours ago
add a comment |
2 Answers
2
active
oldest
votes
The older PDP-8 did similar. It had only one register to speak of (the accumulator), so a subroutine that took several parameters would typically provide a set of values and/or pointers to values immediately after the call instruction (JMS). The called routine would increment the return address to access parameters, and finally to return to the caller just after the parameter block.
This text describes the parameter passing as "in-line":
https://people.cs.clemson.edu/~mark/subroutines/pdp8.html.
The PDP-8 handbook "Introduction to Programming", January 1969, page 3-19, item #6 describes it simply with the following:
The second number to be multiplied is brought into the subroutine by the
TAD I MULTinstruction since it is stored in the location specified by the address that theJMSinstruction automatically stores in the first location of the subroutine [i.e. the return address]. This is a common technique for transferring information to a subroutine.
The first instruction of a subroutine was where the return address is stored by the JMS instruction. Thus, this word was used to pick up parameters as well as to return to the function's caller. The PDP-8 had fixed size instructions and data words of 12-bits (word addressing only); it also supported a memory indirect addressing mode, and a memory increment operation, so this approach worked fairly well.
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
add a comment |
I do not know any specific name here. It was usually called a 'Parameter List'.
It may be due to the fact that this way was more or less the standard handling on many early systems supporting subroutine calls. The need of special names usually only arises when additional methods come into use.
Its inherent benefit is that no additional parameter register is needed, as the return address is stored in the link register, which can then double as a parameter list pointer, only to be advanced while processing, and at the end holding the return address (after the parameter list) (*1). For mainframe systems it was the standard calling convention.
Using the stack for return address handling is a rather new development - compared with parameter passing - but even then it was used quite a lot. Just think the way OS calls (*2) are made in Apple ProDOS.
*1 - In fact, it wouldn't at all be weird to think of it as a stack pointer to access (and pop) the parameters - and when all parameters are removed it holds the return address.
*2 - MLI or Machine Language Interface in ProDOS lingo. Here the JSR to $BF00, the ProDOS entry point, is followed by a byte defining the function call and a word holding the address of a parameter block for this function.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
John Källén is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9328%2fdoes-the-in-code-argument-passing-conventions-used-on-pdp-11s-have-a-name%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The older PDP-8 did similar. It had only one register to speak of (the accumulator), so a subroutine that took several parameters would typically provide a set of values and/or pointers to values immediately after the call instruction (JMS). The called routine would increment the return address to access parameters, and finally to return to the caller just after the parameter block.
This text describes the parameter passing as "in-line":
https://people.cs.clemson.edu/~mark/subroutines/pdp8.html.
The PDP-8 handbook "Introduction to Programming", January 1969, page 3-19, item #6 describes it simply with the following:
The second number to be multiplied is brought into the subroutine by the
TAD I MULTinstruction since it is stored in the location specified by the address that theJMSinstruction automatically stores in the first location of the subroutine [i.e. the return address]. This is a common technique for transferring information to a subroutine.
The first instruction of a subroutine was where the return address is stored by the JMS instruction. Thus, this word was used to pick up parameters as well as to return to the function's caller. The PDP-8 had fixed size instructions and data words of 12-bits (word addressing only); it also supported a memory indirect addressing mode, and a memory increment operation, so this approach worked fairly well.
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
add a comment |
The older PDP-8 did similar. It had only one register to speak of (the accumulator), so a subroutine that took several parameters would typically provide a set of values and/or pointers to values immediately after the call instruction (JMS). The called routine would increment the return address to access parameters, and finally to return to the caller just after the parameter block.
This text describes the parameter passing as "in-line":
https://people.cs.clemson.edu/~mark/subroutines/pdp8.html.
The PDP-8 handbook "Introduction to Programming", January 1969, page 3-19, item #6 describes it simply with the following:
The second number to be multiplied is brought into the subroutine by the
TAD I MULTinstruction since it is stored in the location specified by the address that theJMSinstruction automatically stores in the first location of the subroutine [i.e. the return address]. This is a common technique for transferring information to a subroutine.
The first instruction of a subroutine was where the return address is stored by the JMS instruction. Thus, this word was used to pick up parameters as well as to return to the function's caller. The PDP-8 had fixed size instructions and data words of 12-bits (word addressing only); it also supported a memory indirect addressing mode, and a memory increment operation, so this approach worked fairly well.
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
add a comment |
The older PDP-8 did similar. It had only one register to speak of (the accumulator), so a subroutine that took several parameters would typically provide a set of values and/or pointers to values immediately after the call instruction (JMS). The called routine would increment the return address to access parameters, and finally to return to the caller just after the parameter block.
This text describes the parameter passing as "in-line":
https://people.cs.clemson.edu/~mark/subroutines/pdp8.html.
The PDP-8 handbook "Introduction to Programming", January 1969, page 3-19, item #6 describes it simply with the following:
The second number to be multiplied is brought into the subroutine by the
TAD I MULTinstruction since it is stored in the location specified by the address that theJMSinstruction automatically stores in the first location of the subroutine [i.e. the return address]. This is a common technique for transferring information to a subroutine.
The first instruction of a subroutine was where the return address is stored by the JMS instruction. Thus, this word was used to pick up parameters as well as to return to the function's caller. The PDP-8 had fixed size instructions and data words of 12-bits (word addressing only); it also supported a memory indirect addressing mode, and a memory increment operation, so this approach worked fairly well.
The older PDP-8 did similar. It had only one register to speak of (the accumulator), so a subroutine that took several parameters would typically provide a set of values and/or pointers to values immediately after the call instruction (JMS). The called routine would increment the return address to access parameters, and finally to return to the caller just after the parameter block.
This text describes the parameter passing as "in-line":
https://people.cs.clemson.edu/~mark/subroutines/pdp8.html.
The PDP-8 handbook "Introduction to Programming", January 1969, page 3-19, item #6 describes it simply with the following:
The second number to be multiplied is brought into the subroutine by the
TAD I MULTinstruction since it is stored in the location specified by the address that theJMSinstruction automatically stores in the first location of the subroutine [i.e. the return address]. This is a common technique for transferring information to a subroutine.
The first instruction of a subroutine was where the return address is stored by the JMS instruction. Thus, this word was used to pick up parameters as well as to return to the function's caller. The PDP-8 had fixed size instructions and data words of 12-bits (word addressing only); it also supported a memory indirect addressing mode, and a memory increment operation, so this approach worked fairly well.
answered yesterday
Erik EidtErik Eidt
1,097412
1,097412
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
add a comment |
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
For languages where parameters are passed by reference, and variables are statically assigned (=have fixed virtual addresses), that approach may be considered "natural". Code the "call" instruction followed by the addresses of the actual-parameters; easy. This probably suits early Fortran on the -11, but as noted, split I/D breaks that. To answer the question though: I knew of no name except "inline arguments".
– another-dave
18 hours ago
add a comment |
I do not know any specific name here. It was usually called a 'Parameter List'.
It may be due to the fact that this way was more or less the standard handling on many early systems supporting subroutine calls. The need of special names usually only arises when additional methods come into use.
Its inherent benefit is that no additional parameter register is needed, as the return address is stored in the link register, which can then double as a parameter list pointer, only to be advanced while processing, and at the end holding the return address (after the parameter list) (*1). For mainframe systems it was the standard calling convention.
Using the stack for return address handling is a rather new development - compared with parameter passing - but even then it was used quite a lot. Just think the way OS calls (*2) are made in Apple ProDOS.
*1 - In fact, it wouldn't at all be weird to think of it as a stack pointer to access (and pop) the parameters - and when all parameters are removed it holds the return address.
*2 - MLI or Machine Language Interface in ProDOS lingo. Here the JSR to $BF00, the ProDOS entry point, is followed by a byte defining the function call and a word holding the address of a parameter block for this function.
add a comment |
I do not know any specific name here. It was usually called a 'Parameter List'.
It may be due to the fact that this way was more or less the standard handling on many early systems supporting subroutine calls. The need of special names usually only arises when additional methods come into use.
Its inherent benefit is that no additional parameter register is needed, as the return address is stored in the link register, which can then double as a parameter list pointer, only to be advanced while processing, and at the end holding the return address (after the parameter list) (*1). For mainframe systems it was the standard calling convention.
Using the stack for return address handling is a rather new development - compared with parameter passing - but even then it was used quite a lot. Just think the way OS calls (*2) are made in Apple ProDOS.
*1 - In fact, it wouldn't at all be weird to think of it as a stack pointer to access (and pop) the parameters - and when all parameters are removed it holds the return address.
*2 - MLI or Machine Language Interface in ProDOS lingo. Here the JSR to $BF00, the ProDOS entry point, is followed by a byte defining the function call and a word holding the address of a parameter block for this function.
add a comment |
I do not know any specific name here. It was usually called a 'Parameter List'.
It may be due to the fact that this way was more or less the standard handling on many early systems supporting subroutine calls. The need of special names usually only arises when additional methods come into use.
Its inherent benefit is that no additional parameter register is needed, as the return address is stored in the link register, which can then double as a parameter list pointer, only to be advanced while processing, and at the end holding the return address (after the parameter list) (*1). For mainframe systems it was the standard calling convention.
Using the stack for return address handling is a rather new development - compared with parameter passing - but even then it was used quite a lot. Just think the way OS calls (*2) are made in Apple ProDOS.
*1 - In fact, it wouldn't at all be weird to think of it as a stack pointer to access (and pop) the parameters - and when all parameters are removed it holds the return address.
*2 - MLI or Machine Language Interface in ProDOS lingo. Here the JSR to $BF00, the ProDOS entry point, is followed by a byte defining the function call and a word holding the address of a parameter block for this function.
I do not know any specific name here. It was usually called a 'Parameter List'.
It may be due to the fact that this way was more or less the standard handling on many early systems supporting subroutine calls. The need of special names usually only arises when additional methods come into use.
Its inherent benefit is that no additional parameter register is needed, as the return address is stored in the link register, which can then double as a parameter list pointer, only to be advanced while processing, and at the end holding the return address (after the parameter list) (*1). For mainframe systems it was the standard calling convention.
Using the stack for return address handling is a rather new development - compared with parameter passing - but even then it was used quite a lot. Just think the way OS calls (*2) are made in Apple ProDOS.
*1 - In fact, it wouldn't at all be weird to think of it as a stack pointer to access (and pop) the parameters - and when all parameters are removed it holds the return address.
*2 - MLI or Machine Language Interface in ProDOS lingo. Here the JSR to $BF00, the ProDOS entry point, is followed by a byte defining the function call and a word holding the address of a parameter block for this function.
edited 7 hours ago
Community♦
1
1
answered yesterday
RaffzahnRaffzahn
52.8k6124213
52.8k6124213
add a comment |
add a comment |
John Källén is a new contributor. Be nice, and check out our Code of Conduct.
John Källén is a new contributor. Be nice, and check out our Code of Conduct.
John Källén is a new contributor. Be nice, and check out our Code of Conduct.
John Källén is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9328%2fdoes-the-in-code-argument-passing-conventions-used-on-pdp-11s-have-a-name%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
For common cases where code size would be more important than execution speed, including most uses variadic arguments, it would seem like code size could often have been reduced by having a generic "call function" function that would process encoded information stored immediately after the call itself which would describe the function and its arguments, reducing the size of code needed to supply them to the caller.
– supercat
yesterday
Note that on systems using split I/D address spaces, this calling convention may not work as expected, because the argument fetches will come from the Data space rather than from the Instruction space.
– Ken Gober
19 hours ago