[Libre-soc-dev] opcode allocation pressure

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Thu, Sep 1, 2022 at 11:55 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Thu, Sep 1, 2022, 02:01 Luke Kenneth Casson Leighton via Libre-soc-dev <libre-soc-dev at lists.libre-soc.org> wrote:
>>
>> but it is *not the whole story* because the GF ops have
>> not been allocated, nor rounding converts, nor 3D textures,
>> and additionally there are the Transcendentals
>> https://libre-soc.org/openpower/transcendentals/
>>
>> fortunately the Ts can fit into EXT063 and EXT059 naturally.
>
>
> looking over the transcendentals encodings, they both have
> 5 bits set to `///`, which iirc is don't care bits, this seems like a waste,

those kinds of subtle decisions would be down to the IBM Architectural
Resource (aka "opcode allocator" team) although we can obviously
make recommendations.

> we should have those be an `EO` expanded opcode field (where RA would
> go for single-input instructions) or just part of XO (for 2-in instructions),
> reducing the number of XO values used by 32x.

the problem is that doing so complicates the decoder as it becomes
not 2 levels but now 3 levels of MUXing.

if you look at the tables i am following the pattern set by the IBM
Architectural Resource Allocation team, there are already other 2-op
A-Form instructions which likewise ignore bits 21-25.

there will be a reason for it.

l.