RISC V manual confusion: instruction format VS immediate format - cpu-architecture

I have some question related the RISC V manual
It has different types of instruction encoding such as R-type,I-type.
Just like the MIPS encoding.
* R-type
31 25 24 20 19 15 14 12 11 7 6 0
+------------+---------+---------+------+---------+-------------+
| funct7 | rs2 | rs1 |funct3| rd | opcode |
+------------+---------+---------+------+---------+-------------+
* I-type
31 20 19 15 14 12 11 7 6 0
+----------------------+---------+------+---------+-------------+
| imm | rs1 |funct3| rd | opcode |
+----------------------+---------+------+---------+-------------+
* S-type
31 25 24 20 19 15 14 12 11 7 6 0
+------------+---------+---------+------+---------+-------------+
| imm | rs2 | rs1 |funct3| imm | opcode |
+------------+---------+---------+------+---------+-------------+
* U-type
31 11 7 6 0
+---------------------------------------+---------+-------------+
| imm | rd | opcode |
+---------------------------------------+---------+-------------+
But it also have something called immediate format:
such as I-immediate, S-immediate and so on
* I-immediate
31 10 5 4 1 0
+-----------------------------------------+-----------+-------+--+
| <-- 31 | 30:25 | 24:21 |20|
+-----------------------------------------+-----------+-------+--+
* S-immediate
31 10 5 4 1 0
+-----------------------------------------+-----------+-------+--+
| <-- 31 | 30:25 | 11:8 |7 |
+-----------------------------------------+-----------+-------+--+
* B-immediate
31 12 11 10 5 4 1 0
+--------------------------------------+--+-----------+-------+--+
| <-- 31 |7 | 30:25 | 11:8 |z |
+--------------------------------------+--+-----------+-------+--+
* U-immediate
31 30 20 19 12 11 0
+--+-------------------+---------------+-------------------------+
|31| 30:20 | 19:12 | <-- z |
+--+-------------------+---------------+-------------------------+
* J-immediate
31 20 19 12 11 10 5 4 1 0
+----------------------+---------------+--+-----------+-------+--+
| <-- 31 | 19:12 |20| 30:25 | 24:21 |z |
+----------------------+---------------+--+-----------+-------+--+
According to the manual, it say those immediate is produced by RISC-V instruction but how are the things related?
What is the point to have immediate format?

The 2nd set of diagrams is showing you how the immediate bits are concatenated and sign-extended into a 32-bit integer (so they can work as a source operand for normal 32-bit ALU instructions like addi which need both their inputs to be the same size).
For I-type instructions it's trivial, just arithmetic right-shift the instruction word by 20 bits, because there's only one immediate field, and it's contiguous at the top of the instruction word.
For S-type immediate instructions, there are two separate fields in the instruction word: [31:25] and [11:7], and this shows you that they're in that order, not [11:7, 31:25] and not with any implicit zeros between them.
B-type immediate instructions apparently put bit 7 in front of [30:25], and the low bit is an implicit zero. (So the resulting number is always even). I assume B-type is for branches.
U-type is also interesting, padding the 20-bit immediate with trailing zeros. It's used for lui to create the upper bits of 32-bit constants (with addi supplying the rest). It's not a coincidence that U-type and I-type together have 32 total immediate bits.
To access static data, lui can create the high part of an address while lw can supply the low part directly, instead of using an addi to create the full address in a register. This is typical for RISC ISAs like MIPS and PowerPC as well (see an example on the Godbolt compiler explorer). But unlike most other RISC ISAs, RISC-V has auipc which adds the U-type immediate to the program counter, for efficient PIC without having to load addresses from a GOT (global offset table). (A recent MIPS revision also added an add-to-PC instruction, but for a long time MIPS was quite bad at PIC).
lui can encode any 4k-aligned address, i.e. a page-start address with 4k pages.

Related

Different type of base 16?

Base 16 should go from 0 to F, with F being equal to 15 in base 10. But yet, when I use a base 16 converter found on google (https://www.hexator.com/) , it says that F is equal to 46.
Expected results:
0 | 0
1 | 1
2 | 2
3 | 3
4 | 4
5 | 5
6 | 6
7 | 7
8 | 8
9 | 9
a | 10
b | 11
c | 12
d | 13
e | 14
f | 15
Am I miss-interpreting something here?
That encoder is converting the ASCII value of the letter 'F' into the hexadecimal representation of it. The ASCII value of 'F' is 70, which is 46 when converted into hexadecimal. See this ascii table.
That converter is converting text into its hex representation, not Hex strings into decimal numbers.

Grafana visualisation of non time series data

I have two columns in my InfluxDB database : Values and Iterator count
I want visualise this on Grafana where my x axis is iterator count and value on y axis is basically corresponding to each iterator count.
EXAMPLE
Iterator Count(X) | Value
1 | 46
2 | 64
3 | 32
4 | 13
5 | 12
6 | 11
7 | 10
8 | 9
9 | 12
10 | 25.
Is it possible to achieve visualisation for the same, having no aspect of time
You can use plot.ly plugin
You just need to specify Iterator Count(X) as the x-axis in the trace section and Value as the y-axis.

llvm-cov fails to generate report when run on cloud GitLab CI

I have been running the following llvm-cov report command (which ships as part of the Swift toolchains) in Docker images (swift:5.1) on various environments.
BINARY_PATH="..."
PROF_DATA_PATH="..."
IGNORE_FILENAME_REGEX="..."
llvm-cov report \
$BINARY_PATH \
--format=text \
-instr-profile="$PROF_DATA_PATH" \
-ignore-filename-regex="$IGNORE_FILENAME_REGEX"
When the docker image is hosted on any machine aside from GitLab's cloud docker runners, I get the expected code coverage output:
Filename Regions Missed Regions Cover Functions Missed Functions Executed Lines Missed Lines Cover
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ChannelHandlers/RedisByteDecoder.swift 5 0 100.00% 3 0 100.00% 10 0 100.00%
ChannelHandlers/RedisCommandHandler.swift 15 5 66.67% 8 3 62.50% 45 11 75.56%
ChannelHandlers/RedisMessageEncoder.swift 3 1 66.67% 3 1 66.67% 13 6 53.85%
Commands/BasicCommands.swift 28 4 85.71% 16 2 87.50% 99 7 92.93%
Commands/HashCommands.swift 38 4 89.47% 29 1 96.55% 156 1 99.36%
Commands/ListCommands.swift 56 8 85.71% 48 5 89.58% 217 11 94.93%
Commands/SetCommands.swift 46 12 73.91% 30 4 86.67% 147 4 97.28%
Commands/SortedSetCommands.swift 172 19 88.95% 105 6 94.29% 555 18 96.76%
Commands/StringCommands.swift 23 2 91.30% 21 1 95.24% 100 1 99.00%
Extensions/StandardLibrary.swift 10 2 80.00% 6 1 83.33% 21 1 95.24%
Extensions/SwiftNIO.swift 9 1 88.89% 7 0 100.00% 38 1 97.37%
RESP/RESPTranslator.swift 69 7 89.86% 10 2 80.00% 172 10 94.19%
RESP/RESPValue.swift 39 11 71.79% 14 3 78.57% 69 17 75.36%
RESP/RESPValueConvertible.swift 52 19 63.46% 15 3 80.00% 99 22 77.78%
RedisClient.swift 2 0 100.00% 2 0 100.00% 7 0 100.00%
RedisConnection.swift 72 23 68.06% 47 10 78.72% 228 31 86.40%
RedisErrors.swift 12 4 66.67% 6 1 83.33% 23 3 86.96%
RedisKey.swift 15 9 40.00% 12 6 50.00% 38 20 47.37%
RedisMetrics.swift 9 2 77.78% 9 2 77.78% 23 2 91.30%
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL 675 133 80.30% 391 51 86.96% 2060 166 91.94%
However, when the same docker images running the same commands, are hosted with GitLab's cloud runners:
Filename Regions Missed Regions Cover Functions Missed Functions Executed Lines Missed Lines Cover
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL 0 0 - 0 0 - 0 0 -
I'm making sure that the code coverage data is provided correctly by the Swift Package Manager through ls -l and in every environment (including GitLab CI) I get:
Profdata: -rw-r--r--. 1 root root 575608 Feb 8 19:51 .build/x86_64-unknown-linux/debug/codecov/default.profdata
Test binary: -rwxr-xr-x. 1 root root 16309424 Feb 8 19:51 .build/x86_64-unknown-linux/debug/redi-stackPackageTests.xctest
This also happens with LLVM-8 and LLVM-9 (LLVM-7 ships w/ Swift 5.1)
For the life of me, I can't figure out why.
Environments I've tested (all running Docker Engine 19+):
+----------------+-----------------+----------------+-------------------+
| | | | |
| HOST | OS | CPU | Generates Report? |
| | | | |
+-----------------------------------------------------------------------+
| iMac 2011 | High Sierra | sandybridge | YES |
+-----------------------------------------------------------------------+
| MBP 2019 | Catalina | skylake | YES |
+-----------------------------------------------------------------------+
| mac mini 2018 | Catalina | skylake | YES |
+-----------------------------------------------------------------------+
| GitHub Actions | 'ubuntu|latest' | skylake|avx512 | YES |
+-----------------------------------------------------------------------+
| GitLab CI | 'tags: docker' | haswell | NO |
+----------------+-----------------+----------------+-------------------+
Relevant bug reports:
Swift
GitLab

formatting an AVC/H.264 mdat

Can anyone tell me or point me to a section of the specification(s) that clearly demonstrates how from an elementary stream with a series of NALUs how these should be written into a ISO BMFF mdat?
I can see looking at samples and other code that I should have something like: AUD, SPS, PPS, SEI, VideoSlice, AUD etc etc
Things that are not entirely clear to me:
If the SPS and PPS are also stored out of band in the AVCC are they required in the mdat?
If they are required in the mdat when/where should they be written? e.g. just prior to an IDR?
What is the requirement for AUDs?
If I am generating sample sizes for the trun is the calcuation for this? In the example I am working to recreate the first sample in the trun has a size of 22817 however if I look at the first sample in the mdat the NALU size prefix is 22678. The value in the trun appears to be the size of all the NALUs + sizes up to and including the first sample (see my example below)
>
1 0016E405 (1500165) - box.Size
2 6D646174 (mdat) - box.Type
3 00000002 (2) NAL Size
4 0910 - (2) AUD # 5187
5 00000025 (37)
6 27640020 AC248C0F 0117EF01 10000003 00100000 078E2800 0F424001 E84EF7B8 0F844229 C0 (37) # 5193 SPS
7 00000004 (4)
8 28DEBCB0 (4) PPS
9 0000000B (11)
10 06000781 36288029 67C080 (? SEI ?)
11 0000000C (12)
12 06010700 00F00000 03020480 (? SEI is type 6)
13 0000002D (45) # 5269
14 060429B5 00314741 393403CA FFFC8080 FA0000FA 0000FA00 00FA0000 FA0000FA 0000FA00 00FA0000 FA0000FF 80 (SEI ??)
15 00005896 (22678)
16 25888010 02047843 00580010 08410410 0002….. 22678 bytes video # 5322
If the SPS and PPS are also stored out of band in the AVCC are they required in the mdat?
No
If they are required in the mdat when/where should they be written? e.g. just prior to an IDR?
Yes, if you choose to include them, but there is no reason to
What is the requirement for AUDs?
They are optional
If I am generating sample sizes for the trun is the calcuation for this?
The number of bytes in the access unit (AU, aka frame). Which may contain more than one NALU. SPS/PPS/SEI/AUD all counted toward the AU size. The 4 byte size prefixed to each NALUs is also counted in the AU size recored in the trun.
bytes
4 | 3 00000002 (2) NAL Size
2 | 4 0910 - (2) AUD # 5187
4 | 5 00000025 (37)
37 | 6 27640020 AC248C0F 0117EF01 10000003 00100000 078E2800 0F424001 E84EF7B8 0F844229 C0 (37) # 5193 SPS
4 | 7 00000004 (4)
4 | 8 28DEBCB0 (4) PPS
4 | 9 0000000B (11)
11 | 10 06000781 36288029 67C080 (? SEI ?)
4 | 11 0000000C (12)
12 | 12 06010700 00F00000 03020480 (? SEI is type 6)
4 | 13 0000002D (45) # 5269
45 | 14 060429B5 00314741 393403CA FFFC8080 FA0000FA 0000FA00 00FA0000 FA0000FA 0000FA00 00FA0000 FA0000FF 80 (SEI ??)
4 | 15 00005896 (22678)
22678 | 16 25888010 02047843 00580010 08410410 0002….. 22678 bytes video # 5322
------|
22817 | <- bytes total

Need a Logic to say Bingo

I am creating an iphone app where I have a grid view of 25 images as:
0 1 2 3 4
5 6 7 8 9
10 11 12 13 14
15 16 17 18 19
20 21 22 23 24
Now when any 5 consecutive images are selected it should say bingo, like if 0,6, 12, 18, 24 are selected it should say Bingo.
How will i do that, please help me.
Many Thanks for your help.
Rs
iPhone Developer
-----------------------------------
| 0 | 1 | 2 | 3 | 4 | 5 |
-----------------------------------
| 6 | 7 | 8 | 9 | 10 | 11 |
-----------------------------------
| 12 | 13 | 14 | 15 | 16 | 17 |
-----------------------------------
| 18 | 19 | 20 | 21 | 22 | 23 |
-----------------------------------
| 24 |
-----------------------------------
Hope this is how your grid looks like.
Associate each column with an array. The array will contain the list of all neighbour elements of that column,
For example, the neighbor array of the column [ 6 ] will ollk like array(0, 7, 12), which are all the immediate neighbors of [ 6 ].
Set counter = 0;
Now, when someone clicks an element, increment the counter (Now counter = 1)
When he clicks the second element, check if the element is in the neighbor list of the previous element OR the 1st element.
If the element clicked is in the neighbor list, increment the counter (now counter = 2)
ELSE
If the element clicked is not in the neighbor array, reset the counter (counter = 0) and start over.
Check if the value of counter = 5. If it is, Say Bingo!
The algorithm is not fully correct, but I hope you got the idea :)