Why does an instruction include the address of the next instruction on the IBM 650?
The IBM 650 seems to be a load-store machine. One advantage of a load-store machine is that the instruction can be shorter because there's less pressure to pack more information into it. But the IBM 650 has two addresses in each instruction: the operand, and the address of the next instruction.
Of course, after every instruction, the next one needs to be read from somewhere else. That's true of all stored-program computers. It's just that the obvious way to do that is to implement some kind of counter which implicitly gets incremented after each instruction, and then also may be used by the hardware as a pointer to fetch the next one. Then, if ever that value needs to be modified, well that's what jmp
is for.
The ... "interesting" approach of the IBM 650 means that jmp
is basically replaced by no-op
, and every instruction incurs the cost of specifying the address of the next instruction.
What is the use of this? Maybe they expected users to modify the next instruction field to allow for Real Goofy control flow (structured programming hadn't been invented yet, nor had GOTO Considered Harmful been written)? Or was the logic to increment and dereference a program counter not feasible for some reason?
ibm instruction-set
|
show 3 more comments
The IBM 650 seems to be a load-store machine. One advantage of a load-store machine is that the instruction can be shorter because there's less pressure to pack more information into it. But the IBM 650 has two addresses in each instruction: the operand, and the address of the next instruction.
Of course, after every instruction, the next one needs to be read from somewhere else. That's true of all stored-program computers. It's just that the obvious way to do that is to implement some kind of counter which implicitly gets incremented after each instruction, and then also may be used by the hardware as a pointer to fetch the next one. Then, if ever that value needs to be modified, well that's what jmp
is for.
The ... "interesting" approach of the IBM 650 means that jmp
is basically replaced by no-op
, and every instruction incurs the cost of specifying the address of the next instruction.
What is the use of this? Maybe they expected users to modify the next instruction field to allow for Real Goofy control flow (structured programming hadn't been invented yet, nor had GOTO Considered Harmful been written)? Or was the logic to increment and dereference a program counter not feasible for some reason?
ibm instruction-set
30
With IBM 650 using a rotating drum for memory, I'd imagine one of the advantages would be to allow Story of Mel-style optimizations where you could place the next instruction at the position the drum head would be once the previous one finished executing. Not sure if that's actually the reason, though, or just a side effect.
– Maciej Stachowski
Dec 11 '18 at 13:28
@MaciejStachowski You may be on to something there. But that problem would be much more easily addressed by interleaving the data on the drum, so that logically adjacent data get stored separately on the drum. The same way the disk sectors on a floppy disk are interleaved. That way, the medium is better at reading sequential data (but truly random access suffers).
– Wilson
Dec 11 '18 at 13:58
3
@Wilson You forget about instruction execution timing which is not the same on each and every instruction - also such a skew would screw linear data access - which (data access) is the next part that suffers from sequential execution.
– Raffzahn
Dec 11 '18 at 14:40
1
Interleaving would only work if execution times were uniform. Were they?
– Loren Pechtel
Dec 12 '18 at 15:28
1
@EamonnM.R. that story was ALREADY linked in the very first comment :-)
– Arioch
Dec 13 '18 at 9:36
|
show 3 more comments
The IBM 650 seems to be a load-store machine. One advantage of a load-store machine is that the instruction can be shorter because there's less pressure to pack more information into it. But the IBM 650 has two addresses in each instruction: the operand, and the address of the next instruction.
Of course, after every instruction, the next one needs to be read from somewhere else. That's true of all stored-program computers. It's just that the obvious way to do that is to implement some kind of counter which implicitly gets incremented after each instruction, and then also may be used by the hardware as a pointer to fetch the next one. Then, if ever that value needs to be modified, well that's what jmp
is for.
The ... "interesting" approach of the IBM 650 means that jmp
is basically replaced by no-op
, and every instruction incurs the cost of specifying the address of the next instruction.
What is the use of this? Maybe they expected users to modify the next instruction field to allow for Real Goofy control flow (structured programming hadn't been invented yet, nor had GOTO Considered Harmful been written)? Or was the logic to increment and dereference a program counter not feasible for some reason?
ibm instruction-set
The IBM 650 seems to be a load-store machine. One advantage of a load-store machine is that the instruction can be shorter because there's less pressure to pack more information into it. But the IBM 650 has two addresses in each instruction: the operand, and the address of the next instruction.
Of course, after every instruction, the next one needs to be read from somewhere else. That's true of all stored-program computers. It's just that the obvious way to do that is to implement some kind of counter which implicitly gets incremented after each instruction, and then also may be used by the hardware as a pointer to fetch the next one. Then, if ever that value needs to be modified, well that's what jmp
is for.
The ... "interesting" approach of the IBM 650 means that jmp
is basically replaced by no-op
, and every instruction incurs the cost of specifying the address of the next instruction.
What is the use of this? Maybe they expected users to modify the next instruction field to allow for Real Goofy control flow (structured programming hadn't been invented yet, nor had GOTO Considered Harmful been written)? Or was the logic to increment and dereference a program counter not feasible for some reason?
ibm instruction-set
ibm instruction-set
edited Dec 13 '18 at 2:41
Ben Crowell
1355
1355
asked Dec 11 '18 at 13:07
WilsonWilson
11.6k553133
11.6k553133
30
With IBM 650 using a rotating drum for memory, I'd imagine one of the advantages would be to allow Story of Mel-style optimizations where you could place the next instruction at the position the drum head would be once the previous one finished executing. Not sure if that's actually the reason, though, or just a side effect.
– Maciej Stachowski
Dec 11 '18 at 13:28
@MaciejStachowski You may be on to something there. But that problem would be much more easily addressed by interleaving the data on the drum, so that logically adjacent data get stored separately on the drum. The same way the disk sectors on a floppy disk are interleaved. That way, the medium is better at reading sequential data (but truly random access suffers).
– Wilson
Dec 11 '18 at 13:58
3
@Wilson You forget about instruction execution timing which is not the same on each and every instruction - also such a skew would screw linear data access - which (data access) is the next part that suffers from sequential execution.
– Raffzahn
Dec 11 '18 at 14:40
1
Interleaving would only work if execution times were uniform. Were they?
– Loren Pechtel
Dec 12 '18 at 15:28
1
@EamonnM.R. that story was ALREADY linked in the very first comment :-)
– Arioch
Dec 13 '18 at 9:36
|
show 3 more comments
30
With IBM 650 using a rotating drum for memory, I'd imagine one of the advantages would be to allow Story of Mel-style optimizations where you could place the next instruction at the position the drum head would be once the previous one finished executing. Not sure if that's actually the reason, though, or just a side effect.
– Maciej Stachowski
Dec 11 '18 at 13:28
@MaciejStachowski You may be on to something there. But that problem would be much more easily addressed by interleaving the data on the drum, so that logically adjacent data get stored separately on the drum. The same way the disk sectors on a floppy disk are interleaved. That way, the medium is better at reading sequential data (but truly random access suffers).
– Wilson
Dec 11 '18 at 13:58
3
@Wilson You forget about instruction execution timing which is not the same on each and every instruction - also such a skew would screw linear data access - which (data access) is the next part that suffers from sequential execution.
– Raffzahn
Dec 11 '18 at 14:40
1
Interleaving would only work if execution times were uniform. Were they?
– Loren Pechtel
Dec 12 '18 at 15:28
1
@EamonnM.R. that story was ALREADY linked in the very first comment :-)
– Arioch
Dec 13 '18 at 9:36
30
30
With IBM 650 using a rotating drum for memory, I'd imagine one of the advantages would be to allow Story of Mel-style optimizations where you could place the next instruction at the position the drum head would be once the previous one finished executing. Not sure if that's actually the reason, though, or just a side effect.
– Maciej Stachowski
Dec 11 '18 at 13:28
With IBM 650 using a rotating drum for memory, I'd imagine one of the advantages would be to allow Story of Mel-style optimizations where you could place the next instruction at the position the drum head would be once the previous one finished executing. Not sure if that's actually the reason, though, or just a side effect.
– Maciej Stachowski
Dec 11 '18 at 13:28
@MaciejStachowski You may be on to something there. But that problem would be much more easily addressed by interleaving the data on the drum, so that logically adjacent data get stored separately on the drum. The same way the disk sectors on a floppy disk are interleaved. That way, the medium is better at reading sequential data (but truly random access suffers).
– Wilson
Dec 11 '18 at 13:58
@MaciejStachowski You may be on to something there. But that problem would be much more easily addressed by interleaving the data on the drum, so that logically adjacent data get stored separately on the drum. The same way the disk sectors on a floppy disk are interleaved. That way, the medium is better at reading sequential data (but truly random access suffers).
– Wilson
Dec 11 '18 at 13:58
3
3
@Wilson You forget about instruction execution timing which is not the same on each and every instruction - also such a skew would screw linear data access - which (data access) is the next part that suffers from sequential execution.
– Raffzahn
Dec 11 '18 at 14:40
@Wilson You forget about instruction execution timing which is not the same on each and every instruction - also such a skew would screw linear data access - which (data access) is the next part that suffers from sequential execution.
– Raffzahn
Dec 11 '18 at 14:40
1
1
Interleaving would only work if execution times were uniform. Were they?
– Loren Pechtel
Dec 12 '18 at 15:28
Interleaving would only work if execution times were uniform. Were they?
– Loren Pechtel
Dec 12 '18 at 15:28
1
1
@EamonnM.R. that story was ALREADY linked in the very first comment :-)
– Arioch
Dec 13 '18 at 9:36
@EamonnM.R. that story was ALREADY linked in the very first comment :-)
– Arioch
Dec 13 '18 at 9:36
|
show 3 more comments
3 Answers
3
active
oldest
votes
Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:
It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.
To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.
Back to the question:
The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.
Using them to store the follow-up address improves things on several levels:
First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.
This in turn also implements jump instructions without any further effort.
On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.
And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.
The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.
Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).
Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.
In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.
Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.
*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".
*2 - And adding an incrementer for the PC.
*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.
*4 - Plus exceptions like Table Lookup with its very own timing issues.
*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.
1
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
add a comment |
If your primary memory is not random access, in the sense that at any instant some addressed words will take longer than others to be read, then you can potentially improve performance by having each instruction specify where the next instruction is located. The programmer is then coerced to figuring out where that next instruction ought to be.
This applies to any rotating memory, whether it's a drum surface or pulses in a mercury tank. The cost, as pointed out, was relatively low.
Instruction bits to some extent were not in short supply in those days, since memories were very small and expensive, so a memory address didn't need many bits.
Much programmer effort was spent on 'optimal programming', though Wilkes refused to countenance such a scheme for the EDSAC, rightly perceiving that this was just a temporary need until better memory technology arrived.
add a comment |
Yes, it WAS due to the fact that with a rotating drum memory, you wanted the next instruction to be at a location that was just about to come under the read/write heads rather than in the next sequential location, where it could take a full revolution of the drum to be able to read the instruction.
All was not lost for the programmer, however. The 650 came with the Symbolic Optimizing Assembly Program (SOAP) which arranged the instructions to the best advantage for you.
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
});
}
});
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%2f8515%2fwhy-does-an-instruction-include-the-address-of-the-next-instruction-on-the-ibm-6%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:
It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.
To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.
Back to the question:
The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.
Using them to store the follow-up address improves things on several levels:
First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.
This in turn also implements jump instructions without any further effort.
On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.
And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.
The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.
Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).
Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.
In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.
Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.
*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".
*2 - And adding an incrementer for the PC.
*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.
*4 - Plus exceptions like Table Lookup with its very own timing issues.
*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.
1
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
add a comment |
Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:
It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.
To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.
Back to the question:
The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.
Using them to store the follow-up address improves things on several levels:
First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.
This in turn also implements jump instructions without any further effort.
On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.
And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.
The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.
Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).
Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.
In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.
Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.
*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".
*2 - And adding an incrementer for the PC.
*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.
*4 - Plus exceptions like Table Lookup with its very own timing issues.
*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.
1
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
add a comment |
Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:
It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.
To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.
Back to the question:
The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.
Using them to store the follow-up address improves things on several levels:
First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.
This in turn also implements jump instructions without any further effort.
On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.
And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.
The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.
Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).
Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.
In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.
Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.
*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".
*2 - And adding an incrementer for the PC.
*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.
*4 - Plus exceptions like Table Lookup with its very own timing issues.
*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.
Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:
It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.
To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.
Back to the question:
The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.
Using them to store the follow-up address improves things on several levels:
First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.
This in turn also implements jump instructions without any further effort.
On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.
And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.
The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.
Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).
Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.
In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.
Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.
*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".
*2 - And adding an incrementer for the PC.
*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.
*4 - Plus exceptions like Table Lookup with its very own timing issues.
*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.
edited Dec 13 '18 at 11:52
Toby Speight
257212
257212
answered Dec 11 '18 at 14:29
RaffzahnRaffzahn
50.5k6119205
50.5k6119205
1
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
add a comment |
1
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
1
1
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
so basically it's the same reason old HDDs doesn't have consecutive sectors, since by the time the HDD finishes reading the sector the platter already rotates further than the next one
– phuclv
Dec 13 '18 at 12:41
add a comment |
If your primary memory is not random access, in the sense that at any instant some addressed words will take longer than others to be read, then you can potentially improve performance by having each instruction specify where the next instruction is located. The programmer is then coerced to figuring out where that next instruction ought to be.
This applies to any rotating memory, whether it's a drum surface or pulses in a mercury tank. The cost, as pointed out, was relatively low.
Instruction bits to some extent were not in short supply in those days, since memories were very small and expensive, so a memory address didn't need many bits.
Much programmer effort was spent on 'optimal programming', though Wilkes refused to countenance such a scheme for the EDSAC, rightly perceiving that this was just a temporary need until better memory technology arrived.
add a comment |
If your primary memory is not random access, in the sense that at any instant some addressed words will take longer than others to be read, then you can potentially improve performance by having each instruction specify where the next instruction is located. The programmer is then coerced to figuring out where that next instruction ought to be.
This applies to any rotating memory, whether it's a drum surface or pulses in a mercury tank. The cost, as pointed out, was relatively low.
Instruction bits to some extent were not in short supply in those days, since memories were very small and expensive, so a memory address didn't need many bits.
Much programmer effort was spent on 'optimal programming', though Wilkes refused to countenance such a scheme for the EDSAC, rightly perceiving that this was just a temporary need until better memory technology arrived.
add a comment |
If your primary memory is not random access, in the sense that at any instant some addressed words will take longer than others to be read, then you can potentially improve performance by having each instruction specify where the next instruction is located. The programmer is then coerced to figuring out where that next instruction ought to be.
This applies to any rotating memory, whether it's a drum surface or pulses in a mercury tank. The cost, as pointed out, was relatively low.
Instruction bits to some extent were not in short supply in those days, since memories were very small and expensive, so a memory address didn't need many bits.
Much programmer effort was spent on 'optimal programming', though Wilkes refused to countenance such a scheme for the EDSAC, rightly perceiving that this was just a temporary need until better memory technology arrived.
If your primary memory is not random access, in the sense that at any instant some addressed words will take longer than others to be read, then you can potentially improve performance by having each instruction specify where the next instruction is located. The programmer is then coerced to figuring out where that next instruction ought to be.
This applies to any rotating memory, whether it's a drum surface or pulses in a mercury tank. The cost, as pointed out, was relatively low.
Instruction bits to some extent were not in short supply in those days, since memories were very small and expensive, so a memory address didn't need many bits.
Much programmer effort was spent on 'optimal programming', though Wilkes refused to countenance such a scheme for the EDSAC, rightly perceiving that this was just a temporary need until better memory technology arrived.
answered Dec 11 '18 at 22:45
another-daveanother-dave
937110
937110
add a comment |
add a comment |
Yes, it WAS due to the fact that with a rotating drum memory, you wanted the next instruction to be at a location that was just about to come under the read/write heads rather than in the next sequential location, where it could take a full revolution of the drum to be able to read the instruction.
All was not lost for the programmer, however. The 650 came with the Symbolic Optimizing Assembly Program (SOAP) which arranged the instructions to the best advantage for you.
add a comment |
Yes, it WAS due to the fact that with a rotating drum memory, you wanted the next instruction to be at a location that was just about to come under the read/write heads rather than in the next sequential location, where it could take a full revolution of the drum to be able to read the instruction.
All was not lost for the programmer, however. The 650 came with the Symbolic Optimizing Assembly Program (SOAP) which arranged the instructions to the best advantage for you.
add a comment |
Yes, it WAS due to the fact that with a rotating drum memory, you wanted the next instruction to be at a location that was just about to come under the read/write heads rather than in the next sequential location, where it could take a full revolution of the drum to be able to read the instruction.
All was not lost for the programmer, however. The 650 came with the Symbolic Optimizing Assembly Program (SOAP) which arranged the instructions to the best advantage for you.
Yes, it WAS due to the fact that with a rotating drum memory, you wanted the next instruction to be at a location that was just about to come under the read/write heads rather than in the next sequential location, where it could take a full revolution of the drum to be able to read the instruction.
All was not lost for the programmer, however. The 650 came with the Symbolic Optimizing Assembly Program (SOAP) which arranged the instructions to the best advantage for you.
answered Dec 12 '18 at 14:05
JenniferJennifer
1911
1911
add a comment |
add a comment |
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%2f8515%2fwhy-does-an-instruction-include-the-address-of-the-next-instruction-on-the-ibm-6%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
30
With IBM 650 using a rotating drum for memory, I'd imagine one of the advantages would be to allow Story of Mel-style optimizations where you could place the next instruction at the position the drum head would be once the previous one finished executing. Not sure if that's actually the reason, though, or just a side effect.
– Maciej Stachowski
Dec 11 '18 at 13:28
@MaciejStachowski You may be on to something there. But that problem would be much more easily addressed by interleaving the data on the drum, so that logically adjacent data get stored separately on the drum. The same way the disk sectors on a floppy disk are interleaved. That way, the medium is better at reading sequential data (but truly random access suffers).
– Wilson
Dec 11 '18 at 13:58
3
@Wilson You forget about instruction execution timing which is not the same on each and every instruction - also such a skew would screw linear data access - which (data access) is the next part that suffers from sequential execution.
– Raffzahn
Dec 11 '18 at 14:40
1
Interleaving would only work if execution times were uniform. Were they?
– Loren Pechtel
Dec 12 '18 at 15:28
1
@EamonnM.R. that story was ALREADY linked in the very first comment :-)
– Arioch
Dec 13 '18 at 9:36