How to calculate byte offset in n-way associative cache - caching

From what I know this is the formula of address mapping to cache
| tag | index | offset |
However I'm wondering that how the offset is calculated
For example in the following exercise:
Give a CPU this 32 KB cache module as the following figure.
What is the bit length of tag? (how many tag bits ?)
Total address bit = 32 bits = Tag + Index + Block Offset + byte Offset
1024 sets = 2^10 => set index = 10 bits
Block size = 8 byte = 2^3 => byte offset = 3 bits
4 block/set = 2^2 => block offset = 2 bits
=> Tag = 32 – (10 + 3 + 2) = 17 bits
The offset contains Block Offset + byte Offset but in the link (in the an example catalog) the offset in the answer contain only byte offset not block offset
So do offset contains Block Offset + byte Offset or byte offset only

Related

Does go use something like space padding for structs? [duplicate]

This question already has answers here:
Sizeof struct in Go
(6 answers)
Closed 4 months ago.
I was playing around in go, and was trying to calculate and get the size of struct objects. And found something interesting, if you take a look at the following structs:
type Something struct {
anInteger int16 // 2 bytes
anotherInt int16 // 2 bytes
yetAnother int16 // 2 bytes
someBool bool // 1 byte
} // I expected 7 bytes total
type SomethingBetter struct {
anInteger int16 // 2 bytes
anotherInt int16 // 2 bytes
yetAnother int16 // 2 bytes
someBool bool // 1 byte
anotherBool bool // 1 byte
} // I expected 8 bytes total
type Nested struct {
Something // 7 bytes expected at first
completingByte bool // 1 byte
} // 8 bytes expected at first sight
But the result I got using unsafe.Sizeof(...) was as following:
Something -> 8 bytes
SomethingBetter -> 8 bytes
Nested -> 12 bytes, still, after finding out that "Something" used 8 bytes, though this might use 9 bytes
I suspect that go does something kind of like padding, but I don't know how and why it does that, is there some formula? Or logics? If it uses space padding, is it done randomly? Or based on some rules?
Yes, we have padding! if your system architecture is 32-bit the word size is 4 bytes and if it is 64-bit, the word size is 8 bytes. Now, what is the word size? "Word size" refers to the number of bits processed by a computer's CPU in one go (these days, typically 32 bits or 64 bits). Data bus size, instruction size, address size are usually multiples of the word size.
For example, suppose this struct:
type data struct {
a bool // 1 byte
b int64 // 8 byte
}
This struct it's not 9 bytes because, when our word size is 8, for first cycle, cpu reads 1 byte of bool and padding 7 bytes for others.
Imagine:
p: padding
+-----------------------------------------+----------------+
| 1-byte bool | p | p | p | p | p | p | p | int-64 |
+-----------------------------------------+----------------+
first 8 bytes second 8 bytes
For better performance, sort your struct items from bigger to small.
This is not good performance:
type data struct {
a string // 16 bytes size 16
b int32 // 4 bytes size 20
// 4 bytes padding size 24
c string // 16 bytes size 40
d int32 // 4 bytes size 44
// 4 bytes padding size 48 - Aligned on 8 bytes
}
Now It's better:
type data struct {
a string // 16 bytes size 16
c string // 16 bytes size 32
d int32 // 4 bytes size 36
b int32 // 4 bytes size 40
// no padding size 40 - Aligned on 5 bytes
}
See here for more examples.

Direct Mapping Cache

Consider the cache system with the following properties:
Cache (direct mapped cache):
- Cache size 128 bytes, block size 16 bytes (24 bytes)
- Tag/Valid bits for cache blocks are as follows:
Block index - 0 1 2 3 4 5 6 7
Tag - 0 6 7 0 5 3 1 3
Valid - 1 0 0 1 0 0 0 1
Find Tag Block index, Block offset, Cache hit/miss for memory addresses - 0x7f6, 0x133.
I am not sure how to solve.
Since cache size is 128 bytes, cache has 128/16 = 8 blocks and hence block offset = 3.
Since block size is 16 bytes, block offset is 4.
Address bits are 12 for 0x7f6 = 0111 1111 0110:
Offset = (0110 >> 1) = 3
Index = 111 = 7
Tag = 01111 = f

Maximum value of PCR

What is the maximum value of Program Clock Reference(PCR) in MPEG?
I understand that it is derived from a 27MHz clock, periodically loaded into a 42bit register.
PCR(i)=PCR_Base(i) * 300 + PCR_Ext(i)
where PCR_Base is loaded into a 33 bits register
PCR_Ext is loaded into a 9-bit register.
So, the maximum value of PCR w.r.t 27MHz clock is:
PCR = (2^33 - 1)*300 + (2^9 - 1) = 2,576,980,374,811.
=> (2,576,980,374,811/27,000,000) = 95443.7s = 1590.7 min = 26.5 hours
The register overflow happens after 26.5 hours of continuous streaming. Is this understanding correct?
PCR_ext(i) value should be 0 .. 299.
So the maximum PCR = (2^33-1)*300+299 = 2,576,980,377,599

how to compress the three bytes data into two bytes in java

I have to compress the 3 bytes of data in to two bytes.
the 3 bytes data includes day is in one byte,hour is in another byte, finally minutes is in one more byte.so totally i have 3 bytes data.how could i flip this data into two bytes only.
Thanks,
Minutes are ranging from 0 to 59 so the number could be stored on 6
bits (6 bits => 0 to 63)
Hours are ranging from 0 to 23 the number
could be stored on 5 bits (5 bits => 0 to 31)
Days... Err... Ranging from 0 to 6 ? Let's asusme that. 2 bytes = 16 bits, minus the 11
other bits, so you have 5 bits left which is more than enough.
To pack your 3 bytes of data into two, you have to dispatch the bits :
I will set bits 0 to 5 for the minutes, bits 6 to 10 for the hours, and the bits left for the day number.
So the formula to pack the bits is :
packed=minutes+hours*64+days*2048
To get back your uncompressed data :
minutes=packed & 63
hours=(packed & 1984) / 64
days=(packed & 63488) / 2048
I assume you need day from 1-31, hour from 0-23 and minute from 0-59, you thus need 5 bits for the day, 5 bits for the hours and 6 bits for the minutes. This makes exactly 16 bits. You should put 5 bits (day) and the first 3 bits for hours into your first byte and the remaining 2 bits for hours and the 6 bits for minutes into the second byte:
int day = 23;
int hour = 15;
int minute = 34;
byte fromint_dh = (day << 3) | (hour >> 2);
byte fromint_hm = ((hour & 0x03) << 6) | (minute); // take the last two bits from hour and put them at the beginning
....
int d = fromint_dh >> 3;
int h = ((fromint_dh & 0x07) << 2) | ((fromint_hm & 0xc0) >> 6); // take the last 3 bits of the fst byte and the fst 2 bits of the snd byte
int m = fromint_hm & 0x3F // only take the last 6 bits
Hope this helps. It's easy to get the bits wrong ...

Breaking a 32 bit integer into 8 bit chucks for Radix Sort

I am basically a beginner in Computer Science. Please forgive me if I ask elementary questions. I am trying to understand radix sort. I read that a 32 bit unsigned integer can be broken down into 4 8-bit chunks. After that, all it takes is "4 passes" to complete the radix sort. Can somebody please show me an example for how this breakdown (32 bit into 4 8-bit chunks) works? Maybe, a 32-bit integer like 2147507648.
Thanks!
You would divide the 32 bit integer up in 4 pieces of 8 bits. Extracting those pieces is a matter of using using some of the operators available in C.:
uint32_t x = 2147507648;
uint8_t chunk1 = x & 0x000000ff; //lower 8 bits
uint8_t chunk2 = (x & 0x0000ff00) >> 8;
uint8_t chunk3 = (x & 0x00ff0000) >> 16;
uint8_t chunk4 = (x & 0xff000000) >> 24; //highest 8 bits
2147507648 decimal is 0x80005DC0 hex. You an pretty much eyeball those 8 bits out of the hex representation, since each hex digit represents 4 bits, two and two of them represents 8 bits.
So that now means chunk 1 is 0xC0, chunk 2 is 0x5D, chunk3 is 0x00 and chunk 4 is 0x80
It's done as follows:
2147507648
=> 0x80005DC0 (hex value of 2147507648)
=> 0x80 0x00 0x5D 0xC0
=> 128 0 93 192
To do this, you'd need bitwise operations as nos suggested.

Resources