<p>PUBLIC FEEDBACK – NON CONFIDENTIAL</p>

<p>Before addressing specific concerns, we need to reiterate from our previous reply: “The OPF ISA TWG can only vote on a complete RFC, and this or any other feedback given before we have a complete RFC is not binding with respect to the outcome of a vote by the OPF ISA TWG or the votes of individual voting members.”</p>

<p>We regret any misunderstandings about the expectations for an RFC submission.  The aggregate proposal embodied in sections 1 and 2 of the simple_v_spec.pdf may enable us to give more confident feedback about the likelihood that the Simple-V looping mechanism RFC, when complete, will receive a positive vote from the workgroup, and how to improve that likelihood.  The aggregate proposal is not a complete RFC submission, and we believe it will require significant modifications (several person-months of work) to reach a point where we can make final, detailed adjustments collaboratively.  Until that time, we can only make coarse-grain observations about missing content and style issues.</p>

<p>One ongoing misunderstanding is the belief that there’s a hidden development process and/or list of requirements that will culminate in a successful RFC.  The goal is simply to provide introductory motivation and the equivalent of a diff file that contains the changes to the existing document in front-to-back order, preferably with terse motivations for non-editorial changes.  To ease and accelerate the evaluation process, we recommend that changes include a reasonable amount of surrounding context (existing architecture words that aren’t changing).  Any content that doesn’t fit the foregoing description has no place in the RFC.  So, for example, references to other architectures and business considerations may be appropriate in limited quantities in the introductory motivation, but nowhere else should they appear.</p>

<p>The way successful RFCs are developed is through flagrant plagiarism.  Find parts of the existing architecture that have superficially similar functions to what is trying to be described, then copy, paste, and modify.  Carefully use the terminology defined in the architecture and the language and editorial constructs that it commonly employs.  Be consistent in the choice of words and language and editorial constructs to describe the new functionality.  Describe function from the ground up or with reference to other parts of the Power architecture, but without external references.  Make cross references to related content in a different section that completes a concept instead of duplicating large parts of descriptions.  The process is straightforward.</p>

<p>I skimmed the aggregate proposal and have two functionality-related comments that are likely to impact the effort required to write and/or the acceptability of the completed RFC.  The aggregate proposal uses Little Endian ordering for register contents unless I misread.  The existing architecture uses Big Endian ordering for register contents and that change to existing functionality is highly unlikely to be an acceptable blanket change.  It will almost certainly be necessary to create a control mechanism to reverse the orientation with which the bytes are interpreted.  The effort required to complete that will be quite large.  My other comment is about XLEN.  Reading front to back, XLEN just sort of appears without definition.  That would need to be fixed.  But the amount of effort required to complete an RFC that bases the entire architecture on XLEN is quite large and would be very difficult/controversial in places.  I strongly recommend that XLEN be deferred to a later RFC to increase the tractability of the initial Simple-V looping mechanism RFC.</p>