-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring RISC-V emulation APIs for easier adoption and porting #310
Comments
I would like to invite @RinHizakura, @qwe661234, and @visitorckw to join the discussion and contribute to the refinement of the API. |
In the initial stages of developing this emulator, I redirected I/O operations to files for comparison purposes. However, I now recognize that this approach to the function interface was not as flexible as I had initially thought. |
So, it could be useful to provide an abstract way for defining the desired |
I think the distinction between modules is a little bit unclear in the current design of
So, if it doesn't matter to provide user-specific operations on memory, providing them on the build time for the library will also be a great solution. |
Not quite sure about whether changing the memory size directly is safe. As I remember, some implementations of rv32emu intensionally rely on the fact that the memory size is 2^32 - 1 to have some trick. Or maybe I mix up with some project else. Looking for others to answer the question. |
The built-in ELF programs do not seem to need a lot of memory so I think 2GB - 4GB is a safe region. Dynamically changing the memory size in different runtime might be needed. For example, 64KiB multiples should be used in WebAssembly. The |
I would like to introduce Then, |
For example:
|
I agree. By the way, |
The repository mnurzia/rv serves as an additional reference for API refinement. It features three main APIs:
These APIs collectively provide a structure for memory access, CPU initialization, and step-wise execution in the CPU simulation. |
As previously suggested, the maximum memory ( Makefile:
Thus, adjusting stack size should be a part in public API. |
I think Currently,
I would like to introduce the sixth attribute of Prefix of all vm-related functions should be consistent ( more discussion ). |
It sounds promising. Please send pull request(s) to refine APIs.
How about
|
Since the envp is not accessible for now, place a TODO in
It is related to |
After streamlining the API, we can control the exit code by storing it in a specific structure, instead of displaying it directly in the console. |
For abstracting file or file descriptor, we could have an attribute called |
Since we should also have to maintain the file descriptor if struct {
...
int stdin;
int stdout;
int stderr;
} vm_attr_t; Note: The variable's name should be refined. I just can't come up with a suitable and concise name now These file descriptors are assigned to 0, 1, and 2 by default, and modified if |
Thanks for tips! I think the boolean really redundant since |
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user; as a result, setting a configuration value (vm_attr_t) is sufficient. The user should concern about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. The vm_attr_t has multiple fields and they are commented clearly in the code. Note that logging feature and system emulator integration are not implemented yet. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user; as a result, setting a configuration value (vm_attr_t) is sufficient. For stdio redirection, rv_register_stdio function is introduced. The user should concern about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. The vm_attr_t has multiple fields and they are commented clearly in the code. Note that logging feature and system emulator integration are not implemented yet. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. For stdio remapping, rv_remap_stdstream function is introduced. The vm_attr_t has multiple fields and they are commented clearly in the code. elf_t is reopened in run_and_trace and dump_test_signature because elf_t is allocated inside rv_create and they cannot access them. It is acceptable to reopen elf_t since they are only for testing and debugging. PRINT_EXIT_CODE build macro is introduced to enable syscall_exit to print exit code to console only during testing since the actual usage of exit code is really depending on applications. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. For stdio remapping, rv_remap_stdstream function is introduced. The vm_attr_t has multiple fields and they are commented clearly in the code. elf is reopened in run_and_trace and dump_test_signature because elf is allocated inside rv_create and they cannot access them. It is acceptable to reopen elf since they are only for testing and debugging. Print inferior exit code to console inside main instead of syscall_exit because the actual usage of exit code depends on applications of using riscv public API. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. For stdio remapping, rv_remap_stdstream function is introduced. The vm_attr_t has multiple fields and they are commented clearly in the code. elf is reopened in dump_test_signature because elf is allocated during rv_create. It is acceptable to reopen elf since it is only for testing. Print inferior exit code to console inside main instead of syscall_exit because the actual usage of exit code depends on applications of using riscv public API. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. The vm_attr_t has multiple fields and they are commented clearly in the code. As you can see in "main", there are various mode to run the emulator such as "run_and_trace", "gdbstub", and "profiling". Thus, a field call "run_flag" is introduced in vm_attr_t. For standard stream remapping, rv_remap_stdstream function is introduced. The emulator can remap default standard stream to required streams after creating the emulator by calling the rv_remap_stdstream function. elf is reopened in dump_test_signature because elf is allocated during rv_create. It is acceptable to reopen elf since it is only for testing. Print inferior exit code to console inside main instead of syscall_exit because the actual usage of exit code depends on applications of using riscv public API. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. A validator for validating the user-defined vm_attr_t might need to be introduced. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. The vm_attr_t has multiple fields and they are commented clearly in the code. As you can see in "main", there are various mode to run the emulator such as "run_and_trace", "gdbstub", and "profiling". Thus, a field call "run_flag" is introduced in vm_attr_t. For standard stream remapping, rv_remap_stdstream function is introduced. The emulator can remap default standard stream to required streams after creating the emulator by calling the rv_remap_stdstream function. rv_userdata has been dropped since PRIV macro is sufficient for internal implemntation. Also, application will not need to direct access it. elf is reopened in dump_test_signature because elf is allocated during rv_create. It is acceptable to reopen elf since it is only for testing. Print inferior exit code to console inside main instead of syscall_exit because the actual usage of exit code depends on applications of using riscv public API. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. A validator for validating the user-defined vm_attr_t might need to be introduced. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. The vm_attr_t has multiple fields and they are commented clearly in the code. As you can see in "main", there are various mode to run the emulator such as "run_and_trace", "gdbstub", and "profiling". Thus, a field call "run_flag" is introduced in vm_attr_t. For standard stream remapping, rv_remap_stdstream function is introduced. The emulator can remap default standard stream to required streams after creating the emulator by calling the rv_remap_stdstream function. rv_userdata has been dropped since PRIV macro is sufficient for internal implemntation. Also, application will not need to direct access it. elf is reopened in dump_test_signature because elf is allocated during rv_create. It is acceptable to reopen elf since it is only for testing. Print inferior exit code to console inside main instead of syscall_exit because the actual usage of exit code depends on applications of using riscv public API. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. A validator for validating the user-defined vm_attr_t might need to be introduced. related: sysprog21#310
The following should be included in an emulator's simple and clear public API: 1. create/init core 2. run emulation 3. delete/destroy core Other components, including as memory, file systems, program data, etc., should be abstracted from the user, as a result, setting a configuration value (vm_attr_t) is sufficient. The user should manage about memory (state_t) and elf stuff before this PR. The user may just construct a core, run it, and shut it down after this PR, so they won't need to worry about them anymore. The vm_attr_t has multiple fields and they are commented clearly in the code. As you can see in "main", there are various mode to run the emulator such as "run_and_trace", "gdbstub", and "profiling". Thus, a field call "run_flag" is introduced in vm_attr_t. For standard stream remapping, rv_remap_stdstream function is introduced. The emulator can remap default standard stream to required streams after creating the emulator by calling the rv_remap_stdstream function. rv_userdata has been dropped since PRIV macro is sufficient for internal implemntation. Also, application will not need to direct access it. elf is reopened in dump_test_signature because elf is allocated during rv_create. It is acceptable to reopen elf since it is only for testing. Print inferior exit code to console inside main instead of syscall_exit because the actual usage of exit code depends on applications of using riscv public API. The io interface is not changed in this PR because it could maybe reused with semu in some way, still need to be investigated. Also, Logging feature and system emulator integration are not implemented yet. A validator for validating the user-defined vm_attr_t might need to be introduced. related: sysprog21#310
It is not required to give an application the opportunity to bind IO handlers because IO handlers are rarely altered during the creation of a emulator. With this commit, the application can now build a emulator much more easier by only taking the emulator's attribute (vm_attr_t) into consideration. In order to facilitate further integration with the RISC-V system emulator (semu), I have included a TODO inside the IO interface. Related: sysprog21#310
It is not required to give an application the opportunity to bind I/O handlers because I/O handlers are rarely altered during the creation of a emulator. With this commit, the application can now build a emulator much more easier by only taking the emulator's attribute (vm_attr_t) into consideration. In order to facilitate further integration with the RISC-V system emulator (semu), I have included a TODO inside the I/O interface. Related: sysprog21#310
It is not required to give an application the opportunity to bind I/O handlers because I/O handlers are rarely altered during the creation of an emulator. With this commit, the application can now build a emulator much more easier by only taking the emulator's attribute (vm_attr_t) into consideration. In order to facilitate further integration with the RISC-V system emulator (semu), I have included a TODO inside the I/O interface. Related: sysprog21#310
The proposal sounds great. I wonder how mmu_{fetch,load,store} can be interoperated with existing structure. Can you show more about function prototypes? |
Sure. We have to emulate the peripherals, like MMU, UART and PLIC for minimum requirements to boot Linux. First of all, we shall support MMU for more resource-management technique in kernel, for example memory sharing or copy-on-write(COW) such that user space programs can call fork system call. In order to support MMU, we can reuse the typedef struct {
/* memory read interface */
riscv_mem_ifetch mem_ifetch;
riscv_mem_read_w mem_read_w;
riscv_mem_read_s mem_read_s;
riscv_mem_read_b mem_read_b;
/* memory write interface */
riscv_mem_write_w mem_write_w;
riscv_mem_write_s mem_write_s;
riscv_mem_write_b mem_write_b;
/* TODO: add peripheral I/O interfaces */
+ /* MMU memory helper interface */
+ riscv_mmu_mem_walk mmu_mem_walk;
+ /* MMU memory read interface */
+ riscv_mem_ifetch mmu_mem_ifetch;
+ riscv_mem_read_w mmu_mem_read_w;
+ riscv_mem_read_s mmu_mem_read_s;
+ riscv_mem_read_b mmu_mem_read_b;
+ /* MMU memory write interface */
+ riscv_mem_write_w mmu_mem_write_w;
+ riscv_mem_write_s mmu_mem_write_s;
+ riscv_mem_write_b mmu_mem_write_b;
/* system */
riscv_on_ecall on_ecall;
riscv_on_ebreak on_ebreak;
riscv_on_memset on_memset;
riscv_on_memcpy on_memcpy;
} riscv_io_t; We can decide which function pointer to call during instruction decoding stage since we will know the data width at that time.
You might notice that non-mmu {fetch, read, write} and mmu {fetch, read, write} are duplicated after this changes. To preserve the mnemonic of the function pointers, we might want to separate them although we could use union to wrap them up to save memory. But, for simplicity, I would like not to use union first. |
The proposed mmu_mem_{read,write}_[wsb] are confusing since we already have the ones prefixing with |
What about remove typedef struct {
...
/* TODO: add peripheral I/O interfaces */
+ /* MMU memory helper interface */
+ riscv_mmu_mem_walk mmu_walk;
+ /* MMU memory read interface */
+ riscv_mem_ifetch mmu_ifetch;
+ riscv_mem_read_w mmu_read_w;
+ riscv_mem_read_s mmu_read_s;
+ riscv_mem_read_b mmu_read_b;
+ /* MMU memory write interface */
+ riscv_mem_write_w mmu_write_w;
+ riscv_mem_write_s mmu_write_s;
+ riscv_mem_write_b mmu_write_b;
...
} riscv_io_t;
|
Yes, I anticipate removing the legacy memory callback functions prefixed with |
Originally, I am not intend to make mmu_{load,store} registratable, but to reduce the number of parameters that passed to a mmu_{load,store} function. However, if we want to eliminate registration for mmu_{load,store} from
Obviously, we can pass a variable to indicate the width of the data and reduce the number of MMU related functions but I believe one function does one thing well might be a better adoption. Also, they might show more consistency upon the existing |
One thing to notice is that: after the commit 8355777, the I/O interface are binding during initialization, thus no opportunity is given for user registration. Similar situation for mmu_{load, store} callback functions. |
Agree. Prior to the refinement of memory operations, I was thinking of Duff's device to unify these functions with various widths. However, we can benefit from compiler optimizations by using specialized functions which are not exposed and would be only hooks during initialization. |
Yes, declare MMU related functions using |
Not necessary. Let's proceed. |
Since we have ISA and system emulator, it should provide a way to turn on or off the MMU support. There are two ways to do this:
Obviously, option 2 has lower overhead than option 1. If option 2 is used, the existing |
I prefer option 2. When the MMU is not set by Linux during early boot, which set of memory handlers would be used? |
According to the Sv32 description in RISC-V privileged 20211203 section 4.3, the In summary, rv32emu can check if |
The purpose of this commit is to boot 32-bit RISC-V Linux in the future. The virtual memory scheme to support is Sv32. There are one change to original code base to adapt the MMU: The prototype of riscv_io_t interface needs to be changed. Particularly, add a RISC-V instance(riscv_t) as the first parameter. MMU related callbacks require to access the satp CSR to perform a page table walk during virtual memory translation but satp CSR is stored in RISC-V instance(riscv_t), thus it should have a way to access the satp CSR. The trivial solution is adding RISC-V instance(riscv_t) to the prototype of riscv_io_t interface. After this change, we can reuse riscv_io_t for system emulation afterward. The rest of changes are implementing the Sv32 virtual memory scheme. For every memory access, it has to walk through the page table to get the corresponding PTE. Depends on the retrieval of PTE, there are several page faults to be handled if necessary, so there are three exceptions handlers have been introduced which are insn_pgfault, load_pgfault, and store_pgfault and they are used in MMU_CHECK_FAULT. In this commit, the access fault are not handled well since they are related to PMA and PMP and they might not the must to boot 32-bit RISC-V Linux (tested on semu). Related: sysprog21#310
The purpose of this commit is to boot 32-bit RISC-V Linux in the future. The virtual memory scheme to support is Sv32. There are one change to original code base to adapt the MMU: The prototype of riscv_io_t interface needs to be changed. Particularly, add a RISC-V instance(riscv_t) as the first parameter. MMU related callbacks require to access the satp CSR to perform a page table walk during virtual memory translation but satp CSR is stored in RISC-V instance(riscv_t), thus it should have a way to access the satp CSR. The trivial solution is adding RISC-V instance(riscv_t) to the prototype of riscv_io_t interface. After this change, we can reuse riscv_io_t for system emulation afterward. The rest of changes are implementing the Sv32 virtual memory scheme. For every memory access, it has to walk through the page table to get the corresponding PTE. Depends on the retrieval of PTE, there are several page faults to be handled if necessary, so there are three exceptions handlers have been introduced which are insn_pgfault, load_pgfault, and store_pgfault and they are used in MMU_CHECK_FAULT. In this commit, the access fault are not handled well since they are related to PMA and PMP and they might not the must to boot 32-bit RISC-V Linux (tested on semu). More S-mode and M-mode CSR helper macro are introduced as well for future needs. Related: sysprog21#310
The purpose of this commit is to boot 32-bit RISC-V Linux in the future. The virtual memory scheme to support is Sv32. There are one change to original code base to adapt the MMU: The prototype of riscv_io_t interface needs to be changed. Particularly, add a RISC-V instance(riscv_t) as the first parameter. MMU related callbacks require to access the satp CSR to perform a page table walk during virtual memory translation but satp CSR is stored in RISC-V instance(riscv_t), thus it should have a way to access the satp CSR. The trivial solution is adding RISC-V instance(riscv_t) to the prototype of riscv_io_t interface. After this change, we can reuse riscv_io_t for system emulation afterward. The rest of changes are implementing the Sv32 virtual memory scheme. For every memory access, it has to walk through the page table to get the corresponding PTE. Depends on the retrieval of PTE, there are several page faults to be handled if necessary, so there are three exceptions handlers have been introduced which are insn_pgfault, load_pgfault, and store_pgfault and they are used in MMU_CHECK_FAULT. In this commit, the access fault are not handled well since they are related to PMA and PMP and they might not the must to boot 32-bit RISC-V Linux (tested on semu). More PTE, S-mode, M-mode CSR helper macro are introduced as well. Related: sysprog21#310
The purpose of this commit is to boot 32-bit RISC-V Linux in the future. The virtual memory scheme to support is Sv32. There are one change to original code base to adapt the MMU: The prototype of riscv_io_t interface needs to be changed. Particularly, add a RISC-V instance(riscv_t) as the first parameter. MMU related callbacks require to access the satp CSR to perform a page table walk during virtual memory translation but satp CSR is stored in RISC-V instance(riscv_t), thus it should have a way to access the satp CSR. The trivial solution is adding RISC-V instance(riscv_t) to the prototype of riscv_io_t interface. After this change, we can reuse riscv_io_t for system emulation afterward. The rest of changes are implementing the Sv32 virtual memory scheme. For every memory access, it has to walk through the page table to get the corresponding PTE. Depends on the retrieval of PTE, there are several page faults to be handled if necessary, so there are three exceptions handlers have been introduced which are insn_pgfault, load_pgfault, and store_pgfault and they are used in MMU_CHECK_FAULT. In this commit, the access fault are not handled well since they are related to PMA and PMP and they might not the must to boot 32-bit RISC-V Linux (tested on semu). Some S-mode CSRs are added to riscv_internal to support S-mode. PTE, S-mode and M-mode CSR helper macro are introduced as well. Related: sysprog21#310
The purpose of this commit is to boot 32-bit RISC-V Linux in the future. The virtual memory scheme to support is Sv32. There are one change to original code base to adapt the MMU: The prototype of riscv_io_t interface needs to be changed. Particularly, add a RISC-V instance(riscv_t) as the first parameter. MMU related callbacks require to access the satp CSR to perform a page table walk during virtual memory translation but satp CSR is stored in RISC-V instance(riscv_t), thus it should have a way to access the satp CSR. The trivial solution is adding RISC-V instance(riscv_t) to the prototype of riscv_io_t interface. After this change, we can reuse riscv_io_t for system emulation afterward. The rest of changes are implementing the Sv32 virtual memory scheme. For every memory access, it has to walk through the page table to get the corresponding PTE. Depends on the retrieval of PTE, there are several page faults to be handled if necessary, so there are three exceptions handlers have been introduced which are insn_pgfault, load_pgfault, and store_pgfault and they are used in MMU_CHECK_FAULT. In this commit, the access fault are not handled well since they are related to PMA and PMP and they might not the must to boot 32-bit RISC-V Linux (tested on semu). Some S-mode CSRs are added to riscv_internal to support S-mode. PTE, S-mode and M-mode CSR helper macro are introduced as well. Related: sysprog21#310
SBI acts as a communication layer between S-mode software and M-mode hardware. To boot Linux kernel, there are some minimal SBI extensions have to be implemented and they are: 1. Base extension(EID=0x10) 2. Timer extension(EID=0x54494D45) SRST extension(EID=0x53525354) is optional so just implemented shutdown reason. Related: sysprog21#310
SBI acts as a communication layer between S-mode software and M-mode hardware. To boot Linux kernel, there are some minimal SBI extensions have to be implemented and they are: 1. Base extension(EID=0x10) 2. Timer extension(EID=0x54494D45) SRST extension(EID=0x53525354) is optional so just implemented shutdown reason. Related: sysprog21#310
SBI acts as a communication layer between S-mode software and M-mode hardware. To boot Linux kernel, there are some minimal SBI extensions have to be implemented and they are: 1. Base extension(EID=0x10) 2. Timer extension(EID=0x54494D45) SRST extension(EID=0x53525354) is optional so just implemented shutdown reason. Related: sysprog21#310
SBI acts as a communication layer between S-mode software and M-mode hardware. To boot Linux kernel, there are some minimal SBI extensions have to be implemented and they are: 1. Base extension(EID=0x10) 2. Timer extension(EID=0x54494D45) SRST extension(EID=0x53525354) is optional so just implemented shutdown reason. Related: sysprog21#310
SBI acts as a communication layer between S-mode software and M-mode hardware. To boot Linux kernel, there are some minimal SBI extensions have to be implemented and they are: 1. Base extension(EID=0x10) 2. Timer extension(EID=0x54494D45) SRST extension(EID=0x53525354) is optional so just implemented shutdown reason. Related: sysprog21#310
First trial of refactoring, the wasm branch's latest commit is the result.
Since
state_t
is a user-provided data, so all runtime defined value(often change) shall be stored there. For instance, the emulated target program's argc and argv, and the emulator's parameter. The following have been adjusted to reflect the changes:state_t *state_new(void)
----->state_t *state_new(uint32_t mem_size, int argc, char **argv, bool allow_misalign, bool quiet_output)
mem_size
is used formemory_new
because different runtimes may have memory requirements (for example, the page size in WebAssembly is 64KiB), the defaultMEM_SIZE
(2^32 - 1) is not appropriate for that. The rest of parameters are runtime defined value.riscv_t *rv_create(const riscv_io_t *io, riscv_user_t userdata, int argc, char **args, bool output_exit_code)
----->riscv_t *rv_create(riscv_user_t userdata)
Much cleaner function signature.
void rv_reset(riscv_t *rv, riscv_word_t pc, int argc, char **args)
----->void rv_reset(riscv_t *rv, riscv_word_t pc)
We can use
rv->userdata
to get the requiredargc
andargv
.Since memory I/O handlers are rarely changed, it makes less sense to define them during runtime (makes porting difficult). Instead, I believe it is preferable to link them during build time. If really want to change the implementations, make a new C file and link it during build time might be a better choice.
To do this, some changes are made:
rv_create
and link during build timeMEM_WRITE_IMPL
macro has to be changed:src/io.c
memory_write_w
in "src/syscall.c" shall be changed accordingly:src/syscall.c
For notably change, the "pre.js" of the wasm branch do not define IO on its own anymore compare to first attempt.(more abstraction)
Change all
uint32_t
anduint16_t
anduint8_t
in riscv.[ch] toriscv_word_t
andriscv_half_t
andriscv_byte_t
in function signature respectively for consistency.bool elf_load(elf_t *e, riscv_t *rv, memory_t *mem);
----->bool elf_load(elf_t *e, riscv_t *rv);
The memory instance required by
elf_load
can be accessed viarv
's userdata.I am wondering shall we abstract the
FILE
defined instate_new
as a parameter ofstate_new
. Without abstraction, the emulator always depends on standard io(e.g.,stdin
,stdout
,stderr
). What if the user want to use a file instead ofstdout
?Related to: #75
The text was updated successfully, but these errors were encountered: