# Thread: Indirect Addressing uses how many bits?

1. ## Indirect Addressing uses how many bits?

Hi guys,

I got 2 questions, hope you won't find it stupid....

1) How many bits does indirect addressing use? Is it 30 bits? Even though it is allocated 32 bits?

2) Is there a thing called secondary memory algorithms? If so, is there any example?

2. Originally Posted by franziss
1) How many bits does indirect addressing use? Is it 30 bits? Even though it is allocated 32 bits?
If you mean "how big is a pointer" then the answer is "it depends". For example, I believe 32-bit x86 code uses 32-bit pointers, but 64-bit IA64 code uses 64-bit pointers.
Originally Posted by franziss
2) Is there a thing called secondary memory algorithms? If so, is there any example?
Huh? Could you give an example of what you're looking for?

3. Is there a thing called secondary memory algorithms? If so, is there any example?

4. Er... I'm totally blur about secondary memory algorithms. This phase is given to me by a professor and I dare not keep mailing him questions, I'm afraid he might be irritated by me....

Thus, I post it on this forum...

5. Originally Posted by franziss
Hi guys,

I got 2 questions, hope you won't find it stupid....

1) How many bits does indirect addressing use? Is it 30 bits? Even though it is allocated 32 bits?

2) Is there a thing called secondary memory algorithms? If so, is there any example?

i might be making this up, but i think the processor uses 36 bits...4 for the segment address and 32 for the offest address.

6. This is on the C board, why again?

Quzah.

7. Sounds like your professor might be talking about virtual memory and/or caching algorithms.

8. That sounds possible. Though I do wonder why someone in such and advanced class can't articulate a bit better.

9. Originally Posted by franziss
Er... I'm totally blur about secondary memory algorithms. This phase is given to me by a professor and I dare not keep mailing him questions, I'm afraid he might be irritated by me....

Thus, I post it on this forum...
Traditionally, "secondary memory" refers to external storage on mainframes (9-track tape drives, magnetic drums, etc.) This is contrasted to "primary memory" which in contained in the CPU. Programs that need more memory than the amount of CPU "core memory" must store parts of the data base externally.

A sort algorithm specifically fine-tuned for a large data base in secondary storage may very well be different from a sort algorithm optimized for a smaller data base that can be contained in core.

For example some sorting algorithms require repeated access to elements near the first and near the last, whereas others require more accesses, but the accesses are more-or-less sequential. If the external storage has a large access time for elements that are not near each other (like tape drives), you really would like to see successive accesses more-or-less sequential.

With the advent of operating systems with virtual memory, (where large parts of programs and data bases are rapidly shifted between core and external memory in a way invisible to the programmer) the importance of the difference in such algorithms has pretty much been lost on most rank-and-file programmers, except as a mild historical oddity.

Regards,

Dave

Popular pages Recent additions