Bug 562 - make elwidth's encoding more intuitive
Summary: make elwidth's encoding more intuitive
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: PC Other
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 213
  Show dependency treegraph
 
Reported: 2020-12-30 19:25 GMT by Alexandre Oliva
Modified: 2020-12-30 22:01 GMT (History)
2 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Oliva 2020-12-30 19:25:27 GMT
currently it's:

00 	DEFAULT 	default behaviour for operation
01 	ELWIDTH=b 	Byte: 8-bit integer
10 	ELWIDTH=h 	Halfword: 16-bit integer
11 	ELWIDTH=w 	Word: 32-bit integer 

which seems out of order to me.  make make the two bits encode i and have the bit length be 8 << i, or 8 << (3-i) if the default is to be zero.

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 ;-)
Comment 1 Luke Kenneth Casson Leighton 2020-12-30 19:47:52 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)
Comment 2 Jacob Lifshay 2020-12-30 19:50:09 GMT
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)
Comment 3 Luke Kenneth Casson Leighton 2020-12-30 22:01:44 GMT
done