diff options
author | Zack Buhman <zack@buhman.org> | 2024-04-02 17:37:49 +0800 |
---|---|---|
committer | Richard Henderson <richard.henderson@linaro.org> | 2024-04-09 07:43:31 -1000 |
commit | b0f2f2976b4db05351117b0440b32bf0aac2c5c6 (patch) | |
tree | 515c898292ad3c4d9076fb26a83dead6b7af6363 /linux-user/hppa | |
parent | 26d937237f363297e5f70efcb001b15b1cb0fc2b (diff) | |
download | qemu-b0f2f2976b4db05351117b0440b32bf0aac2c5c6.zip qemu-b0f2f2976b4db05351117b0440b32bf0aac2c5c6.tar.gz qemu-b0f2f2976b4db05351117b0440b32bf0aac2c5c6.tar.bz2 |
target/sh4: mac.w: memory accesses are 16-bit words
Before this change, executing a code sequence such as:
mova tblm,r0
mov r0,r1
mova tbln,r0
clrs
clrmac
mac.w @r0+,@r1+
mac.w @r0+,@r1+
.align 4
tblm: .word 0x1234
.word 0x5678
tbln: .word 0x9abc
.word 0xdefg
Does not result in correct behavior:
Expected behavior:
first macw : macl = 0x1234 * 0x9abc + 0x0
mach = 0x0
second macw: macl = 0x5678 * 0xdefg + 0xb00a630
mach = 0x0
Observed behavior (qemu-sh4eb, prior to this commit):
first macw : macl = 0x5678 * 0xdefg + 0x0
mach = 0x0
second macw: (unaligned longword memory access, SIGBUS)
Various SH-4 ISA manuals also confirm that `mac.w` is a 16-bit word memory
access, not a 32-bit longword memory access.
Signed-off-by: Zack Buhman <zack@buhman.org>
Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20240402093756.27466-1-zack@buhman.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Diffstat (limited to 'linux-user/hppa')
0 files changed, 0 insertions, 0 deletions