Improve memory read/write

[qwe661234]

After analyzing the data collected during the execution of the Dhrystone benchmark, we found that the primary performance bottleneck lies in memory read/write operations. To address this issue, we modified the implementation of memory read/write by eliminating unnecessary checks and replacing slow operations with more efficient ones. Additionally, we integrated a simple memory pool and resolved the issue of disabled unaligned memory access, the user can add argument --misalign to enable misaligned memory access.

After analyzing the performance results from running Dhrystone, we observed a significant improvement following our enhancements to the memory I/O.

Test	66200d0	improvement	Speedup
Dhrystone	815 DMIPS	1245 DMIPS	+52.7%

See: #122

[jserv]

Since the misaligned memory access is optional, we don't have to check it for the internals of emulator. Instead, we can register the callback functions while initializing the emulator.

See async.h and async.c for details.

/* API gateway */
struct __ASYNC_API__ Async = {
    .create = async_create,
    .signal = async_signal,
    .wait = async_wait,
    .finish = async_finish,
    .run = async_run,
};

Once you prepare the functions specialized for both misaligned memory and strictly-aligned memory access, the proper I/O implementations can be hooked up. Consequently, you don't have to check allow_ misalign all the time.

[jserv]

Test	66200d0	Proposed	Speedup
Dhrystone	815 DMIPS	1200 DMIPS	+47.2%

What else do you consider it would be beneficial to employ in place of Spike for faster interpreting?

[qwe661234]

Since the misaligned memory access is optional, we don't have to check it for the internals of emulator. Instead, we can register the callback functions while initializing the emulator.

See async.h and async.c for details.

/* API gateway */
struct __ASYNC_API__ Async = {
    .create = async_create,
    .signal = async_signal,
    .wait = async_wait,
    .finish = async_finish,
    .run = async_run,
};

Once you prepare the functions specialized for both misaligned memory and strictly-aligned memory access, the proper I/O implementations can be hooked up. Consequently, you don't have to check allow_ misalign all the time.

But the memory I/O implemention for for both misaligned memory and strictly-aligned memory access is the same, the only difference is that we need to handle exception if misaligned memory access is disabled.

[jserv]

the memory I/O implemention for for both misaligned memory and strictly-aligned memory access is the same, the only difference is that we need to handle exception if misaligned memory access is disabled.

Then, you can hook exception handlers which are aware of misaligned memory access by means of runtime dispatch.

[qwe661234]

the memory I/O implemention for for both misaligned memory and strictly-aligned memory access is the same, the only difference is that we need to handle exception if misaligned memory access is disabled.

Then, you can hook exception handlers which are aware of misaligned memory access by means of runtime dispatch.

Does this means send a callback function to memory read/ write? Because we don't need load/store handler if the memory misaligned access is enabled.

[jserv]

Then, you can hook exception handlers which are aware of misaligned memory access by means of runtime dispatch.
Does this means send a callback function to memory read/ write?

Sort of. In particular, we can shrink the code below:

/* SW: Store Word */
RVOP(sw, {
    const uint32_t addr = rv->X[ir->rs1] + ir->imm;
    if (!rv->is_misaliged_enabled && unlikely(addr & 3)) {
        rv->compressed = false;
        rv_except_store_misaligned(rv, addr);
        return false;
    ...

by replacing with something like the following:

/* SW: Store Word */
RVOP(sw, {
    const uint32_t addr = rv->X[ir->rs1] + ir->imm;
    RV_EXC_MISAGLIN_HANDLER(); /* some macro */

Meanwhile, we can hide the implementation details about allow_ misalign checks.

[jserv]

Integrate memory pool in conjunction of proposed memory operation changes.

[jserv]

Append Close #122 at the end of git commit messages.

[jserv]

Only <stddef.h> should be included here.

[qwe661234]

The gcc-12 compiler shows the warning when I only include <stddef.h>.

[jserv]

I don't think so.

gcc-12 -c mpool.h -Wall

It compiles without warnings. The actual header inclusion should appear in C source files.

[jserv]

Rephrase the git commit message as following:

After analyzing the data collected during the execution of the Dhrystone benchmark, it was discovered that the primary performance bottleneck lies in memory read/write operations. To address this issue, modifications were made to the implementation of memory read/write operations, eliminating unnecessary checks and replacing slow operations with more efficient ones. Additionally, a simple memory pool was integrated. It is now possible for the user to enable misaligned memory access by launching with option "--misalign".

The enhancements made to the memory I/O resulted in a significant improvement, as observed through performance results obtained by running Dhrystone.

[jserv]

Append a test item which triggers option --misalign in GitHub Actions. That is, we shall regularly validate the case when misaligned memory access is allowed for CI pipeline.