Misaligned accesses (need clarfication)

[Nhon Quach]

Hi,

Can anyone tell me what constitute an misaligned access in RISCV?  It was not clear to me from reading the spec.

Specifically,

1. For 32b accesses, for a single byte access, can the byte be located in any of the in four bytes in the data (or register)? If so, which RISCV instruction will generate such a load/store?

2. Same question for 2B accesses. Can the 2B be located anywhere in the 4B data (or register)?

3. For implementations with caches, for misaligned accesses access across cacheline boundary (let's ignore the case of crossing TLB boundary for now), the HW needs to split the transaction into two, correct? This should go without saying, but I like to understand the intent of the architecture.

Thanks,

Nhon

 

================================================================
This electronic message transmission contains information from Abee Semi, Inc. which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by telephone (408.888.7248) or by electronic mail (nhon....@abeesemi.net) immediately.
================================================================

[Stefan O'Rear]

On Sat, Jan 7, 2017 at 10:00 PM, Nhon Quach <nhon....@abeesemi.net> wrote:
> Hi,
>
> Can anyone tell me what constitute an misaligned access in RISCV? It was
> not clear to me from reading the spec.

A misaligned access is one where the address is not divisible by the
size. LW at address 11 is misaligned, at address 12 is correctly
aligned; but LD at 12 would still be misaligned because 12 is not
divisible by 8.

An access of a single byte is never misaligned because all addresses
are divisible by 1.

-s

[Samuel Falvo II]

On Sat, Jan 7, 2017 at 10:00 PM, Nhon Quach <nhon....@abeesemi.net> wrote:

> Hi,
>
> Can anyone tell me what constitute an misaligned access in RISCV? It was

A misaligned access is any access (load or store) to an address that
meets the following criteria:

- for a 16-bit half-word, address bit 0 is set.
- for a 32-bit word, any of address bit 0 or address bit 1 is set.
- for a 64-bit double-word, any of address bits 0, 1, or 2 are set.
- for a 128-bit quad-word, any of address bits 0, 1, 2, or 3 are set.

> 1. For 32b accesses, for a single byte access, can the byte be located in
> any of the in four bytes in the data (or register)? If so, which RISCV
> instruction will generate such a load/store?

The question, as written, doesn't make sense: the former half of the
question specifies a 32-bit access, but the second half of the
question mentions a single byte access.

LB and SB will generate single-byte accesses. It's impossible to be
misaligned, since bytes are the smallest addressable unit.

LW and SW are instructions which transfers 32 bits at a time.

> 2. Same question for 2B accesses. Can the 2B be located anywhere in the 4B
> data (or register)?

No; an aligned half-word access is naturally aligned on half-word
boundaries (meaning, address bit 0 is always zero). They can be
generated with LH or SH instructions.

> 3. For implementations with caches, for misaligned accesses access across
> cacheline boundary (let's ignore the case of crossing TLB boundary for now),
> the HW needs to split the transaction into two, correct? This should go
> without saying, but I like to understand the intent of the architecture.

That is correct, yes.

--
Samuel A. Falvo II

[Nhon Quach]

Samuel,

Thanks for the quick reply. For question 1, I mean for 32b data (or register) for 1B access, can the byte be located in any of the 4 possible locations within a 4B data (or register)?

Your definition of misalignment makes sense (i.e., it's usually defined that way). My question is more on the source of the data (i.e., where the intended source of data within a 4B data or register.

Nhon

 

================================================================
This electronic message transmission contains information from Abee Semi, Inc. which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by telephone (408.888.7248) or by electronic mail (nhon....@abeesemi.net) immediately.
================================================================

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsub...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAEz%3DsomxOCb9_Tr%2Bk3eV_qPBtXONgfz3Or%3DZXX8z1YKTPNwz6g%40mail.gmail.com.

[Benjamin Scherrey]

The address in memory to access the byte will be its absolute byte address. Loading it into your 32/64 bit register it will be the lowest byte and the rest set to zero. Is that what you are asking about? 

  - - Ben Scherrey 

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAEz%3DsomxOCb9_Tr%2Bk3eV_qPBtXONgfz3Or%3DZXX8z1YKTPNwz6g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/1548584105.710753.1483858704400%40mail.yahoo.com.

[Nhon Quach]

Ben,

Thanks. Your case is for load. For store, the data always come from the lower bytes of the registers? The reason I want to make sure is that I am not sure if there is a device or memory somewhere that will take the middle 2 bytes from a 4 byte register for example (again not likely, but I need to make sure).

Nhon

 

================================================================
This electronic message transmission contains information from Abee Semi, Inc. which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by telephone (408.888.7248) or by electronic mail (nhon....@abeesemi.net) immediately.
================================================================

To view this discussion on the web visit https://groups.google.com/a/ groups.riscv.org/d/msgid/hw- dev/1548584105.710753. 1483858704400%40mail.yahoo.com .

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CACo3Shg3DNJC58jLMpdCc9%2B8ZRv5uBygYuR8H6pb-htsyLFnPQ%40mail.gmail.com.

[Stefan O'Rear]

On Sat, Jan 7, 2017 at 11:56 PM, Nhon Quach <nhon....@abeesemi.net> wrote:
> Ben,
>
> Thanks. Your case is for load. For store, the data always come from the
> lower bytes of the registers? The reason I want to make sure is that I am
> not sure if there is a device or memory somewhere that will take the middle
> 2 bytes from a 4 byte register for example (again not likely, but I need to
> make sure).

I would like you to clarify which instructions you are using to do the
loads and stores.

SB - uses the low 8 bits
SH - uses the low 16 bits
SW - uses the low 32 bits
SD - uses the low 64 bits

-s

[Nhon Quach]

Stefan,

So, it's ALWAYS the lower byte(s)? The case I mentioned is not possible. Correct?

Nhon

 

================================================================
This electronic message transmission contains information from Abee Semi, Inc. which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by telephone (408.888.7248) or by electronic mail (nhon....@abeesemi.net) immediately.
================================================================

-s

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsub...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CADJ6UvNYn1QPTQntVTHcatHQSY_T9a52QyPjXRW7hgPb_mOLjw%40mail.gmail.com.

[Nhon Quach]

Actually, for a 4B store to an address that has the lower two bits = 2'b10. Some implementation may split the store into 2: one with the lower 2 bytes and one with the upper two bytes. Extending this, for 2B stores to an address with the lower two bits = 2'b11, wouldn't you have the case the data will be located in the middle even though they are all coming from the lower bytes in the register?

Sorry for not being clear earlier. I am working on the load and store unit of an implementation and still trying to figure out all the possibilities.

Nhon

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/1552425725.719344.1483862842023%40mail.yahoo.com.

[Stefan O'Rear]

On Sun, Jan 8, 2017 at 12:37 AM, Nhon Quach <nhon....@abeesemi.net> wrote:
> Actually, for a 4B store to an address that has the lower two bits = 2'b10.
> Some implementation may split the store into 2: one with the lower 2 bytes
> and one with the upper two bytes. Extending this, for 2B stores to an
> address with the lower two bits = 2'b11, wouldn't you have the case the data
> will be located in the middle even though they are all coming from the lower
> bytes in the register?
>
> Sorry for not being clear earlier. I am working on the load and store unit
> of an implementation and still trying to figure out all the possibilities.

Consider this from the C perspective:

/* C */
extern char foo, bar;
foo = bar;

/* assembly (with pseudo-ops) */
lb a0, bar
sb a0, foo, a1

/* assembly, final */
lui a0, 0x12
lb a0, 0x345(a0)
lui a1, 0x67
sb a0, 0x89a(a1)

The C compiler doesn't know or care whether foo and bar have even or
odd addresses, so lb has to consistently talk to the same part of the
register.

---

RISC-V memory system is logically 8 bits wide, little endian.

SB X8, (X9)

/* Least significant byte of X8 is stored at X9 */

SH X8, (X9)

/* Least significant byte of X8 is stored at X9 */
/* Next byte of X8 is stored at X9+1 */

SW X8, (X9)

/* Least significant byte of X8 is stored at X9 */
/* Next byte of X8 is stored at X9+1 */
/* Next byte of X8 is stored at X9+2 */
/* Next byte of X8 is stored at X9+3 */

---

If you have an 8-bit bus you can generate 4 memory cycles for a SW.
If you have a 32-bit bus then you'll likely need some amount of
realignment circuitry, depending on how your bus works (do you have
A1/A0, or do you use write enables?) I'm not clear on what your bus
looks like so I'm not clear on what you'd need to do, but there needs
to be a shifter _somewhere_ in order to allow the low 8 bits of a
register to talk to any byte of RAM.

A separate question is whether you want to support the logic for
generating 2 bus cycles from a SW at a misaligned address. It's
accepted and somewhat encouraged to treat that as an exception and use
a privileged exception handler to emulate the instruction, e.g.
https://github.com/riscv/riscv-pk/blob/master/machine/misaligned_ldst.c

-s

[Benjamin Scherrey]

Yes understand that there is no such thing as a byte sized register nor any way of addressing part of a register so a store must always push the entire contents of the register into the memory location desired exactly how it is configured. Storing a byte,  word,  etc must therefore take the least significant bits that fit the target size and simply lop off the rest. 

Therefore if the byte you wish to store is in the 2nd significant position, you'll have to shift/rotate it into the correct position before the store byte instruction if you want that byte stored into memory. Otherwise you'll get whatever randomly happens to exist in the least significant byte of the register and not the one you want. 

  -- Ben Scherrey 

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.