[Libre-soc-dev] opcode allocation pressure
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Sep 1 12:03:34 BST 2022
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
>> 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
> 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.
More information about the Libre-soc-dev