Sail support for rvv #149

b224hisl · 2022-02-06T13:37:00Z

We are from RIOS lab, being responsible for providing sail support for RVV(RISCV-VECTOR).
This version of Sail-RVV codes have passed our hand-written assembly tests for LMUL=1, XLEN=64, VLEN=128 and VSEW=32. We will keep maintain this project and while generating more tests with other configs

jrtc27 · 2022-02-06T13:56:20Z

Commented-out code, random debugging script, random unwanted changes to existing code and documentation, committed binaries and even git conflict markers. I'm not reviewing this properly until you've actually reviewed it yourself for that kind of thing, because you clearly haven't; the dSYM file at least should have stood out like a sore thumb just looking at the list of files changed.

martinberger · 2022-02-06T15:57:30Z

Sail-RVV codes have passed our hand-written assembly tests

Thanks @b224hisl

Floating point code is notoriously hard to test. Is there a place where the tests can be seen easily, and where it is explained why you have chosen those specific tests? That would make reviewing easier.

Is it hard to wrap those tests into an easily reproducible script for reviewing purposes (doesn't have to go into the repo)?

martinberger · 2022-02-06T16:08:18Z

@b224hisl Can I gently suggest to consider closing this PR, while RIOS lab apply final polish to the code?

allenjbaum · 2022-02-07T07:08:55Z

"Floating point code is notoriously hard to test. Is there a place where the tests can be seen easily, and why you have chosen those specific tests? That would make reviewing easier." We will eventually need to see a full test plan, not a few hand-written assembly tests. I don't think FP tests are the difficult part; the difficult part is all the load/store exception conditions, masking, etc. And, you'll likely have to repeat the exercise for every possible configuration (I think there are ~90 of them) All this means: you (or whoever is responsible for generating the tests) will need to provide - documentation on the coverpoints that your tests will check for, and - documentation that the tests actually generate those conditions when executed There is an existing IBM FP32 test suite with ~100,000 tests, for a scalar implementation (that is likely more design-verification oriented than compatibility oriented, so we may be able to have smaller tets) We have examples of the coverpoints for the D and F extensions - they are also quite extensive We have a coverage test generator (riscv-ctg) that takes a description of the conditions you are covering, and a coverpoint measurement tool (riscv-isac) for just that purpose. It is not a requirement to use those tools; you can use any tool you prefer, but - it must have the coverage rules documented in a human readable form, and - they must generate a report of which of the coverpoints defined by those rules have actually been observed by the tests. The results of the tests will be run on Sail, and on Spike and compared, using the riscof framework.

…

On Sun, Feb 6, 2022 at 8:08 AM Martin Berger ***@***.***> wrote: @b224hisl <https://github.com/b224hisl> Can I gently suggest that you close this PR, while you apply final polish to your code? — Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJUCO6LWYEGI5U6U3NTUZ2MIBANCNFSM5NVLASBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

martinberger · 2022-02-07T13:33:12Z

@b224hisl New changes are still failing our CI.

scottj97 · 2022-02-07T17:48:12Z

@b224hisl instead of repeatedly closing and reopening still-totally-broken Pull Requests, or quietly pushing still-totally-broken commits with cryptic messages like "delete sth", I suggest you (or someone else from your organization) discuss this here with the reviewers.

Otherwise, this is just spam.

abukharmeh · 2022-02-07T21:20:59Z

c_emulator/riscv_sim_RV32.dSYM/Contents/Info.plist

+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+	<dict>
+		<key>CFBundleDevelopmentRegion</key>
+		<string>English</string>
+		<key>CFBundleIdentifier</key>
+		<string>com.apple.xcode.dsym.riscv_sim_RV32</string>
+		<key>CFBundleInfoDictionaryVersion</key>
+		<string>6.0</string>
+		<key>CFBundlePackageType</key>
+		<string>dSYM</string>
+		<key>CFBundleSignature</key>
+		<string>????</string>
+		<key>CFBundleShortVersionString</key>
+		<string>1.0</string>
+		<key>CFBundleVersion</key>
+		<string>1</string>
+	</dict>


This content is not edited by me, it is generated automatically

You need to add *.plist to your. gitignore to ensure that these don't get into the repo

It might be a better idea to add it to $GIT_DIR/info/exclude instead (as that is specific to your workflow). gitignore is supposed to be common between all contributers, I am not sure how practical is it to add all various editors and IDEs to gitignore.

*.plist is a bad idea, those can be source files. You want *.dSYM as a whole. Which really belongs in your machine's global gitignore file.

abukharmeh · 2022-02-07T21:21:31Z

c_emulator/riscv_sim_RV64.dSYM/Contents/Info.plist

+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+	<dict>
+		<key>CFBundleDevelopmentRegion</key>
+		<string>English</string>
+		<key>CFBundleIdentifier</key>
+		<string>com.apple.xcode.dsym.riscv_sim_RV64</string>
+		<key>CFBundleInfoDictionaryVersion</key>
+		<string>6.0</string>
+		<key>CFBundlePackageType</key>
+		<string>dSYM</string>
+		<key>CFBundleSignature</key>
+		<string>????</string>
+		<key>CFBundleShortVersionString</key>
+		<string>1.0</string>
+		<key>CFBundleVersion</key>
+		<string>1</string>
+	</dict>
+</plist>


abukharmeh · 2022-02-07T21:22:29Z

debug_sail.sh

+
+function test_build () {
+    declare -i rc=0
+    eval $*
+    rc=$?
+    if [ $rc -ne 0 ]; then
+        echo "Failure to execute: $*"
+        exit $rc
+    fi
+}
+
+# test_build make ARCH=RV32 ocaml_emulator/riscv_ocaml_sim_RV32
+# test_build make ARCH=RV64 ocaml_emulator/riscv_ocaml_sim_RV64
+
+test_build make ARCH=RV32 c_emulator/riscv_sim_RV32 -j24
+test_build make ARCH=RV64 c_emulator/riscv_sim_RV64 -j24
+# test_build ./c_emulator/riscv_sim_RV64 ../riscv-tests-vector/isa/rv64uv-p-vsxseg >rv64uv-p-vsxseg.sail
+# test_build ./c_emulator/riscv_sim_RV64 ../riscv-tests-vector/isa/rv64uv-v-vsxseg >rv64uv-v-vsxseg.b


abukharmeh · 2022-02-07T21:22:41Z

doc/ExtendingGuide.md

@@ -1,6 +1,6 @@
 Extending the model
 ===================
-
+ZHUYIFEI


abukharmeh · 2022-02-07T21:28:25Z

Please note that I didnt finish looking at the files, I think you should, there is a lot of comments and files that need to be reverted before trying to review this. e.g binaries {riscv_sim_RV32, riscv_sim_RV64 and Z3 problems}, and IDE configurations (*plist). Sorry @jrtc27 for pointing out things you already mentioned, I just noticed that.

abukharmeh · 2022-02-07T21:29:30Z

build_simulators.sh

-test_build make ARCH=RV32 ocaml_emulator/riscv_ocaml_sim_RV32
-test_build make ARCH=RV64 ocaml_emulator/riscv_ocaml_sim_RV64
+#test_build make ARCH=RV32 ocaml_emulator/riscv_ocaml_sim_RV32
+#test_build make ARCH=RV64 ocaml_emulator/riscv_ocaml_sim_RV64

-test_build make ARCH=RV32 c_emulator/riscv_sim_RV32
-test_build make ARCH=RV64 c_emulator/riscv_sim_RV64
+test_build make ARCH=RV32 c_emulator/riscv_sim_RV32 -j24
+test_build make ARCH=RV64 c_emulator/riscv_sim_RV64 -j24


Revert, Also if you have had issues with OCAML simulator, please let us know in #138 comments

abukharmeh · 2022-02-07T21:40:02Z

ocaml_emulator/softfloat.ml

@@ -35,7 +35,11 @@ let f64_mul rm v1 v2 =
 let f64_div rm v1 v2 =
  ()

+<<<<<<< HEAD


Incomplete merge process !

Thanks！I will handle the conflicts I didn't find before carefully.

abukharmeh · 2022-02-07T23:29:38Z

model/riscv_insts_vext_total.sail

+/* ****************************************************************** */
+/* This file specifies the instructions in the vector set.      */
+
+
+/* ****************************************************************** */


Missing a suitable copyright header matching the rest of the repo as per #146

It seems that there is no package called headache in CentOS, Could you please give me some advice?

No need for headache, just copy the template from other files, and write a list of the contributors to each file added ??

b224hisl · 2022-02-10T04:01:58Z

Sorry for replying late and thanks for your guide. I can pass the ./build_simulator and successfully build the simulator on my local end, but when I push my code to the repo, it can't pass the CI. I'm trying to find what's wrong
Besides, I do not have much experience in pulling request. I hope you will give me more guidance, I will get it done as soon as possible, Thank you very much!

jrtc27 · 2022-02-10T04:04:50Z

That script does not build the RVFI-DII variants of the model, which are what are failing to build

martinberger · 2022-02-10T09:25:15Z

successfully build the simulator on my local end, but when I push my code to the repo,

@b224hisl I imagine that you work locally against an older copy of the code, but while you work locally, the code in this repo changes, which causes the failures when you push to this repo. So I recommend regularly to pull from here to your local repo and merge any changed that we get here back into your local repo. while you test locally. In particular, do this just before you submit code here.

In general, git is a powerful tool, and it takes a while to become familiar with even a fraction of the features. I spent two week (= 4 lectures) teaching git when I taught software engineering. In particular diffing, branching, merging and rebasing is important.

martinberger · 2022-02-10T11:11:09Z

@b224hisl Could it be that you are accidentally push to the official repo, when you want to push locally?

b224hisl · 2022-02-12T02:40:32Z

Hello, I have another question. I can make rvfi successfully on my local end, but it can't pass the CI, it will report bugs like this:

make: *** [generated_definitions/c/riscv_rvfi_model_RV32.c] Killed
make: *** Deleting file 'generated_definitions/c/riscv_rvfi_model_RV32.c'
make: *** Waiting for unfinished jobs....
Makefile:291: recipe for target 'generated_definitions/c/riscv_rvfi_model_RV32.c' failed

So it will automatically kill this building. I don't know whether the building time matters. Could anyone help me with that? Besides, I do have merged the lastest codes of the sail-riscv and handled all conflicts, which may not be the cause of the problem

abukharmeh · 2022-02-12T18:54:29Z

I just tried to compile it, and it does indeed compile fine, though memory usage of the SAIL compiler peak at more than 7 GB, while compiling the master branch takes a bit more than 1GB on my Debian machine.

I think the vector code is making the SAIL compiler use a lot of memory, and that results in GH killing the process around the 7GB mark matching public information I found about GH runners RAM capacity.

We need to find why the vector code makes the SAIL compiler use that much more memory!

abukharmeh · 2022-02-12T21:00:26Z

I think easiest way to debug this would be to split the vector instructions into multiple files and see if we can narrow it down to a given instruction or couple of instructions that are resulting in a significant increase in RAM usage.

Maybe that can be even automated with csplit and some bash script that monitor RAM usage across compilations
csplit riscv_insts_vext_total.sail '/mapping clause encdec.*/' {10} --prefix=riscv_inst_vext --suffix="%02d.sail"

I am not sure if it would be easy to pint point what is happening with the SAIL compiler with valgrind !

EDIT: I wonder if this is a systematic issue that need addressing at the compiler level, perhaps its worth trying to compile with P and V together and monitor RAM usage !

martinberger · 2022-02-12T21:53:23Z

monitor RAM usage !

@abukharmeh I doubt we are already running into Github Action resource limits, but if resources are an issue, we should try and get more. Compute is cheap.

abukharmeh · 2022-02-12T22:11:18Z

Thats also an option, according to this 7GB is the GitHub action RAM capacity for Linux machines, Apparently, GitHub can be connected to an external runner, maybe that's what we should do then! I cannot see anything in the log that indicates any error, Sail compiler is just getting killed, and on my local machine, it definitely took more than 7GB to compile the model with Vector extension!

abukharmeh · 2022-03-05T17:58:31Z

model/riscv_insts_vext_total.sail

+        //print_int("i=",i)
+      }
+    };
+    //print("end loop")


Debug comments perhaps should be removed before trying to merge with master ?

abukharmeh · 2022-03-05T17:58:50Z

model/riscv_insts_vext_total.sail

+          //result[i] = sail_sign_extend(0b1, vsew_bits)
+          result[i] = vd_val[i];
+          //print("agnositc")


Debug comments perhaps should be removed before trying to merge with master ?

abukharmeh · 2022-03-05T17:59:04Z

model/riscv_insts_vext_total.sail

+        else if tail_ag == AGNOSTIC then {
+          //result[i] = sail_sign_extend(0b1, vsew_bits)
+          result[i] = vd_val[i];
+          //print("agnostic0")


Debug comments perhaps should be removed before trying to merge with master ?

abukharmeh · 2022-03-05T18:00:56Z

c_emulator/riscv_sim.c

@@ -225,6 +226,7 @@ char *process_args(int argc, char **argv)
                    "N"
                    "I"
                    "F"
+		    "W"


Alignment !

abukharmeh · 2022-03-05T18:06:47Z

gen_vlen.py

+import sys
+import os
+import math
+
+vlen = int(sys.argv[1])
+elen = int(sys.argv[2])
+sail_path = 'model/riscv_vlen.sail'
+
+# Check value of VLEN
+if vlen < 128:
+    vlen = 128
+    print('WARN: VLEN less than 128; setting VLEN to 128\n')
+if vlen % 2 != 0:
+    vlen = vlen - (vlen % 2)
+    print('WARN: VLEN not a power of 2; setting VLEN to %d\n' % vlen)
+
+# Check value of ELEN
+if elen < 8:
+    elen = 8
+    print('WARN: ELEN less than 8; setting ELEN to 8\n')
+if elen % 2 != 0:
+    elen = elen - (elen % 2)
+    print('WARN: ELEN not a power of 2; setting ELEN to %d\n' % elen)
+
+if os.path.exists(sail_path):
+    os.remove(sail_path)
+
+lb = ['/* Define the VLEN value for the architecture */\n',
+      '\n',
+      'type vlen          : Int = %d\n' % vlen,
+      'type vlen_bytes    : Int = %d\n' % (vlen / 8),
+      'type vstart_int    : Int = %d\n' % math.log(vlen, 2),
+      'type vstartbits          = bits(vstart_int)\n',
+      '\n',
+      'type elen          : Int = %d\n' % elen,
+      '\n']
+
+
+fh_sail = open('model/riscv_vlen.sail', 'w')
+fh_sail.writelines(lb)
+fh_sail.close()
+
+exit()


This opens the same discussion about configurability and the idea of auto-generating SAIL code. While this script is trivial, and one can clearly reason its inputs and outputs, I wonder if it's better to have these as options to the simulators as cmd line args instead of generating them like this, Is there anything that prevents us from assigning these at runtime?

Personally, I think this is not needed, if we cannot set these at runtime for whatever reason, then people can just change them in that file, perhaps we should be checking that VLEN and ELEN actually make sense inside the model rather than here ?

I think we are going to prohibit any dynamic change of the Sail model. The Sail model is a constant, and the C-model it generates is a constant. Any behavioral change will be parameters that are passed to the Csim as commandline arguments (some of them rather complex, which is what we are trying to pin downs, e.g. lists of lists - but these are simple)

abukharmeh · 2022-03-05T18:16:21Z

model/riscv_insts_vext_total.sail

+    var real_num_elem : int = undefined;
+    if lmul >= 1.0 then {
+      real_num_elem = num_elem;
+      //print("init_masked_result: lmul >= 1.0")


Debug info like this need to be removed before merging ?

If there exist any debug information that we think would be very useful at a later stage, then we perhaps should have them guarded by a higher verbosity debug print?

I don't think the model has variable verbosity debug logging at the moment, but perhaps that's something someone could argue that is needed ? @billmcspadden-riscv

Yes, these kind of "debug droppings" should be removed or, if they are potentially useful, then a verbosity level should be added.

The SystemVerilog UVM package has a pattern we could follow. Is that something that people would respect and use?

scottj97 · 2022-03-07T18:44:09Z

gen_vlen.py

+# Check value of VLEN
+if vlen < 128:
+    vlen = 128
+    print('WARN: VLEN less than 128; setting VLEN to 128\n')
+if vlen % 2 != 0:
+    vlen = vlen - (vlen % 2)
+    print('WARN: VLEN not a power of 2; setting VLEN to %d\n' % vlen)
+
+# Check value of ELEN
+if elen < 8:
+    elen = 8
+    print('WARN: ELEN less than 8; setting ELEN to 8\n')
+if elen % 2 != 0:
+    elen = elen - (elen % 2)
+    print('WARN: ELEN not a power of 2; setting ELEN to %d\n' % elen)


The values of parameters from the caller should not be considered suggestions, which you can ignore if you don't like their values. They should be considered commands. If the code cannot obey those commands, it should fail immediately with a reasonable error message, instead of doing something other than what was commanded.

allenjbaum · 2022-03-07T20:47:39Z

Actually, this really should be caught in riscv-config. It is hasn't been, then it should be added there as a configuration constraint.

…

On Mon, Mar 7, 2022 at 10:44 AM Scott Johnson ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In gen_vlen.py <#149 (comment)>: > +# Check value of VLEN +if vlen < 128: + vlen = 128 + print('WARN: VLEN less than 128; setting VLEN to 128\n') +if vlen % 2 != 0: + vlen = vlen - (vlen % 2) + print('WARN: VLEN not a power of 2; setting VLEN to %d\n' % vlen) + +# Check value of ELEN +if elen < 8: + elen = 8 + print('WARN: ELEN less than 8; setting ELEN to 8\n') +if elen % 2 != 0: + elen = elen - (elen % 2) + print('WARN: ELEN not a power of 2; setting ELEN to %d\n' % elen) The values of parameters from the caller should not be considered suggestions, which you can ignore if you don't like their values. They should be considered commands. If the code cannot obey those commands, it should fail immediately with a reasonable error message, instead of doing something other than what was commanded. — Reply to this email directly, view it on GitHub <#149 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQCBVLDFDMXXYBHCQLU6ZFAZANCNFSM5NVLASBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

b224hisl · 2022-05-20T13:31:53Z

Hello, Thanks for your advice. And we are fixing the bugs of this sail-rvv project and deleting the unrelated information.
As memtioned above, there exists the problem of running out of the RAM so we can't pass the CI, though we can compile the csim and rvfi on the local end. Is there any feedback to this problem?
Besides, when buliding the osim, it will report "too many non-constant constructor“(#138 ). We have followed the guide in rems-project/sail#165, using another verison of sail. But it still can't be successfully compiled even without the V-extension

b224hisl · 2022-06-21T02:40:19Z

Could someone help me handle the questions I mentioned above?

martinberger · 2022-06-21T09:01:12Z

Could you give us some more information regarding what fails when you compile without the V extension? What are compiling in this case and what is the error message you are getting? What are you compiling when you run out of RAM using GitHub actions?

b224hisl · 2022-06-22T02:31:31Z

Could you give us some more information regarding what fails when you compile without the V extension? What are compiling in this case and what is the error message you are getting? What are you compiling when you run out of RAM using GitHub actions?

when I try to bulid the osim, it will report "too many non-constant constructor", I have upload my error log in #138 (comment).

And running out of the github RAM is another thing. When I try to bulid the other two simulators, I can successfully bulid them on my local end, but it can not pass the CI here.

I just tried to compile it, and it does indeed compile fine, though memory usage of the SAIL compiler peak at more than 7 GB, while compiling the master branch takes a bit more than 1GB on my Debian machine.

I think the vector code is making the SAIL compiler use a lot of memory, and that results in GH killing the process around the 7GB mark matching public information I found about GH runners RAM capacity.

We need to find why the vector code makes the SAIL compiler use that much more memory!

bacam · 2022-06-27T21:59:21Z

I looked into this today. In the runner currently used in this pull request it runs two copies of sail in parallel, so the increase in memory usage is doubled. The master branch now has a different runner that appears to only build one at a time, so it will probably fit in memory. You should be able to use it by rebasing the branch.

The osim issue should be fixed shortly when Alasdair releases a new Sail version, but that will require a few small changes, all of the same form. I'll add an example.

bacam · 2022-06-27T22:09:31Z

model/riscv_insts_vext_total.sail

+union clause ast = NITYPE : (nifunct6, bits(1), regidx, regidx, regidx)
+
+mapp


This mixed assignment / definition using a tuple won't be supported by the next Sail version. The result_real line isn't necessary anyway and can be removed. Instead put a let in front of the tuple to make it a definition rather than an assignment.

That's strange, github has changed the line range to a different piece of code entirely. Here's an example patch instead:

--- a/model/riscv_insts_vext_total.sail +++ b/model/riscv_insts_vext_total.sail @@ -8285,9 +8285,8 @@ function process_rfvv_widen(funct6, vm, vs2, vs1, vd, num_elem, vsew_bits, lmul) vs1_0 : bits('double_vsew) = read_single_element(double_vsew, 0, double_lmul, vs1); foreach (i from 0 to (num_elem - 1)) { if mask_helper[i] == true then { - result_real : real = undefined; /* Currently Ordered/Unordered sum do the same operations */ - (fptype, sign, result_real) = fpreal_add(fp_to_real(vs2_val[i]), fp_to_real(vs1_0)); + let (fptype, sign, result_real) = fpreal_add(fp_to_real(vs2_val[i]), fp_to_real(vs1_0)); vs1_0 = real_to_fp(result_real) } };

xiak95 · 2022-12-28T13:26:46Z

This is currently being superseded with #191 #198 etc, so can be closed ?

billmcspadden-riscv · 2023-01-02T16:45:24Z

Yes. Bill Mc.

…

On Wed, Dec 28, 2022 at 7:26 AM xiak95 ***@***.***> wrote: This is currently being superseded with #191 <#191> #198 <#198> etc, so can be closed ? — Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXROLOCHYA6PQGPPY4OBYO3WPQ52DANCNFSM5NVLASBA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Bill McSpadden Formal Verification Engineer RISC-V International mobile: 503-807-9309

github-actions · 2023-01-24T13:27:44Z

Unit Test Results

712 tests ±0 712 ✔️ ±0 0s ⏱️ ±0s
    6 suites ±0     0 💤 ±0
    1 files ±0     0 ❌ ±0

Results for commit b69d069. ± Comparison against base commit 5cc5a93.

ptomsich · 2023-05-25T20:57:00Z

Looking at the history, we apparently had an agreement that this PR can be closed, as it is superseded by #191, #198, and others.

Sail support for rvv

a0eddc6

delete sth

19f6c73

abukharmeh reviewed Feb 7, 2022

View reviewed changes

doc/ExtendingGuide.md Outdated

@@ -1,6 +1,6 @@

Extending the model

===================

ZHUYIFEI

Copy link

Contributor

abukharmeh Feb 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revert ?

abukharmeh reviewed Feb 7, 2022

View reviewed changes

main.yml

76be2df

b224hisl and others added 4 commits February 11, 2022 10:59

handle the conflicts, and delete unrelated file

917fa43

successfully compile csim rvfi but osim still exist some problems

4ee2fad

successfully compile csim rvfi but osim still exist some problems

51b9064

add new CI witout building osim

604b1c9

abukharmeh reviewed Mar 5, 2022

View reviewed changes

c_emulator/riscv_sim.c

@@ -225,6 +226,7 @@ char *process_args(int argc, char **argv)

"N"

"I"

"F"

"W"

Copy link

Contributor

abukharmeh Mar 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alignment !

abukharmeh reviewed Mar 5, 2022

View reviewed changes

scottj97 reviewed Mar 7, 2022

View reviewed changes

bacam reviewed Jun 27, 2022

View reviewed changes

Rubiczhang and others added 8 commits September 6, 2022 17:23

slice vext_total

976a6ca

silce vext_total.sail

37a8939

Merge branch 'master' of https://github.com/riscv/sail-riscv

a8af0b4

fixed bugs about floating point

d1ff157

Fix some bugs in vfw instructions

d92272e

Delete some unused code

271464d

Fix bugs in vfmax and vfmin

2d78b7a

Delete some unnecessary code

258edff

scottj97 mentioned this pull request Nov 9, 2022

V extension general framework and configuration setting instructions #191

Merged

Update README.md

b69d069

jjscheel mentioned this pull request Mar 17, 2023

Vector SAIL riscv-admin/dev-partners#24

Closed

13 tasks

ptomsich closed this May 25, 2023

@@ @@ -225,6 +226,7 @@ char *process_args(int argc, char **argv) @@
                                   "N"
                                   "I"
                                   "F"
+              		    "W"

		union clause ast = NITYPE : (nifunct6, bits(1), regidx, regidx, regidx)

		mapp

Sail support for rvv #149

Sail support for rvv #149

Conversation

b224hisl commented Feb 6, 2022

jrtc27 commented Feb 6, 2022

martinberger commented Feb 6, 2022 • edited Loading

martinberger commented Feb 6, 2022 • edited Loading

allenjbaum commented Feb 7, 2022 via email

martinberger commented Feb 7, 2022

scottj97 commented Feb 7, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abukharmeh Mar 13, 2022 • edited Loading

Choose a reason for hiding this comment

jrtc27 Mar 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abukharmeh commented Feb 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abukharmeh Feb 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

b224hisl commented Feb 10, 2022

jrtc27 commented Feb 10, 2022 • edited Loading

martinberger commented Feb 10, 2022 • edited Loading

martinberger commented Feb 10, 2022

b224hisl commented Feb 12, 2022 • edited Loading

abukharmeh commented Feb 12, 2022 • edited Loading

abukharmeh commented Feb 12, 2022 • edited Loading

martinberger commented Feb 12, 2022 • edited Loading

abukharmeh commented Feb 12, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abukharmeh Mar 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abukharmeh Mar 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

allenjbaum commented Mar 7, 2022 via email

b224hisl commented May 20, 2022 • edited Loading

b224hisl commented Jun 21, 2022

martinberger commented Jun 21, 2022

b224hisl commented Jun 22, 2022

bacam commented Jun 27, 2022

Choose a reason for hiding this comment

bacam Jun 27, 2022 • edited Loading

Choose a reason for hiding this comment

xiak95 commented Dec 28, 2022

billmcspadden-riscv commented Jan 2, 2023 via email

github-actions bot commented Jan 24, 2023

Unit Test Results

ptomsich commented May 25, 2023

martinberger commented Feb 6, 2022 •

edited

Loading

martinberger commented Feb 6, 2022 •

edited

Loading

abukharmeh Mar 13, 2022 •

edited

Loading

jrtc27 Mar 14, 2022 •

edited

Loading

abukharmeh commented Feb 7, 2022 •

edited

Loading

abukharmeh Feb 7, 2022 •

edited

Loading

jrtc27 commented Feb 10, 2022 •

edited

Loading

martinberger commented Feb 10, 2022 •

edited

Loading

b224hisl commented Feb 12, 2022 •

edited

Loading

abukharmeh commented Feb 12, 2022 •

edited

Loading

abukharmeh commented Feb 12, 2022 •

edited

Loading

martinberger commented Feb 12, 2022 •

edited

Loading

abukharmeh Mar 5, 2022 •

edited

Loading

abukharmeh Mar 5, 2022 •

edited

Loading

b224hisl commented May 20, 2022 •

edited

Loading

bacam Jun 27, 2022 •

edited

Loading