Bug 928 - ld/st with shift
Summary: ld/st with shift
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 952
  Show dependency tree / graph
 
Reported: 2022-09-21 00:26 BST by Jacob Lifshay
Modified: 2022-10-14 15:32 BST (History)
1 user (show)

See Also:
NLnet milestone: NLnet.2022-08-051.OPF
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2022-09-21 00:26:12 BST 
couldn't find a bug for this, so making one.

ld/st with shift isn't very useful for rt = mem((ra << sh) + imm) unless imm is >25-bits or so, so instead i think the ops we'll want are (only listing loads here, stores are analogous):
rt = mem(pc + (rb << sh) + imm) -- can be encoded by ra=0

rt = mem(ra + (rb << sh) + imm)

we'll also want a way to enable bounds checking and base addr. addition for webassembly, so imho we reserve the max sh value (for 3-bit, that'd be sh=7) to enable wasm addressing mode instead of shifting. for details, see https://bugs.libre-soc.org/show_bug.cgi?id=585

we could alternatively reserve sh=0 for wasm, since that's redundant with the existing ld/st ops and that allows sh to reasonably be only 2 bits if we're low on space. imho reserving sh=0 seems like the best idea in retrospect.