Can some one explain the math behind this.
2 RAMS
16-bits wide
16-bit words
32k 16 bit words is the maximum fill up of each.
How do I get the '32k 16-bit words' from the information provided?
While your question was nearly impossible to understand, I'll try to answer anyway:
32768 16-bit words makes 65536 bytes (8 bits per byte)
2^16 = 65536 = The number of bytes that can be addressed using a 16 bit address.
Related
I've searched around and found a thread referring to how to convert 32mb, and using the power-of-2 method. But I'm still not finding the correct answer.
I also have another followup question dealing with the similar problem:
Suppose you buy 64-bit PC with 1024 MB of RAM. What is the 16-hex digit address of the last byte of installed memory?
And I just can't seem to wrap my head around how to solve this logically.
I found that 512BM is a total of 29 bits on or 2^29. So in hex that is 1FFF FFFF. 1024 follows the same method so 2^30 which is 1073741823 or 3FFF FFFF converted to hex. Not really sure what it means by the 16-hex digit address since 1024MB is only 8 bits long. Also not sure what the 32 bit and 64 bit PCs have to do with this question.
A pointer in 64 bit architect takes 64 bits in memory. For every different value of the pointer points another byte, that means it can point one of different 2^64 addresses of bytes .
2^64 bytes = 2^54 kb = 2^44 mb = 2^34 gb = 2^24 Tb = 16777216 Tb
but none of rams even hard drives has such a big space.
So Why is it it? Couldn't pointers have been smaller? Or am I wrong?
sure they could be smaller...
basically if you have individually addressable bytes... then the whole RAM space needs to fit inside of the pointer address space.
so 32 bit supported up to 4GiB or 2GiB if there is a flag bit of some sort...
that isn't enough now for modern computing... the next size up could be 33, or 34, or 48... but 64-bit is now the native width... and no number greater than 32 divides into 64 more than once... so 64-bit (or 63 if you want one flag bit of some sort) makes pretty good sense
I know that the 1mb memory of 8086 is split into 16 logical sections but i only know about 4 such locations ,would anyone tell about the rest ?
I know that the 1mb memory of 8086 is split into 16 logical sections
I understand what you're saying but I'm afraid it's worse than that!
The 1MB memory has actually 65536 logical sections each overlapping the next by 65520 bytes. Your 16 logical sections are just special cases that happen to start at linear addresses divisable by 65536.
but i only know about 4 such locations
It's not clear what you mean by this but I think that you are referring to the segment registers CS, DS, ES, and SS. These are not locations as such but rather they each provide a pointer to any one of the forementioned sections. A linear address gets calculated by multiplying the appropiate segment register by 16 and then adding in the offset address. The result of this calculation is then truncated to have 20 bits only.
,would anyone tell about the rest ?
Simple enough. There's nothing else.
Suppose an analog audio signal is sampled 16,000 times per second, and each sample is quantized into one of 1024 levels. What would be the resulting bit rate of the PCM digital audio signal?
so that a question in Top down approach book , i answered it but just want to make sure it is correct
my answer is
1024 = 2 ^10
so PCM bit rate = 10 * 16000 = 160 , 000 bps
is that correct
Software often makes the trade off between time and space. Your answer is correct, however to write software you typically read/write data into storage units of bytes (8 bits). Since your answer says 10 bits, your code would use two bytes (16 bits) per sample. So the file consumption rate would be 16 * 160000 == 256000 bits per second (32000 bytes per second). This is mono so stereo would double this. Your software to actually store 10 bits per sample instead of 16 bits would shift this time/space trade-off in the direction of increased computational time (and code complexity) to save storage space.
I have to calculate and verify checksums for IP packets (I am writing a router in C). The struct that represents an IP header has a 16 bit checksum but the total number of bits in the struct is not evenly divisible by 16 -- it is 8 bits short.
My question is this. Do I read the struct 16 bits at a time and pad the last set of bits with zeroes to calculate the checksum?
If you had the wrong number of bits, you would pad zero bits to the end of the data.
However, IP calculates over the header fields and thus always has a multiple of 16 bits on which to calculate the checksum. TCP sometimes needs an extra byte of zero at the end of the data.
http://en.wikipedia.org/wiki/IPv4_header_checksum