| Summary: | make elwidth's encoding more intuitive | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Alexandre Oliva <oliva> |
| Component: | Specification | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | libre-soc-isa, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Other | ||
| See Also: | https://bugs.libre-soc.org/show_bug.cgi?id=563 | ||
| NLnet milestone: | --- | 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: | ||
| Bug Depends on: | |||
| Bug Blocks: | 213 | ||
|
Description
Alexandre Oliva
2020-12-30 19:25:27 GMT
00 DEFAULT default behaviour for operation
01 ELWIDTH=w Word: 32-bit integer
10 ELWIDTH=h Halfword: 16-bit integer
11 ELWIDTH=b Byte: 8-bit integer
interestingly it's w and b that swap. yep like it.
> for floating-point encodings, if we wish 64-bit to be the default, but also
> support 128 bits instead of either f16/bf16, we could still do this, having
> the shift amount be a signed 2-bit number ;-)
urrr :)
can you write it out? (remember bf16 is fly in the ointment)
note that 128-bit can instead be supported by just prefixing the base f128 instructions as described in bug #563. this would mean that the elwidth encodings for fp can still be: 00 default 01 f32 10 f16 11 bf16 (instead of 8-bit) done |