Bug 610

Summary:	renumber FP regs as pairs for ELFv2 ABI compliance
Product:	Libre-SOC's first SoC	Reporter:	Alexandre Oliva <oliva>
Component:	Specification	Assignee:	Luke Kenneth Casson Leighton <lkcl>
Status:	CONFIRMED ---
Severity:	enhancement	CC:	libre-soc-isa
Priority:	---
Version:	unspecified
Hardware:	PC
OS:	Other
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:

Description Alexandre Oliva 2021-03-04 22:40:55 GMT

Since the ELFv2 ABI requires 128-bit VSX registers, and we don't want to implement VSX, I thought we could group our own 64-bit registers in pairs, each equivalent to a single VSX register, so that we could comply with the calling conventions without software emulation of VSX opcodes and registers.

We could accomplish this by shifting our FP register numbers by one bit, so that only the even-numbered ones would be directly accessible/nameable.  Getting to the odd-numbered ones would require vectors, which is not unlike other recent changes that made only registers multiple of certain powers of two directly nameable.

We'd go from 128 separate 64-bit FP registers to 64 pairs of 64-bit FP registers, which could pave the way for future extensions that would use the pairs as a single float128 register.

This amounts to a very tiny actual change to the implementation, that is mainly a different way of looking at our FP regs so as to avoid a huge performance penalty we'd incur in ELFv2 VSX emulation.

Comment 1 Luke Kenneth Casson Leighton 2021-03-04 23:19:24 GMT

thank you for recording this lxo so thst it can be evaluated during an appropriate phase (after the current implementation phase).

SV REMAP contexts do provide the means to offset and/or multiply SVSTATE.srcstep numbering, so as to match VSX precisely.

forever irrevocably damaging SV through complications to accommodate a 15 year old concept that itself is known to be harmful is not something that should be taken lightly.

i fully expect SV to supercede VSX wholly and entirely over a period of 10 to 25 years.

in this light do we *really* want to irrevocably and irreversibly damage SV through adding arbitrary offsets?

additionally i see the performance slowdown as not a detriment at all.  in fact the total opposite: as an incentive to help expedite the process of turning VSX into a legacy part of OpenPOWER that is phased out as quickly and as quietly as is realistic and practical, over the course of the next decade.

SV is not being designed with short-term goals in mind.  it's being designed for a 20 to 30 year lifespan.