Floating-Point Rounding Modes

[ProfPierce]

I've been trying to understand the implementation of the floating-point instructions in RARS. It seems that for the computational instructions, a rounding mode must be specified as the fourth operand in the instruction. The language specification indicates that this is an optional field, and if not specified in the instruction, rounding defaults to the value contained in the frm field of the fcsr. It is recommended this field be 000 by default for Round to Nearest, ties to Even. If I don't include one of the valid mode options (dyn, rne, rtz, etc)., an error is produced from assembly stating pseudoinstructions aren't allowed. I have pseudoinstructions disabled because I want to use only basic instructions. Observing the fcsr register on the Control and Status tab, it appears the rounding mode is zero as I would expect. What am I missing? Is it the intention in RARS to require all instructions include explicit rounding modes as opposed to using the default in fcsr? Thank you for your time.

[TheThirdOne]

My understanding

For RARS assembly, if you want to use dynamic rounding in a floating point operation without using psuedo-instructions, you need to include using the rounding mode dyn. This fills the 3 RM bits in the instruction format with 0b111 which on execution gets the rounding mode from the frm CSR.

I think you may be misunderstanding dyn as something that specifies a rounding mode on its own, but instead you should think of it as the rounding mode that defers the frm rounding mode.

To give you a little context for what the psuedo-intructions used are the following is the definition of fmul.s without specifying a rounding mode. Essentially all it does is add , dyn on the end of the instruction.

fmul.s    f1, f2, f3     ; fmul.s    RG1, RG2, RG3, dyn     ;#Floating MULtiply: assigns f1 to f2 * f3

The reason why I don't allow rounding mode to be omitted without psuedo-instructions is partially a technical limitation which is the product of several design decisions (and one specification point).

• Two basic instructions cannot overlap their binary encoding
• Each basic instruction has only one assembly format that will produce it
• Psuedo-instructions use basic instructions through the same interface as normally written code.
• It must be possible to specify rounding mode.

The reason I have not tried to change any of those points is because psuedo-instructions only save you explicitly writing out the rounding mode and if you have psuedo-instructions disabled it probably means you want things to be explicit rather than implicit.

Action Items

Just using the rounding mode dyn should let you make programs that work as you intend. If you think that omitted rounding mode without psuedo-instructions should still be possible, I will need some convincing. Perhaps an alternative solution is that some simple psuedo-instructions could be allowed whereas more complex ones would not.

I would appreciate knowing your reasoning for wanting no psuedo-instructions. Most of them are quite simple, and mandated by the specification.

If you want a fuller explanation of how the technical points make it impossible to make am omitted rounding mode without psuedo-instructions possible, feel free to ask.

[ProfPierce]

Thank you for the excellent clarification and rationale! I appreciate the timely response as well. For my fall classes, I am switching from MIPS to RISC-V. I have been having my students use MARS since it provides an excellent IDE environment for learning assembly language. The switch to RISC-V using RARS will be quite easy and natural. I use the Patterson/Hennessy text books and even though they present the 64-bit version of RISC-V, the 32-bit version is based on the same design. The focus of my classes is on the architecture and organization concepts with assembly as the primary tool for learning the hardware/software interface. Your RARS project is greatly appreciated. Again, thanks. Bill Pierce Assistant Professor of Computer Science Hood College, Frederick, MD

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Monday, May 18, 2020 7:07 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Author <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. My understanding For RARS assembly, if you want to use dynamic rounding in a floating point operation without using psuedo-instructions, you need to include using the rounding mode dyn. This fills the 3 RM bits in the instruction format with 0b111 which on execution gets the rounding mode from the frm CSR. I think you may be misunderstanding dyn as something that specifies a rounding mode on its own, but instead you should think of it as the rounding mode that defers the frm rounding mode. To give you a little context for what the psuedo-intructions used are the following is the definition<https://github.com/TheThirdOne/rars/blob/3c970b95f271f9bfd4186b2999741fbd37db2fe2/src/PseudoOps.txt#L231> of fmul.s without specifying a rounding mode. Essentially all it does is add , dyn on the end of the instruction. fmul.s f1, f2, f3 ; fmul.s RG1, RG2, RG3, dyn ;#Floating MULtiply: assigns f1 to f2 * f3 The reason why I don't allow rounding mode to be omitted without psuedo-instructions is partially a technical limitation which is the product of several design decisions (and one specification point). * Two basic instructions cannot overlap their binary encoding * Each basic instruction has only one assembly format that will produce it * Psuedo-instructions use basic instructions through the same interface as normally written code. * It must be possible to specify rounding mode. The reason I have not tried to change any of those points is because psuedo-instructions only save you explicitly writing out the rounding mode and if you have psuedo-instructions disabled it probably means you want things to be explicit rather than implicit. Action Items Just using the rounding mode dyn should let you make programs that work as you intend. If you think that omitted rounding mode without psuedo-instructions should still be possible, I will need some convincing. Perhaps an alternative solution is that some simple psuedo-instructions could be allowed whereas more complex ones would not. I would appreciate knowing your reasoning for wanting no psuedo-instructions. Most of them are quite simple, and several as mandated by the specification. If you want a fuller explanation of how the technical points make it impossible to make am omitted rounding mode without psuedo-instructions possible, feel free to ask. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2M7QNZKOY7QNBYQSGTRSG5SVANCNFSM4NEH2MTA>.

[TheThirdOne]

I am glad that it has been helpful.

I use the Patterson/Hennessy text books and even though they present the 64-bit version of RISC-V, the 32-bit version is based on the same design.

I actually only learned that the Patterson/Hennessy book uses RV64 yesterday. I don't own a RISC-V copy and hadn't heard from anyone before about it.

Would RARS supporting RV64 be helpful? When initially porting RARS, I dismissed it because I thought it was not necessary, but recently I have been thinking about it more because professional tooling for RV32 is shaky and running programs compiled from C would be a nice feature.

I would certainly be open to adding an option to switch between RV32 and RV64 if there was interest.

[ProfPierce]

Both of the current versions of the textbooks authored by Patterson and Hennessy have incorporated RV64 as the primary architectural reference. I am sure this is because the predominant architectures in most all major technologies including mobile are now 64-bit. I feel that having a runtime simulator that directly supports the RISC-V 64-bit would be of great benefit for the students studying computer science and engineering. My school, Hood College, is a small liberal arts school and our computer science department is small. We don't have the capacity to invest in resources to provide hardware for students to get hands-on exposure to the technology. We've made minimal investments in a very small robotics lab to support AI and machine learning but everything else we do is software based. Emulators and simulators are the next best thing that the students can work with to understand the relationship of software to the underlying hardware. I don't know how much effort would be required to add a 64-bit version to the RARS product but I would adopt it in a heartbeat. I sometimes feel when explaining to my students that we're using a 32-bit simulator when all the technology they use is 64-bit is like taking them backwards. I am sure there are other instructors like me, especially who teach in small institutions, who would welcome a 64-bit version of the program. Thank you for asking for my input. Best wishes, Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Monday, May 18, 2020 9:05 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Author <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. I am glad that it has been helpful. I use the Patterson/Hennessy text books and even though they present the 64-bit version of RISC-V, the 32-bit version is based on the same design. I actually only learned that the Patterson/Hennessy book uses RV64 yesterday. I don't own a RISC-V copy and hadn't heard from anyone before about it. Would RARS supporting RV64 be helpful? When initially porting RARS, I dismissed it because I thought it was not necessary, but recently I have been thinking about it more because professional tooling for RV32 is shaky and running programs compiled from C would be a nice feature. I would certainly be open to adding an option to switch between RV32 and RV64 if there was interest. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2J3YDJJH4ZTC76W2L3RSHLNJANCNFSM4NEH2MTA>.

[TheThirdOne]

I just created another issue that will track progress on implementing RV64. Most of the work will come in the form of reading the specification closely to see how rv32 and rv64 differ. I might have it done before the fall, but don't count on it.

[ProfPierce]

That's great. I wouldn't put any deadlines on the project that might cause you to feel rushed. Work on it as your time allows. If you would like any help with testing, I would certainly be willing to contribute to that. I am perfectly fine with the RV32 implementation for the time being. Best wishes, Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Monday, May 18, 2020 10:32 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Author <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. I just created another issue that will track progress on implementing RV64. Most of the work will come in the form of reading the specification closely to see how rv32 and rv64 differ. I might have it done before the fall, but don't count on it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2KZ5YIJDPHLINVVFYDRSHVVLANCNFSM4NEH2MTA>.

[BenjaminBeichler]

I would also appreciate RV64 support, but I also use RARS since 2 years without it ;-) Unfortunately, I also have no capacity to support the development, except testing (even from my students).

👍

[TheThirdOne]

@ProfPierce and @BenjaminBeichler, I have finished the bulk of the work on the rv64 mode. A jar can be found at https://github.com/TheThirdOne/rars/releases/tag/pr78 . Let me know if something doesn't work correctly.

[BenjaminBeichler]

Nice! I will have a look, and report any problems I see.

[ProfPierce]

Many thanks for providing this. I've been doing some testing and have a scenario that I can't seem to figure out. I am defining a 53-bit double word using the .dword assembler directive, providing a value that could be represented in a 32-bit word. I would expect such a value to be sign extended to the 64-bit double word and loaded into a register as a 64-bit value using the ld instruction. However, this is not what I'm getting. The value is replicated in the upper 32 most significant bits rather than sign extended. I've attached a word doc with my test program and screen shots of data segment and register. Am I missing something or am I not understanding the 64-bit data definition and loads? Thank you. Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Sunday, June 21, 2020 3:58 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. @ProfPierce<https://github.com/ProfPierce> and @BenjaminBeichler<https://github.com/BenjaminBeichler>, I have finished the bulk of the work on the rv64 mode. A jar can be found at https://github.com/TheThirdOne/rars/releases/tag/pr78 . Let me know if something doesn't work correctly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2PZJSFSONM3DW4G673RXZQ5FANCNFSM4NEH2MTA>.

[TheThirdOne]

@ProfPierce, Your expectations are absolutely correct. You hit a bug in the .dword implementation; I didn't explicitly handle the case where the value fits in 32 bits and expected the other code to correctly handle it. I pushed a fix in af804a5. Thanks for pointing this out.

BTW, I can't see the attachment through the Github interface.

[ProfPierce]

Thank you. Working as expected now. I appreciate your efforts. I'll continue working with the program and let you know if I discover anything else. It really is a great tool. Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Tuesday, June 23, 2020 5:48 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. @ProfPierce<https://github.com/ProfPierce>, Your expectations are absolutely correct. You hit a bug in the .dword implementation; I didn't explicitly handle the case where the value fits in 32 bits and expected the other code to correctly handle it. I pushed a fix in af804a5<af804a5>. Thanks for pointing this out. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2J77ZT6MSCY6BZQMHLRYEPLVANCNFSM4NEH2MTA>.

[TheThirdOne]

I have updated the jar with the latest developments. It should be correct and complete aside from updates to system calls. Currently all of the system calls only consider the bottom 32 bits.

I am considering merging this in as is and not updating the system calls to go with it because I am feeling particularly demotivated to work on them and I would like to get out a new release before most school's semesters start.

[ProfPierce]

I am perfectly satisfied with the current version and have found no other issues in my working with the program. I don't know how to thank you enough for the work you have done and the time you have put into the software. I am grateful. Thank you. Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Wednesday, July 8, 2020 7:12 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. I have updated the jar with the latest developments. It should be correct and complete aside from updates to system calls. Currently all of the system calls only consider the bottom 32 bits. I am considering merging this in as is and not updating the system calls to go with it because I am feeling particularly demotivated to work on them and I would like to get out a new release before most school's semesters start. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2IN3OVVGK7LRX2QFTTR2T4PJANCNFSM4NEH2MTA>.

[BenjaminBeichler-Bot]

@TheThirdOne good job, I think it is also totally enough to put the info that syscalls only consider bottom 32 bits into the documentation and it is fine. It takes 3 lines to shift the upper part if needed for print, the "user" only needs to know.

[ProfPierce]

Hi Benjamin, I thought I would download the latest release which appears to be rars_b3afbbe.jar however it seems to be missing the RV64 instructions and directives in the help. I obtained rars_21bf74e on the 9th after getting your email and it seems to have everything. Is this the version I should continue using? Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Wednesday, July 8, 2020 7:12 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. I have updated the jar with the latest developments. It should be correct and complete aside from updates to system calls. Currently all of the system calls only consider the bottom 32 bits. I am considering merging this in as is and not updating the system calls to go with it because I am feeling particularly demotivated to work on them and I would like to get out a new release before most school's semesters start. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2IN3OVVGK7LRX2QFTTR2T4PJANCNFSM4NEH2MTA>.

[TheThirdOne]

@ProfPierce, If you are downloading from https://github.com/TheThirdOne/rars/releases/tag/continuous, that would not be the correct place to look. https://github.com/TheThirdOne/rars/releases/tag/pr78 would be the place to download from until I make a release for v1.5 which should happen sometime in the next two weeks.

The continuous release is an automatic thing, and I have made some mistakes in how I set it up that makes it more confusing than it should be. I committed a fix for #82 which triggered rebuilding the main branch without support for rv64. The pr78 release is manually updated by me and dedicated to providing a build until rv64 gets included into the master branch.

[ProfPierce]

Thank you for the clarification. Best wishes, Bill

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Sunday, July 12, 2020 10:52 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. @ProfPierce<https://github.com/ProfPierce>, If you are downloading from https://github.com/TheThirdOne/rars/releases/tag/continuous, that would not be the correct place to look. https://github.com/TheThirdOne/rars/releases/tag/pr78 would be the place to download from until I make a release for v1.5 which should happen sometime in the next two weeks. The continuous release is an automatic thing, and I have made some mistakes in how I set it up that makes it more confusing than it should be. I committed a fix for #82<#82> which triggered rebuilding the main branch without support for rv64. The pr78 release is manually updated by me and dedicated to providing a build until rv64 gets included into the master branch. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2IX6JABTRQDPTSO3F3R3JZFBANCNFSM4NEH2MTA>.

[TheThirdOne]

I just published the release that adds support for rv64 (https://github.com/TheThirdOne/rars/releases/tag/v1.5).

[ProfPierce]

Hi Benjamin, I happen to notice something that isn't a big deal but it had me scratching my head trying to figure our the doubleword assembler directive. You fixed the .dword definition so that all doublewords will occupy a full 8 bytes. If I define a sequence of dwords, they all start at dword boundaries in memory. However, if I define a word prior to a doubleword, the doubleword begins on the next word boundary rather than the next doubleword boundary. This matches your description in the help which states that the dword is allocated on the next word boundary. I was trying to find this in the spec and cannot. All the references to the .dword directive indicate they should begin at memory addresses that are 8-byte boundaries. Maybe you can help me out to understand if this is indeed the way it is supposed to work and reference me to this in the spec. This isn't a show stopper by any means and i can go with the current implementation. However, I would like some explanation to offer to my students who will come across this when working on assembly language projects. Thanks for your help. Best wishes, Bill Pierce

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Wednesday, July 15, 2020 12:13 AM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. I just published the release that adds support for rv64 (https://github.com/TheThirdOne/rars/releases/tag/v1.5). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2K52AL6KO5TFYQB32LR3UUG3ANCNFSM4NEH2MTA>.

[TheThirdOne]

I was trying to find this in the spec and cannot. All the references to the .dword directive indicate they should begin at memory addresses that are 8-byte boundaries. Maybe you can help me out to understand if this is indeed the way it is supposed to work and reference me to this in the spec.

I don't recall anything about assembler directives being mentioned anywhere in the RISC-V specification. As a general rule, interactions with the CPU for RISC-V are well specified, but how tooling works is more based on convention of tools for other architectures and what early RISC-V tools used.

I just tested and found that GNU AS also does not align .dword to double word boundaries. It also doesn't align smaller stores to their natural alignment though. So RARS is weird in that it does align the smaller directives.

This isn't a show stopper by any means and i can go with the current implementation. However, I would like some explanation to offer to my students who will come across this when working on assembly language projects.

I decided to implement .dword (and ld) to not need alignment simply because it was easier. I am open to changing it to, but I would be more in favor of matching AS by dropping natural alignment for other directives than adding alignment to .dword.

One other thing to note is that RARS currently traps on misaligned loads which is allowed by the specification, but only with an exception handler that makes the loads still work even if slower and non-atomically. Trapping on misaligned load should become an optional feature.

The best explanation for the behavior of GNU AS can see for students is that it is much harder to get around forced natural alignment than it is to manually align when you need to.

[ProfPierce]

Thank you for the clarification and explanation. I would say to leave things as they are for now, especially since the traps for non-aligned loads are working. This reinforces the concept of alignment restriction as discussed in the textbook and forces students to think about allocation of data in memory for best utilization and performance. Best wishes, Bill

…

________________________________ From: Benjamin Landers <[email protected]> Sent: Saturday, August 8, 2020 10:36 PM To: TheThirdOne/rars <[email protected]> Cc: Pierce, Bill <[email protected]>; Mention <[email protected]> Subject: Re: [TheThirdOne/rars] Floating-Point Rounding Modes (#73) [CAUTION - External Email] This email originated from outside of Hood College. DO NOT click on links or open attachments if you do not recognize the sender. I was trying to find this in the spec and cannot. All the references to the .dword directive indicate they should begin at memory addresses that are 8-byte boundaries. Maybe you can help me out to understand if this is indeed the way it is supposed to work and reference me to this in the spec. I don't recall anything about assembler directives being mentioned anywhere in the RISC-V specification. As a general rule, interactions with the CPU for RISC-V are well specified, but how tooling works is more based on convention of tools for other architectures and what early RISC-V tools used. I just tested and found that GNU AS also does not align .dword to double word boundaries. It also doesn't align smaller stores to their natural alignment though. So RARS is weird in that it does align the smaller directives. This isn't a show stopper by any means and i can go with the current implementation. However, I would like some explanation to offer to my students who will come across this when working on assembly language projects. I decided to implement .dword (and ld) to not need alignment simply because it was easier. I am open to changing it to, but I would be more in favor of matching AS by dropping natural alignment for other directives than adding alignment to .dword. One other thing to note is that RARS currently traps on misaligned loads which is allowed by the specification, but only with an exception handler that makes the loads still work even if slower and non-atomically. Trapping on misaligned load should become an optional feature. The best explanation for the behavior of GNU AS can see for students is that it is much harder to get around forced natural alignment than it is to manually align when you need to. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANFDM2PVVEYUVZ5JA6OXOILR7YDR7ANCNFSM4NEH2MTA>.