Suppose I have a variable inst which holds an encoded MIPS instruction. I want to set the rt field to 0 without changing the other fields. The rt field is a 5-bit field indexed from 16-20. I first tried:
inst = inst & ~(1 << 16);
which sets the rt field to 0. Then I want to put the value of a new variable new_reg into the rt field. I tried:
inst = inst | (new_reg << 16);
Could anyone confirm whether these two lines of code are correct?
I believe the problem is with your first bitmask. The command (1 << 16) only masks the first bit, where you want to mask all of the bits from 16-20. Try:
inst = inst & ~(0x3f << 16)
Then:
inst = inst | (new_reg << 16);
Related
I am working with small/basic bare-metal Hypervisor set-up that starts in EL2, and later on switches to EL1 where
I have MMU set-up (using stage 1 translation) which is working. For instance the following snippet that sets-up the table.
```
uint64_t *l1_table = ((load_addr) + SZ_1M);
#if 1
/* Only one table (which is at level 1) is used, that just shows
* with one table we can map 1GB of address space, where VA == PA
*/
l1_table[0] = (uint64_t)0x0000000;
l1_table[0] |= PT_BLOCK | PT_KERNEL | PT_AF;
l1_table[0] |= (MT_DEVICE << 2);
l1_table[1] = (uint64_t)0x40000000;
l1_table[1] |= PT_BLOCK | PT_AF | PT_KERNEL;
l1_table[1] |= (MT_NORMAL << 2);
#endif
I wanted to set-up stage 2 translation, where I would like to use IPA from stage 1 as an input to stage 2 translation table.
I guess, tables for stage 2 translation needed to be set-up while control is in EL2 but I don't
understand how to fetch IPA generated during stage 1 for stage 2 translation, and how table structure would look like for stage 2.
Are the PTEs for stage 2 table is based on IPA generated during stage 1 of stage 2 translation?
I have seen something like this in some of my coworkers code today :
I2C1ADB1= (slave_read_address | 0x01);
What does this | 0x01 part do? Does it end 1 at the end of the bits?
Let's say I2C1ADB1=0b00000000. If I use above line, will the new I2C1ADB1 be 0b000000001? Will it also increase the bit count from 8 to 9?
'|' is bit-wise OR operator in C. It does bit-wise OR between two values and return the final value.
I2C1ADB1= (slave_read_address | 0x01);
Assume slave_read_address in binary is 0bxxxxxxxx where each x is bit value 1 or 0. Similarly, 0x01 in binary is 0x00000001.
As you know OR will return true (1) if at least one of the value is true (1). Otherwise returns false (0).
So After the above C line, I2C1ADB1 will have 0bxxxxxxx1.
The operator will not ADD bits. Usually '|' (OR) operator is used to set a particular set of bits without altering other bits.
The statement I2C1ADB1 = (slave_read_address | 0x01); stores the value of slave_read_address into I2C1ADB1, forcing the low order bit to 1.
Your interpretation is incorrect, the value is not shifted, no extra bit is appended. The lowest bit is set to 1:
0 becomes 1,
1 is unchanged,
2 becomes 3,
3 does not change,
4 becomes 5,
etc.
Because on the left you have a variable and on the right a constant the result is to set all the corresponding 1 bits from the constant in the variable. In this case you’re right: it sets the last bit. No bit count increase occur!
How can I switch the certain bits of a number? For example, given bit representation (just an example, the syntax is surely wrong!):
someNumber = 00110111
changeNumber = 11100110
Then how can I change the far right bit of someNumber with the far right bit of the changeNumber without changing the rest bits of the someNumber? So the result would be:
00110111 //someNumber
11100110 //changeNumber
________
00110110
Extract the far right bit of changeNumber:
changeNumber & 1
Remove the far right bit of someNumber:
someNumber & ~1
And OR them together:
(changeNumber & 1) | (someNumber & ~1)
To set bit n, change 1 to 2n.
One a similar line as Martin,
Test the last bit of someNumber, and use the result to select the operation to change some number ('bitwise and' or 'bitwise or')
#DEFINE SWITCH_MASK_OR 0b00000001
#DEFINE SWITCH_MASK_AND (~SWITCH_MASK_OR)
...
result = changeNumber & SWITCH_MASK_OR ? \
someNumber | SWITCH_MASK_OR : someNumber & SWITCH_MASK_AND;
I suggest the following steps:
Clear the last bit of someNumber.
someNumber &= ~1
Extract the last bit of changeNumber
int lastBit = changeNumber & 1;
Set the last bit of someNumber:
someNumber |= lastBit;
AND the changenumber with a mask of 00000001, so extracting the state of the lowest bit, all others set to 0: 00000000
AND the somenumber with a mask of 11111110, so setting the lowest bit to 0 while leaving the rest unchanged: 00110110
OR the two results together, so : 00110110
What I have done is awfully heavy on the preprocessor. MinGW takes a minute or 2 to compile it, but it does pass unit tests; Eclipse is struggling and pops up a Java heap low, or eventually overflow. My question is there a way to make this easier for the preprocessor? Shall I just increase my Java heap? Or is there a better way to populate a table at compile time
Here it is:
I have created a CRC look up table and decided to populate it at compile time (key word: compile time), and didn't want to hard code any numbers. So I came up with a macro to calculate CRC, only hard coding the polynomial. (perhaps slightly hard to read, but it passes unit tests)
// Define CRC polynomial
#define POLYNOMIAL (0x8005)
#define CRC_1ITERATION(crc) ( \
(((crc)&0x7FFF)<<1)^( ((crc)&0x8000)?POLYNOMIAL:0 ) )
And then propagated it to 16 iterations... a re-invocation of the macro 16 iterations deep!
// Iterate the CRC polynomial
#define CRC_2ITERATIONS(crc) CRC_1ITERATION( CRC_1ITERATION(crc) )
#define CRC_4ITERATIONS(crc) CRC_2ITERATIONS( CRC_2ITERATIONS(crc))
#define CRC_8ITERATIONS(crc) CRC_4ITERATIONS( CRC_4ITERATIONS(crc))
#define CRC_16ITERATIONS(crc) CRC_8ITERATIONS( CRC_8ITERATIONS(crc))
CRC_16ITERATIONS() is now something I can invoke to transition an input CRC to it's output 16 iterations later. I use this to populated my table. Actually, I made even more nested macros to populate the table, but to keep things simple this code is enough to make Eclipse struggle:
// Populate the table (EDIT: corrected spelling)
CRC_16ITERATIONS(0), CRC_16ITERATIONS(1), CRC_16ITERATIONS(2), CRC_16ITERATIONS(3),
CRC_16ITERATIONS(4), CRC_16ITERATIONS(5), CRC_16ITERATIONS(6), CRC_16ITERATIONS(7),
CRC_16ITERATIONS(8), CRC_16ITERATIONS(9), CRC_16ITERATIONS(10), CRC_16ITERATIONS(11),
CRC_16ITERATIONS(12), CRC_16ITERATIONS(13), CRC_16ITERATIONS(14), CRC_16ITERATIONS(15)
It worked in MinGW including passing unit tests but like I said, I think I'm blowing some sort of parenthesis or macro expansion stack in Java/Eclipse. I was hoping to scale this up to a 256 entry table but I suspect MinGW will take a half-hour to compile it.
The first eight iterations just shift the byte up eight places. You can do that in the argument, and use CRC_8ITERATIONS instead of CRC_16ITERATIONS (which by the way you misspelled it CRC_16ITERATION several times).
I.e.:
CRC_8ITERATIONS(0), CRC_8ITERATIONS(1 << 8), CRC_8ITERATIONS(2 << 8), CRC_8ITERATIONS(3 << 8),
CRC_8ITERATIONS(4 << 8), CRC_8ITERATIONS(5 << 8), CRC_8ITERATIONS(6 << 8), CRC_8ITERATIONS(7 << 8),
CRC_8ITERATIONS(8 << 8), CRC_8ITERATIONS(9 << 8), CRC_8ITERATIONS(10 << 8), CRC_8ITERATIONS(11 << 8),
CRC_8ITERATIONS(12 << 8), CRC_8ITERATIONS(13 << 8), CRC_8ITERATIONS(14 << 8), CRC_8ITERATIONS(15 << 8)
That compiles about 256 times faster for me than using CRC_16ITERATIONS.
For just that particular set, I can go faster still by initially shifting up those four zeros at the top, and using CRC_4ITERATIONS. I.e.:
CRC_4ITERATIONS(0), CRC_4ITERATIONS(1 << 12), CRC_4ITERATIONS(2 << 12), CRC_4ITERATIONS(3 << 12),
CRC_4ITERATIONS(4 << 12), CRC_4ITERATIONS(5 << 12), CRC_4ITERATIONS(6 << 12), CRC_4ITERATIONS(7 << 12),
CRC_4ITERATIONS(8 << 12), CRC_4ITERATIONS(9 << 12), CRC_4ITERATIONS(10 << 12), CRC_4ITERATIONS(11 << 12),
CRC_4ITERATIONS(12 << 12), CRC_4ITERATIONS(13 << 12), CRC_4ITERATIONS(14 << 12), CRC_4ITERATIONS(15 << 12)
That compile time was too fast for me to measure.
I can take it further, add a CRC_3ITERATIONS, and do this:
0, CRC_1ITERATION(1 << 15), CRC_2ITERATIONS(2 << 14), CRC_2ITERATIONS(3 << 14),
CRC_3ITERATIONS(4 << 13), CRC_3ITERATIONS(5 << 13), CRC_3ITERATIONS(6 << 13), CRC_3ITERATIONS(7 << 13),
CRC_4ITERATIONS(8 << 12), CRC_4ITERATIONS(9 << 12), CRC_4ITERATIONS(10 << 12), CRC_4ITERATIONS(11 << 12),
CRC_4ITERATIONS(12 << 12), CRC_4ITERATIONS(13 << 12), CRC_4ITERATIONS(14 << 12), CRC_4ITERATIONS(15 << 12)
You could use this trick on the first 128 bytes to only iterate as many times as needed with CRC_7ITERATIONS, CRC_6ITERATIONS, etc. The last 128 bytes will all need to use CRC_8ITERATIONS, which is still pretty fast. At least for me using clang llvm 3.5.
Though I prefer just running a separate program to generate a file to include that has the table in it.
How do you concatenate bits in VHDL? I'm trying to use the following code:
Case b0 & b1 & b2 & b3 is
...
and it throws an error
Thanks
The concatenation operator '&' is allowed on the right side of the signal assignment operator '<=', only
You are not allowed to use the concatenation operator with the case statement. One possible solution is to use a variable within the process:
process(b0,b1,b2,b3)
variable bcat : std_logic_vector(0 to 3);
begin
bcat := b0 & b1 & b2 & b3;
case bcat is
when "0000" => x <= 1;
when others => x <= 2;
end case;
end process;
Here is an example of concatenation operator:
architecture EXAMPLE of CONCATENATION is
signal Z_BUS : bit_vector (3 downto 0);
signal A_BIT, B_BIT, C_BIT, D_BIT : bit;
begin
Z_BUS <= A_BIT & B_BIT & C_BIT & D_BIT;
end EXAMPLE;