Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

lowRISC

Name: Anonymous 2016-02-05 17:59

lowRISC is creating a fully open-sourced, Linux-capable, RISC-V-based SoC, that can be used either directly or as the basis for a custom design. They aim to tape out their first volume chip this year.

Their open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board.

lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community.

http://www.lowrisc.org/

Name: Cudder !cXCudderUE 2016-02-06 5:31

RISC-V
When will these deluded academics stop designing shitty MIPS clones and focus on something more worth cloning, like x86?

Name: Anonymous 2016-02-06 7:33

>>2
Hello, welcome to our kickstarter to raise five hundred thousand dollars for a license from Intel to make x86 chips that can be legally sold in first world countries. For our stretch goal, we'll actually start designing and producing it.

Name: Anonymous 2016-02-06 15:50

>>2
What are your technical complaints about RISC-V?

Name: Anonymous 2016-02-06 17:52

Jackson 5 get

Name: Cudder !cXCudderUE 2016-02-06 17:54

>>3
Pre-Pentium patents have expired and IIRC some of the newer ones have expired too. I know for sure the 486 is public-domain. But also keep in mind, "if you don't get sued by someone trying to stop you from competing, you're not trying hard enough."

>>4
It's basically MIPS. Too many registers, horribly bloated and very sparse instruction encoding.

http://bbs.progrider.org/prog/read/1405230133

http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient

Look at how much cache the MIPS has relative to the x86 and ARM. And yet it still manages to be the least efficient, even after accounting for process variation and clock speed.

Name: Anonymous 2016-02-06 18:33

>>6
But is RISC-V really "basically MIPS"?
RISC-V decided not to build on OpenRisc because of some technical reasons that also apply to MIPS. You can read about it here.
https://blog.riscv.org/2014/10/why-not-build-on-openrisc/

The documentation for RISC-V is here.
http://riscv.org/download.html

Name: Anonymous 2016-02-06 19:52

Why do people still care about branch delay slots? The compiler can take care of those and it's simpler & more efficient for the hardware.

Name: Anonymous 2016-02-07 1:23

>>8
Because compiler writers are retards, and the hardware can do it better when you consider that a compiler will make optimizations for one model that won't apply to another. If we can finally toss out x86 (eat my anus, Cudder), might as well do it right. We don't need another toy arch like MIPS. CISC is the way to go, and the compiler can't be trusted. It should stick to more general optimizations on the AST and focus on small executable output.

Name: Anonymous 2016-02-07 4:03

>>9
no u

Name: Anonymous 2016-02-07 10:52

>>9
So basically reinvent x86?

Name: Anonymous 2016-02-07 11:00

>>6
What's the point in making a 486 chip when lowrisc exists today?

Name: Cudder !cXCudderUE 2016-02-07 16:20

>>8
No it's not.

>>12
Take advantage of 30+ years of software?

What's the point in making lowrisc when practically no software exists for it?

Name: Anonymous 2016-02-07 16:28

Let's keep backwards compatabily with x86 for the next 1000 years!

Name: Anonymous 2016-02-07 18:36

>>13
People nowadays do not write directly in assembly, cdr.

Name: Anonymous 2016-02-07 21:42

>>13
Why would I want to run proprietary software? The owners intentionally do not want me to use them.

Name: Anonymous 2016-02-10 21:01

>>14
Mormonism is backwards-compatible with Christianity, is backwards compatible with Judaism. x86 is just the start, you just watch, in 4000 years we'll still be starting up our computers in 16-bit real mode.

Name: Anonymous 2016-02-10 22:29

>>13
I would rather have new arch with no software, than arch bloated from the start by x86 compatible shit. You can take advantage of 30+ years of algorithm design and create something much better.

Name: Anonymous 2016-02-10 22:39

>>18
http://i.imgur.com/y0d5Pui.gifv

Name: Anonymous 2016-02-11 0:15

>>17
Mormon detected.

Absolutely nobody else thinks fucking Kolob space wizards is compatible with anything.

Name: Anonymous 2016-02-11 1:43

>>11
Yes. It's not CISC that's the problem, it's x86 specifically. Kill the instruction set and start over, design it with the intention to add instructions later instead of cramming them where they they fit for the next thirty years. Design it so you don't need a 1452345 stage pipeline.

Fucking AMD, man. They had to pull that x64 bullshit and now we're either stuck with x86 for the next twenty years or ARM is going to take over the Earth because now Intel is too cowardly to pop the x86 dick out of their asshole and design chips that are usable for devices that run on a battery. Windows Mobile is NEVER going to take off, Kiketel, people will NEVER want to run Windows apps on phones.

Name: Anonymous 2016-02-11 2:18

Design it so you don't need a 1452345 stage pipeline.
Something tells me you have no idea why pipeline depth is the way it is.

Name: Anonymous 2016-02-11 4:17

I use the decoding frontend of Intel CPUs to heat my apartment

Name: Anonymous 2016-02-11 11:15

>>23
http://bbs.progrider.org/prog/read/1443529343

Name: Cudder !cXCudderUE 2016-02-11 11:48

>>21,23
x86 is pretty good, what AMD did with it wasn't.

As process sizes get smaller, transistors become leakier and so it will be more energy efficient to have less of them. Especially when in the stopped state, leakage becomes a huge contributor to overall power consumption. The majority of the transistors on modern CPUs are in the caches, not the core itself, but making the caches smaller means lower performance. The solution is obviously to make the instruction set denser, i.e. more CISC, so adding a few more transistors to the core to enable removing a lot more from the caches.

Intel is already having to spend a lot of effort to reduce idle power consumption because they have the smaller process. When the ARMs get to that point, they'll have to deal with that problem too.

Name: Anonymous 2016-02-11 18:08

>>25
Holy fuck, you're a retard.

x86 is already very dense. Sure, there are a few places where there are long literals, but you'd be lucky to get just a few percent better in practical ISA overhaul. There's no way you're going to have any significant change in power going down this route, because you're not going to change cache size in any measurable way.

Name: Anonymous 2016-02-11 19:00

CISC is shit and x86 is even worse.

Name: Anonymous 2016-02-11 19:45

>>27
CISC is white male privileged scum.

Name: Anonymous 2016-02-11 19:56

VAX is a better CISC architecture.

Name: Anonymous 2016-02-11 20:04

VAX my anus

Name: Anonymous 2016-02-11 20:06

>>25
x86 is pretty good
TCTFOOAFM - Tell Cudder to fuck off on a full moon
Description
Creates a 150-character response telling Cudder to fuck off and posts it to progrider. Only works on a full moon. Alternative message lenghts are not supported. For alternative posting times, see TCTFOOAWM.
This opcode is 256 bytes wide.

Name: Anonymous 2016-02-11 21:03

>>31
Can I use it in my bootloader or does it need some kind of initalisation?

Name: Anonymous 2016-02-12 1:46

>>33
nice dubs
>>33
thanks

Name: Anonymous 2016-02-28 0:12

>>2
http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

Name: Anonymous 2016-02-28 8:01

>>34
Seems you haven't even readen the pdf you linked and are clueless what it is about. It's completely irrelevant to the discussion, as it's about firmware and external hardware security, not CPU design.
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -