[Libre-soc-dev] setvl lost its reserved fields (was: setvl gaining CTR mode)
luke.leighton at gmail.com
Sun Jul 3 11:03:45 BST 2022
To all VCs and their Agents
To all OPF ISA WG Members
To all OPF Members and Stakeholders
Please disregard the contents of this thread in its entirety.
The discussion is only public because we do not censor discussion as it would be a direct conflict with our funding body, NLnet.
At no time will any changes be made to the specification as a result of matters raised by Jacob Lifshay in this thread.
Please disregard this thread and do not consider it to contain any committments in any way.
On July 3, 2022 10:52:16 AM GMT+01:00, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Sun, Jul 3, 2022, 02:29 lkcl <luke.leighton at gmail.com> wrote:
>> when i said "it is too late" it means, "it is too late". you should
>raised this (and offered to help) 6 to 24 months ago.
>I did, as i mentioned in the last message, which you claim you ignored.
>will copy that part of it again in hopes that you will read it this
>I wrote (added emphasis):
>> Also, this is effectively changing back to the design *we already
>on* iirc (see link below), that had been lost presumably when setvl was
>crammed into the bitmanip major op.
>please read the bottom paragraph of this email for an alternative idea
>requires no implementation changes whatsoever, only spec. text
>our implementation was correct in the first place...).
>third time of repeating, you have not listened the first time and you
>> not listened the second time.
>> i have not read anything that you have written in the past two
>that is a *major* problem, if you don't listen, why should I bother
>to convey anything? it doesn't help either of us. please do read
>I do at least read your messages even if i disagree with their
>i asked for an opinion on the minor incremental change to add CTR mode.
>what i requested in the last message is a even more minor change than
>adding ctr mode....all that is happening is a constant-0 bit is
>changes to assembly syntax, what each bit of the instruction encoding
>currently does, unit tests, etc.
>If you don't like renaming fields at all, then we can do what is 100%
>equivalent (except in clarity) -- state that all values of SVi with the
>set must trap and are reserved for future extensions (with a
>*non-normative* note explaining what could be done -- non-normative
>it explains what the idea is, but it isn't a part of the official
>that imposes any requirements).
More information about the Libre-soc-dev