[Libre-soc-bugs] [Bug 1044] SVP64 implementation of pow(x,y,z)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #49 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #47)
> (In reply to Luke Kenneth Casson Leighton from comment #46)
> > the assumption that you are making is one that a *SIMD* architecture
> > has because the ISA directly connects to the back-end hardware.
> 
> no, i was thinking of vertical-first mode, not SIMD. I do know how it works,
> having read your explanations for years and having read about how Mitch
> Alsup's cpu design works.

... but you then go on to make assumptions about the hardware
implementation, which is completely inappropriate to do given
that there will be *multiple* implementations, of varying
capability

in amongst those, the *only* thing that is 100% guaranteed
is that "smaller code size results in lower power consumption".

therefore you *must* stop limiting your thinking based on the
*assumption* that *we* will implement *only one* piece of
hardware, and that that one piece of hardware will have
"some limitation or other on performance if feature X of SVP64
is utilised".

the entire purpose of the entire grants every single one is to
prove the *ISA* not the implementations *of* the ISA.



> * the data-flow graph of the code I write directly determines minimum
> latency even if the cpu has effectively infinite resources. you can't escape
> Amdahl's law. not even if you have a monster cpu with all the fanciest SV
> features.

again: *not your damn problem*!!! :)

that is the *hardware implementor's* problem to deal with, not
yours, right now.

i asked you not to second-guess the hardware implementation(s)
and you did exactly that only 5 minutes later!

(In reply to Jacob Lifshay from comment #48)
> I'm dropping the conversation about performance, it's a distraction 

yes it is. 100%.

we are proving - and demonstrating - the *ISA* here,
not implementations *of* the ISA, ok? we simply cannot
guess what *future* implementors will come up with that
solve every single one of every single "objection related
to performance". therefore we *must* drop it, stone-cold,
as "100% not our problem".

exactly like the Khronos Group does not specify performance in the
Certification of a given implementation.  only "do the tests pass,
yes, then you got your Compliance Certificate".

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