3 ms·

You comment is a drive-by disparagement without much detail. If you don't care to elaborate here, then how about a link to something more substantial? I glance

You comment is a drive-by disparagement without much detail. If you don't care to elaborate here, then how about a link to something more substantial? I glanced at Wikipedia to see if I could learn for myself. When you say "horrible assembler instructions", does that mean something like the typical RISC trope of e.g. implementing a MOVE instruction by using an ADD with R0 as a source (always 0 in this architecture)? If so, what's the big deal? An assembler can easily convert a programmer's MOVE into the appropriate ADD. That's "horrible"??? Plus, it's not the 1960s any more. Very little code is nowadays written in assembler.

Annatar 8y ago
Quite a lot of code is written in assembler, especially if one is in the demo and cracking scene. Low level driver implementations are often written in assembler. Machine implementation details of the kernel are written in assembler. Operating systems are still very much the subject of much research in computer science and much there is still unexplored frontier, terra incognita. The instruction set of RISC V is not intuitive and is very clumsy even by RISC standards: compare for example the SPARC V9b and RISC V ISA. Then there is the issue of RISC V ISA closely mimicking that of intel processors, a notoriously bad processor design and it's dst, src syntax to boot (although using AT&T style assembler can ameliorate that horrible state of affairs somewhat). A processor with a very clumsy ISA that is hard for humans to memorize and program is going to be even harder for compiler writers and for the compiler. Then there is the doubt that we don't know what the performance of this hardware will be: is it going to be a number cruncher like UltraSPARC T5 or POWER7? Who knows. But compiler writers have struggled with writing optimizing compilers for RISC processors for a very long time, most infamous examples being Itanium and UltraSPARC. To make matters worse, UltraSPARC processors are very fast, and yet the code generated never took advantage of that speed until Solaris 10 and UltraSPARC T3. Judging by the ISA alone, it's extremely doubtful RISC V will fare any better: it's too clumsy. Final nail in the coffin: re-invention of the wheel. There is already OpenSPARC. RISC V is a solution to a non-existent problem, marketed as the need for a fully open source processor, even though OpenSPARC's Verilog code is copyrighted under the GPL. http://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html http://www.oracle.com/technetwork/systems/opensparc/openspar...

Annatar 8y ago

Quite a lot of code is written in assembler, especially if one is in the demo and cracking scene. Low level driver implementations are often written in assembler. Machine implementation details of the kernel are written in assembler. Operating systems are still very much the subject of much research in computer science and much there is still unexplored frontier, terra incognita. The instruction set of RISC V is not intuitive and is very clumsy even by RISC standards: compare for example the SPARC V9b and RISC V ISA. Then there is the issue of RISC V ISA closely mimicking that of intel processors, a notoriously bad processor design and it's dst, src syntax to boot (although using AT&T style assembler can ameliorate that horrible state of affairs somewhat). A processor with a very clumsy ISA that is hard for humans to memorize and program is going to be even harder for compiler writers and for the compiler. Then there is the doubt that we don't know what the performance of this hardware will be: is it going to be a number cruncher like UltraSPARC T5 or POWER7? Who knows. But compiler writers have struggled with writing optimizing compilers for RISC processors for a very long time, most infamous examples being Itanium and UltraSPARC. To make matters worse, UltraSPARC processors are very fast, and yet the code generated never took advantage of that speed until Solaris 10 and UltraSPARC T3. Judging by the ISA alone, it's extremely doubtful RISC V will fare any better: it's too clumsy. Final nail in the coffin: re-invention of the wheel. There is already OpenSPARC. RISC V is a solution to a non-existent problem, marketed as the need for a fully open source processor, even though OpenSPARC's Verilog code is copyrighted under the GPL. http://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html http://www.oracle.com/technetwork/systems/opensparc/openspar...