Re:Why I will be using RISC-V in my next chip
by _yosefk on Saturday January 09, 2016 @05:13PM
(#10873106)
VLIW DSPs are in every phone. VLIW CPUs are almost certainly a bad idea and as to GPUs, AFAIK VLIW needs to coexist with barrel threading there which might create problems. But VLIW certainly has its place.
Re:Why I will be using RISC-V in my next chip
by adapteva on Saturday January 09, 2016 @05:47PM
(#10873199)
Most DSP archs came out of thr 90's and many of the cores today are a reflection of that trend (ceva etc). I worked on the TigerSharc DSP for 8 years and can tell you that from an implementation standpoint they can be a nightmare! Not sure they do have a viable place long term from an economical perspective.
Re:Why I will be using RISC-V in my next chip
by creshal on Saturday January 09, 2016 @05:40PM
(#10873179)
In DSPs, sure, but not in general-purpose CPUs or GPUs.
Re:Why I will be using RISC-V in my next chip
by wsxcde on Sunday January 10, 2016 @01:07AM
(#10874416)
I suspect the DSP makers just use VLIW because of interia.
They probably don't have the money or incentive to revisit their old decisions.
Also wouldn't you say that most of the stuff that used to be implemented on DSPs is now moving into ASICs? I wouldn't be so sure that VLIWs are going to be around forever.
Re:Why I will be using RISC-V in my next chip
by sklogic on Sunday January 10, 2016 @02:30AM
(#10874571)
VLIW is many times cheaper (in terms of power and area) than OoO. It is not going anywhere from the low budget range.
Re:Why I will be using RISC-V in my next chip
by wsxcde on Sunday January 10, 2016 @12:53PM
(#10876232)
But VLIW and OoO aren't the only two design points. The renewed interest in traditional inorder vector processors. In any case, I do think the point of DSPs was to be area/power efficient for certain specialized algorithms, and a lot of these are just becoming ASICs/specialized accelerators today.
Re:Why I will be using RISC-V in my next chip
by Marat_Dukhan on Saturday January 09, 2016 @11:27PM
(#10874150)
nVidia Kepler and Maxwell (i.e. the two latest archs ATM) use VLIW instruction encoding
Re:Why I will be using RISC-V in my next chip
by creshal on Sunday January 10, 2016 @09:52AM
(#10875455)
Do they? I can't find anything about it. VLIW for GPUs is always only mentioned in the context of AMD TeraScale – which has been obsoleted in favour of a RISC architecture five years ago.
Re:Why I will be using RISC-V in my next chip
by Marat_Dukhan on Sunday January 10, 2016 @01:17PM
(#10876352)
I guess that's because unlike AMD, nVidia doesn't officially document the GPU instruction set. But if you disassemble .cubin with nvdisasm, you'd see that code of Kepler/Maxwell is organized in bundles of 4/8 words, where the first word doesn't encode any instruction. Here is what Scott Gray of Nervana Systems, who developed a native assembler for Maxwell, write about it[1]: "Starting with the Kepler architecture Nvidia has been moving some control logic off of the chip and into kernel instructions which are determined by the assembler. This makes sense since it cuts down on die space and power usage, plus the assembler has access to the whole program and can make more globally optimal decisions about things like scheduling and other control aspects. The op codes are already pretty densely packed so Nvidia added a new type of op which is a pure control code. On Kepler there is 1 control instruction for every 7 operational instructions. Maxwell added additional control capabilities and so has 1 control for every 3 instructions."
[1] https://github.com/NervanaSystems/maxas/wiki/Control-Codes
VLIW has been the future since the 80s, and we're still waiting for the magic wonder compilers that can actually spit out efficient VLIW code. Even GPUs have abandoned VLIW (AMD TeraScale) in favour of RISC (Nvidia, AMD GCN).