Are misaligned loads/stores supported?

[DL8]

According to RISC-V spec, the behavior in misaligned loads/stores (e.g. reading 4 bytes from address 0x1) depends on the implementation. How do we handle them?
Any behavior is acceptable, as long as it's well-defined and documented

[amichai-bd]

For simplification - in our LOTR project we want all memory access to be 4Byte aligned.

Meening - access to address 0x1 is illegal.

All Load/Store will be 0x0, 0x4, 0x8 etc..

[DL8]

From software perspective, the behavior you described is dangerous. If terminating the thread is too complicated for the PoC, it should be enough to document this behavior.

Regardless of what you'll do in the end, a CR indication is also a good addition. Can it include other useful information? For example, the value of PC and the address that caused the event. If the entire state of the thread can be dumped, that may also be useful (not critical if it overcomplicates).

[amichai-bd]

Due to us having the CRs that control the core & thread - having the thread "terminate" should not be too complicated.
so we can "freeze" the thread which misbehaved and add the indications to the CR.
I think we should add a new type of CR - we will call them SR (Status Registers) which will indicate the status of each core/thread.
It will remember error events, show if the thread is enabled or disabled, it can even show threads PC (program counter) or any other indication we would like.

I will start a new Discussion regarding this.

to conclude:

in case of a miss behaved thread that tries to access a "not 4 byte align" offset in memory, the access will not take place and the thread will be "frozen" + an error indication will be set in the SR (status register)

[DL8]

If it's not too complicated, I think it may be worth generalizing to all kinds of exceptions: when an error is detected, execution will freeze and corresponding SRs will be updated. The error indication in the SR will be an exception code defined in the architecture. Hopefully, it will enable easier implementation of exception handling when the time comes

[amichai-bd]

Yes - we will have many SRs. Each for different "exceptions".
Even more:
We can make the behavior of the design change according to a CR.
Example:
in case of a misaligned load/store, we can either freeze the thread or let it store/load continue ignoring the 2 LSB.
This will be according to how we set the CR register - it might be called "cr_freeze_when_error".
In any case - we definitely should have a list of "exceptions" that each may trigger and write to an SR (Status Register).
This will be good preparation for "implementation of exception handling" (when we do it in next projects)

Feels like we are attacking the LOTR design from many angles and I don't want to overwhelm our work.
This is a nice discussion - but for now, let's try to get our design up and running.

I feel like we did not get to talk about the RISCV toolchain. (compile+linker+assembler)
Let me know if you need any help to enable it - if you can make a 4 thread program + compiling it in the toolchain we can already start testing it. the CORE_4T design will be ready next week to run programs.
(I will enable the thread ID bit which is definitely needed - other CR/SR can wait)

[DL8]

I agree we shouldn't go into exception handling at this time, but from software perspective treating every exception as fatal is much better than letting the CPU run in an unpredictable state.

When an exception occurs and the CPU terminates, the following should be exposed via CR/SR (for each thread):

• Exception type - error code (e.g. misaligned access, undefined instruction. No need to implement everything now)
• CPU state - an SR for each register (including PC)