I have been having a great time with this series! You explain things so clearly I am looking forward to your other lectures once I finish this series. The RVALP text is an incredible resource. I am a computer engineering student now and I wish that I had a professor as entertaining as you are. I am not sure if I would have been able to grasp instruction encoding without your text and video, thank you.
WOW ! Surprised !! First, I am one of the authors of the PowerPC Embedded ABI. Yes, it was designed for embedded applications, so it is not a generalized as this ABI. Second I am very surprised that the load/store instruction only allow 4k of immediate offset. Some large embedded applications could easily have more than 4k atomic or compound variables (because it is embedded, many times most of the application data is declared globally; improves performance). In an embedded application, some variables may be constant (stored in ROM) and some maybe stored in RAM. Clearly another "global" pointer is required.
I guess their research suggested that reusing as much of the existing instruction decoding as they can was better than creating another instruction format. One can use a LUI before the load/store to get any 32-bit 4K multiple into another "base register" if you want absolute addressing.
RISC-V is clearly aimed at embedded application (IoT). I would like to see a comparison of this ABI and one specifically aimed at embedded applications. Clearly the linker must resolve the starting address of .text, .data, and .rodata.
Yes. The RISC-V instruction set is designed with the expectation that even the assembler will help out. The pseudoinstructions fill in the most annoying gaps in the instruction set. Yes, the linker plays a bit of a role too. Look at the pseudo instructions at the bottom of this page and their use of the linker relocation functions described here: github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md
First of all thank you for your quality content. I already watched your kicad hardware design tutorials a year ago and it was a blessing. This series is not different. I have a question however that I feel like it should be mentioned here as well. What if we call another subroutine from a subroutine. The value in ra would be lost if we follow the rv32 convention. The first subroutine wouldn't know where to return to after calling another subroutine. Normally you would store ra onto a stack or a saved register. Is there any special way to do it in a rv32 assembly?
I'm sorry if this seems like a stupid question, but I was confused about how you placed 10 into a0. Wouldn't you place the value 10 in a0 by using the instruction addi a0, x0, 10 or something similar rather than addi a0, 10(x0)?
You are right. I messed that up! ...and this is why you should look at the descriptions on TH-cam under any of my videos... I disclose mistakes there as they are brought to my attention.
@@JohnsBasement Great Vids, Thanks. Everyone makes mistakes. I like to look at these kinds of mistakes as opportunities for me to test if I'm paying attention. Also, it gives me a chance to see if/when I'm reading your RV32I Reference Card correctly. 👍👍😀😀
I always called it "green-bar." Other common names include "fan-fold" and "continuous form." I've seen it in green and blue. It comes in different sizes. The paper seen on my TH-cam channel is 8.5x15 inches. More common is 11x15. I use the shorter form because, a few years ago, someone was dumping it for next to nothing & I got a lifetime supply and it nicely matches the aspect ratio of a standard 16x9 HD camera. Of course, it has its own Wikipedia page: en.wikipedia.org/wiki/Continuous_stationery
You sent a link to a product asking if it is the same thing. TH-cam, apparently, doesn't always let us post links in the comments... I got mine from someone dumping cartons of it for $15. Try looking around if you want some. Maybe on ebay you can get a better price. Here is the size I use: a.co/d/7jozDxO (maybe this link will post?)
Kind of strange that yhe gunction arguments can't be all used for return values, considering they font need to be saved and the next function will overwrite them as nessesary. The calling function really shouldn't rely on its function arguments coming back, no? Seems a waste to go to memory.
Good question. I can imagine using a different return value reg can improve the performance of some kinds of recursive functions. But that hardly seems like the main reason for why it is the way it is.
I have been having a great time with this series! You explain things so clearly I am looking forward to your other lectures once I finish this series. The RVALP text is an incredible resource. I am a computer engineering student now and I wish that I had a professor as entertaining as you are. I am not sure if I would have been able to grasp instruction encoding without your text and video, thank you.
You are very welcome! Thank you for such kind words. 😀
Very good lecture. I almost yelled that "use pseudoinstructions!" but then noticed that they are introduced in the next one...
Thanks!
You are doing awesome work, John! Thanks for all RISC-V videos of yours.
Thanks for your positive review!
With your explanations, I feel like I understanding things. Of course, I have to actually do it to really understand it!
Glad to help!
WOW ! Surprised !!
First, I am one of the authors of the PowerPC Embedded ABI. Yes, it was designed for embedded applications, so it is not a generalized as this ABI.
Second I am very surprised that the load/store instruction only allow 4k of immediate offset. Some large embedded applications could easily have more than 4k atomic or compound variables (because it is embedded, many times most of the application data is declared globally; improves performance). In an embedded application, some variables may be constant (stored in ROM) and some maybe stored in RAM. Clearly another "global" pointer is required.
I guess their research suggested that reusing as much of the existing instruction decoding as they can was better than creating another instruction format.
One can use a LUI before the load/store to get any 32-bit 4K multiple into another "base register" if you want absolute addressing.
RISC-V is clearly aimed at embedded application (IoT). I would like to see a comparison of this ABI and one specifically aimed at embedded applications. Clearly the linker must resolve the starting address of .text, .data, and .rodata.
Yes. The RISC-V instruction set is designed with the expectation that even the assembler will help out. The pseudoinstructions fill in the most annoying gaps in the instruction set.
Yes, the linker plays a bit of a role too. Look at the pseudo instructions at the bottom of this page and their use of the linker relocation functions described here:
github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md
Thank you !
You're welcome!
First of all thank you for your quality content. I already watched your kicad hardware design tutorials a year ago and it was a blessing. This series is not different. I have a question however that I feel like it should be mentioned here as well. What if we call another subroutine from a subroutine. The value in ra would be lost if we follow the rv32 convention. The first subroutine wouldn't know where to return to after calling another subroutine. Normally you would store ra onto a stack or a saved register. Is there any special way to do it in a rv32 assembly?
Thank you.
This is correct. You'll want to push it on the stack with a store instruction.
You are a legend
🤣... Thank you!
Do you need to change the frame pointer also, when you call a subroutine?
If you are using a library that expects one, yes.
I'm sorry if this seems like a stupid question, but I was confused about how you placed 10 into a0. Wouldn't you place the value 10 in a0 by using the instruction addi a0, x0, 10 or something similar rather than addi a0, 10(x0)?
You are right. I messed that up!
...and this is why you should look at the descriptions on TH-cam under any of my videos... I disclose mistakes there as they are brought to my attention.
@@JohnsBasement Great Vids, Thanks.
Everyone makes mistakes. I like to look at these kinds of mistakes as opportunities for me to test if I'm paying attention. Also, it gives me a chance to see if/when I'm reading your RV32I Reference Card correctly.
👍👍😀😀
@@montpierce424Thanks! I try to fix these missteps before posting. But I don't always catch them all.
You need a second video explaining proper use of fp, and tp.
🤔 Probably not a bad idea.
What kind of paper is he using, at 9:50 ?
I always called it "green-bar." Other common names include "fan-fold" and "continuous form." I've seen it in green and blue. It comes in different sizes. The paper seen on my TH-cam channel is 8.5x15 inches. More common is 11x15. I use the shorter form because, a few years ago, someone was dumping it for next to nothing & I got a lifetime supply and it nicely matches the aspect ratio of a standard 16x9 HD camera.
Of course, it has its own Wikipedia page:
en.wikipedia.org/wiki/Continuous_stationery
You sent a link to a product asking if it is the same thing. TH-cam, apparently, doesn't always let us post links in the comments... I got mine from someone dumping cartons of it for $15. Try looking around if you want some. Maybe on ebay you can get a better price. Here is the size I use: a.co/d/7jozDxO (maybe this link will post?)
@@JohnsBasement Thanks
Kind of strange that yhe gunction arguments can't be all used for return values, considering they font need to be saved and the next function will overwrite them as nessesary. The calling function really shouldn't rely on its function arguments coming back, no? Seems a waste to go to memory.
Good question. I can imagine using a different return value reg can improve the performance of some kinds of recursive functions. But that hardly seems like the main reason for why it is the way it is.
u sound like warren buffet....
🤣