[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=560

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|IN_PROGRESS                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #89 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #87)
> Reopening since this needs more evaluation:

mmm no, it doesn't.  the decision's been made.  what would help would be to
provide additional clarification and illustration of why we are not going to be
doing dynamic bytereversal, and to move as quickly as possible to clarifying
the spec.

> If we copy what VSX does

which we're not.  some time maybe in 2+ years we might add a microcoding layer
on top which provides bare minimum compliance with zero priority on
performance, but that is far, far into the future.

> then we'll have to implement the byteswapping in
> the ALUs, since that's what VSX does:

given the cost and complexity, 18 billion transistors, this is the strongest
possible case *not* to add dynamic bytelevel byteswapping in front of either
the regfile or in the ALUs.

even doing it as microcoding would cause such a catastrophic bottleneck on the
bytereversing that we would be in danger of penalising the entire BE mode.


> Notice how the big-endian and little-endian Power code is identical --
> implying that the registers switch between big-endian and little-endian,
> however it changes on AArch64 (64-bit Arm) since they define the registers
> to be little endian only and need to insert explicit byteswapping
> instructions.

great.  that's a solution in software.  one that doesn't add over half a
million gates in byteswapping (or penalise BE mode due to bottlenecking through
a reduced-bandwidth microcoded resource)

this is very useful to illustrate how VSX does things, and it also allows the
opportunity to underscore how deeply expensive this proposal really is.

we are not following IBM's path here.

re-closing this as invalid.

can we move on to clarification of the spec, covering the issues and
ambiguities that Alexandre has raised?

-- 
You are receiving this mail because:
You are on the CC list for the bug.