Please add pseudo instructions to the ref card

[chaoyangnz]

Thanks for your great work. This RISC-V assembly guide is invaluable for the beginners. Just a request to add the pseudo instructions for reference.

[johnwinans]

Thank you for the kind words. I will increase the priority on adding them on my TODO list.
What do you have in mind:

• A table in the reference card section?
• A narrative somewhere?

[chaoyangnz]

A table appended at reference card with some brief description should be helpful.

Another thing not relevant to pseudo instructions is the instructions encoding (assembly) process. Currently the instructions decoding mapping diagrams are very clear. If we have the another diagram to visualize the encoding, that is better.
For example, LUI t1, 0x123456, how the assembler extract 0x123456 (it’s more than 20 bits) to imm[12:31] is not too clear. The same thing: ADDI t1, x0, 0x12345

[johnwinans]

I agree that the encoding does not make sense for pseudo-ops. I'll find a place for a table like the one in the ISA spec. Hmmm... Are you looking at the latest release? If you click on the I-Type, J-Type, etc. there is a picture showing exactly what bits are used for which parts of the immediate values. Is there some other diagram or notation that you think is better? Please share. Thank you,

…

-John Winans

On 4/3/20 5:11 PM, Chao Yang wrote: A table appended at reference card with some brief description should be helpful. Another thing not relevant to pseudo instructions is the instructions encoding (assembly) process. Currently the instructions decoding mapping diagrams are very clear. If we have the another diagram to visualize the encoding, that is better. For example, LUI t1, 0x123456, how the assembler extract 0x123456 (it’s more than 20 bits) to imm[12:31] is not too clear. The same thing: ADDI t1, x0, 0x12345 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQ6H76SCX2QSNFVK3B6JA3RKZNI3ANCNFSM4L3P5ROQ>.

[chaoyangnz]

Sorry for my bad description. All the diagrams and notations currently used are good. But all the explanations are instruction-centric , I mean you decode the binary as instructions which is assembled already. But our assembly coder may understand from the perspective of assembly statements, my example LUI t1, 0x123456, how this statement is assembled into the instruction binary, I am not clear, as I have different understanding how 0x123456 will fill the higher 20bits of a U-type format. On Sat, 4 Apr 2020 at 11:23 AM, John Winans <[email protected]> wrote:

I agree that the encoding does not make sense for pseudo-ops. I'll find a place for a table like the one in the ISA spec. Hmmm... Are you looking at the latest release? If you click on the I-Type, J-Type, etc. there is a picture showing exactly what bits are used for which parts of the immediate values. Is there some other diagram or notation that you think is better? Please share. Thank you, -John Winans On 4/3/20 5:11 PM, Chao Yang wrote: > A table appended at reference card with some brief description should be > helpful. > > Another thing not relevant to pseudo instructions is the instructions > encoding (assembly) process. Currently the instructions decoding mapping > diagrams are very clear. If we have the another diagram to visualize the > encoding, that is better. > For example, LUI t1, 0x123456, how the assembler extract 0x123456 (it’s > more than 20 bits) to imm[12:31] is not too clear. The same thing: ADDI > t1, x0, 0x12345 > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#1 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ABQ6H76SCX2QSNFVK3B6JA3RKZNI3ANCNFSM4L3P5ROQ >. > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDODU47RF3HP65SMQQPB33RKZOUZANCNFSM4L3P5ROQ> .

-- Regards, Chao Yang (from Gmail mobile)

[johnwinans]

I like your idea. But I'm not immediately clear on how to go about it. Do you have an example of a method you think would be good to present the encoding concepts? I assumed that the diagrams in section 5.3 with the arrows were easy to mentally reverse. Since the LUI is just shifted to the left I'm not sure how to do it more justice than the same diagram with the arrows pointing the other way around. Maybe a discussion on how the li pseudo op uses instructions like lui, addi and shift to construct large values out of immediate values would help set a stage for this material? If you have any ideas or URLs of something similar that we can use for a model of approaching the problem, please share.

…

-John

On 4/3/20 5:40 PM, Chao Yang wrote: Sorry for my bad description. All the diagrams and notations currently used are good. But all the explanations are instruction-centric , I mean you decode the binary as instructions which is assembled already. But our assembly coder may understand from the perspective of assembly statements, my example LUI t1, 0x123456, how this statement is assembled into the instruction binary, I am not clear, as I have different understanding how 0x123456 will fill the higher 20bits of a U-type format. On Sat, 4 Apr 2020 at 11:23 AM, John Winans ***@***.***> wrote: > I agree that the encoding does not make sense for pseudo-ops. I'll find > a place for a table like the one in the ISA spec. > > Hmmm... Are you looking at the latest release? If you click on the > I-Type, J-Type, etc. there is a picture showing exactly what bits are > used for which parts of the immediate values. > > Is there some other diagram or notation that you think is better? > Please share. > > > Thank you, > > -John Winans > > > On 4/3/20 5:11 PM, Chao Yang wrote: > > A table appended at reference card with some brief description should be > > helpful. > > > > Another thing not relevant to pseudo instructions is the instructions > > encoding (assembly) process. Currently the instructions decoding mapping > > diagrams are very clear. If we have the another diagram to visualize the > > encoding, that is better. > > For example, LUI t1, 0x123456, how the assembler extract 0x123456 (it’s > > more than 20 bits) to imm[12:31] is not too clear. The same thing: ADDI > > t1, x0, 0x12345 > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > <#1 (comment)>, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/ABQ6H76SCX2QSNFVK3B6JA3RKZNI3ANCNFSM4L3P5ROQ > >. > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#1 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABDODU47RF3HP65SMQQPB33RKZOUZANCNFSM4L3P5ROQ> > . > -- Regards, Chao Yang (from Gmail mobile) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQ6H76GYEFU6KWKRWGQ4WTRKZQVDANCNFSM4L3P5ROQ>.

[chaoyangnz]

Yes, will be perfect if describe how LI pseudo instruction figure out the 32bits immediate. Anyway, thanks for your time to help me. I will let you know what I find out. On Sat, 4 Apr 2020 at 12:04 PM, John Winans <[email protected]> wrote:

I like your idea. But I'm not immediately clear on how to go about it. Do you have an example of a method you think would be good to present the encoding concepts? I assumed that the diagrams in section 5.3 with the arrows were easy to mentally reverse. Since the LUI is just shifted to the left I'm not sure how to do it more justice than the same diagram with the arrows pointing the other way around. Maybe a discussion on how the li pseudo op uses instructions like lui, addi and shift to construct large values out of immediate values would help set a stage for this material? If you have any ideas or URLs of something similar that we can use for a model of approaching the problem, please share. -John On 4/3/20 5:40 PM, Chao Yang wrote: > Sorry for my bad description. > > All the diagrams and notations currently used are good. > > But all the explanations are instruction-centric , I mean you decode the > binary as instructions which is assembled already. But our assembly coder > may understand from the perspective of assembly statements, my example LUI > t1, 0x123456, how this statement is assembled into the instruction binary, > I am not clear, as I have different understanding how 0x123456 will fill > the higher 20bits of a U-type format. > > On Sat, 4 Apr 2020 at 11:23 AM, John Winans ***@***.***> > wrote: > > > I agree that the encoding does not make sense for pseudo-ops. I'll find > > a place for a table like the one in the ISA spec. > > > > Hmmm... Are you looking at the latest release? If you click on the > > I-Type, J-Type, etc. there is a picture showing exactly what bits are > > used for which parts of the immediate values. > > > > Is there some other diagram or notation that you think is better? > > Please share. > > > > > > Thank you, > > > > -John Winans > > > > > > On 4/3/20 5:11 PM, Chao Yang wrote: > > > A table appended at reference card with some brief description > should be > > > helpful. > > > > > > Another thing not relevant to pseudo instructions is the instructions > > > encoding (assembly) process. Currently the instructions decoding > mapping > > > diagrams are very clear. If we have the another diagram to > visualize the > > > encoding, that is better. > > > For example, LUI t1, 0x123456, how the assembler extract 0x123456 (it’s > > > more than 20 bits) to imm[12:31] is not too clear. The same thing: ADDI > > > t1, x0, 0x12345 > > > > > > — > > > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub > > > <#1 (comment) >, > > > or unsubscribe > > > < > > > https://github.com/notifications/unsubscribe-auth/ABQ6H76SCX2QSNFVK3B6JA3RKZNI3ANCNFSM4L3P5ROQ > > >. > > > > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > <#1 (comment)>, or > > unsubscribe > > > < https://github.com/notifications/unsubscribe-auth/ABDODU47RF3HP65SMQQPB33RKZOUZANCNFSM4L3P5ROQ > > > . > > > -- > Regards, > Chao Yang > (from Gmail mobile) > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#1 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ABQ6H76GYEFU6KWKRWGQ4WTRKZQVDANCNFSM4L3P5ROQ >. > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDODUZ42SKPAAVKJBDKRFTRKZTPHANCNFSM4L3P5ROQ> .

-- Regards, Chao Yang (from Gmail mobile)