Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LSB to MSB order #351

Open
Rhialto opened this issue Jun 4, 2023 · 3 comments
Open

LSB to MSB order #351

Rhialto opened this issue Jun 4, 2023 · 3 comments

Comments

@Rhialto
Copy link

Rhialto commented Jun 4, 2023

On https://melsloop.com/docs/the-story-of-mel/pages/mels-hack-the-missing-bits in figure 7, you place the opcode bits at the least significant side of the word. Presumably because in figure 4, the "command" field is bits 0-4.

However, in early computing, bits were often counted the other way around: left to right, msb to lsb. Some modern CPU vendors still like to do that. The PowerPC documentation from IBM works like that. A quick google finds me https://cseweb.ucsd.edu/classes/sp06/cse240b/manuals/power4-1.pdf ; check chapter 1 page 7.

So it is certainly possible (even likely, I'd think) that the opcode bits are the most significant bits of the word.

Did you check how that influences the various theories about how the loop hack worked?

@imdfl
Copy link
Collaborator

imdfl commented Jun 6, 2023

Hi @Rhialto , thanks for the insightful comment.

IIUC, you're suggesting that when the manual refers to the magnitude bits, lower numbers refer to more significant bits, so bit 0 would be the most significant.
This seems in line with the bit layout in the RPC 4000 manual:

image

Given that it's customary to place the sign bit in the msb (though I don't know what the norm was at the time).

With this layout, incrementing the data address, as described in the story, would affect the opcode (command) in case of an "overflow".

image

However, I don't see how this would lead to the magic.

  • Since the next address bits are not affected in this scenario (there's no backward overflow...), the jump would have to occur by changing the code to TBC or TMI, or to 0 which is either HALT or SNS. As I understand the RPC-4000 manual, none of these options makes sense with the given bits. SNS would not jump because bits 5-11 are 0, TBC would not jump because there's been no overflow and nothing flipped on branch control and TMI would require too many coincidences with the data and operations.
  • The index register bit plays no role in this scenario (again, no backward overflow).

@e-basteln
Copy link

Bits 0 to 4 are indeed the most significant bits in the RPC-4000. While the Programming Manual and the Reference Manual don't state that explicitly, the Maintenance Manual does. See https://bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-4000_Maintenance_and_Training_Manual.pdf, section 1.4.1 (pages 1-8 to 1-9).

I agree that this corrected understanding of the bit order still does not provide a consistent technical explanation of Mel's hack as recounted by Ed Nather. But the discussion on https://melsloop.com/docs/the-story-of-mel/pages/mels-hack-the-missing-bits should nevertheless be corrected, since much of it (starting with the "Unpleasant Truth" section) is based on a misunderstanding.

@e-basteln
Copy link

I have looked into possible implementations of Mel's hack a bit further. I can offer some plausible -- although not entirely compelling -- scenarios, I think: https://www.e-basteln.de/computing/rpc4000/storyofmel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants