[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

[bugzilla-daemon at libre-soc.org]

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

Cole Poirier <colepoirier at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |colepoirier at gmail.com

--- Comment #128 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #127)
> (In reply to Cole Poirier from comment #112)
> 
> > For what it’s worth, I just reviewEd the 16b compressed encoding page and I
> > can definitely see how Alexandre came to the operating paradigm i.e. set of
> > axioms interpreted from the wiki page, that he was operating under until
> > this comment. 
> 
> (referring to you 3rd person, alexandre, i am aware you are there, it makes
> context when answering cole easier/shorter)
> 
> what happened was: alexandre wanted to discuss alternative ideas (which i am
> normally in favour of).  however one of those ideas was an "extender" that,
> similar to VLE, a batch of multi-bit patterns actually indicate that the
> overall length is to be 32 bit, not 16bit.
> 
> it's taken something like 3-4 days and over 60 comments to make it clear
> that this idea was already eliminated right from the very start, even before
> alexandre joined the discussion.
> 
> however i specifically did not say that in a categorical declarative
> fashion, because if i had done that he would have been puzzled, perhaps
> offended, and asked "err why?" anyway.
> 
> by instead providing explanation he has learned a huge amount in a short
> amount of time particularly the difference between hardware and software.
> 
> the purpose of the wiki page is as a specification, "to be implemented" i.e.
> to be frozen.
> 
> the purpose is not for said implementors to come up with, after it is
> frozen, to come up with and discuss new encoding ideas!
> 
> consequently i am not going to put in a massive section emphasising that it
> is 16bit only.  i will mention briefly that it is not like VLE, and leave it
> at that.
> 
> with all tables throughout the entire page being exactly 16 bits on length
> it should be obvious that Compressed *is* 16 bit, and i am concluding that,
> as alexandre said, it was simply his *desire* to have a 32bit length in
> Compressed (despite repetitions that this cannot happen) that stopped him
> from seeing this.
> 
> regarding new bugreports, i would like everyone to focus on review of the v1
> Compressed, no other discussion, and once reviewed we decide what to look at
> next (probably under new bugreports such as "v2 review" and so on)

The thing you’ve missed is there are 8 (eight!!) mentions of SV on the page.
You need not add “a massive section” stating it’s 16bit repeatedly, but I
highly suggest you at least go over it editing out any mentions of SV.
Additionally, specifications *must* be clear and unambiguous, which the current
page is certainly not. I cannot understand why you would resist going over it
and editing it to make it clearer and more unambiguous. I understand that the
purpose of this bug report has transformed into explaining g the difference
between software paradigms and hardware paradigms to Alexandre, I have ever
have not at any point been under this misapprehension and I *still* find the
current proposed encoding wiki page far to confusing for what should be an
unambiguous specification. So, I’ll mention again that we’re almost at comment
#130, so if not for our sakes in terms of making the discussion shorter and
much more focussed, for the sake of the VM/server/database, I’m going to
suggest again that we migrate the discussion of 16C to a new bug report that is
*strictly* focussed on discussing C16, and *only* C16 without the 60+ comments
of confusion in between?

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