OpenRISC Gains Atomic Operations and Multicore Support 77
An anonymous reader writes "You might recall the Debian port that is coming to OpenRISC (which is by the way making good progress with 5000 packages building) — Olof, a developer on the OpenRISC project, recently posted a lengthy status update about what's going on with OpenRISC. A few highlights are upstreamed binutils support, multicore becoming a thing, atomic operations, and a new build system for System-on-Chips."
Re:How did OpenRISC not have atomic ops until now? (Score:4, Informative)
RTFA.
With a single core, it worked without atomic operations (albeit non-optimal. But then, which CPU is optimal?).
Re: (Score:3)
6502! Just kidding.
Re: (Score:2)
6502! Just kidding.
1 Accumulator and 2 Index Registers. Can't get more optimal than that!
Atomic operations in 6502 (Score:3)
Re: (Score:2)
Re: (Score:1)
yes, you do. in a preemptable OS, in a multi-threaded app, you need atomic operations to share data between threads, as any read-modify-write operation on shared data gets wrecked when it is preempted between the read and the write.
Re: (Score:2)
Which can be slow and clumsy though, often a bad choice to use for real time systems.
Re: (Score:1)
yes, that would be one way to implement atomic operations
Re: (Score:3)
yes, you do. in a preemptable OS, in a multi-threaded app, you need atomic operations to share data between threads, as any read-modify-write operation on shared data gets wrecked when it is preempted between the read and the write.
Furthermore, what is atomic in terms of context switching preemption is not necessarily atomic in terms of memory bus arbitration. The two can usually coincide, but they don't have to.
Re: (Score:2)
What about multi-processor systems that share memory? It's not multi core if each processor only has one core.
Re: (Score:2)
CAS is an atomic instruction, probably even more atomic than the stuff in OpenRISC (which uses a load-exclusive/store-conditional pair of instructions, similar to many RISC machines).
Re: (Score:3)
Actually I found the atomic ll/sc stuff to be convenient even with multiple tasks on a single processor, as it means no need to lock out context switching for atomic operations.
Even with just a single core in the processor you will still hit concurrency issues if there are other processors in the system sharing some resource.
Re: (Score:2, Informative)
From the blog post linked in the article:
"the requirement for implementing a mutex is that an mutex operation is never allowed to be interrupted. Previously on OpenRISC this was done by making a syscall that disabled all interrupts as it's first instructions."
Is Gains? (Score:1)
No, fool, I is Gains Atomic. [sounds like an great stage name]
Re: (Score:1)
Re: (Score:1)
No, fool, I is Gains Atomic.
Gaines Burgers, not Atomics!
Re: (Score:3)
> Absolutely nothing over any of the well supported and understood open source MIPS implementations.
Ah! Read this ( http://jonahprobell.com/lexra.... [jonahprobell.com] ) and be cautious when re-implementing the MIPS ISA..
Re: (Score:3)
Re: (Score:2)
Re:What advantages? (Score:4, Insightful)
MIPS may (or may not be) "open source", however it is not free to implement. Implement the latest MIPS ISA without a license agreement from MIPS and you'll be sued to smithereens. You won't be sued if you implement OpenRISC though.
Re: (Score:2)
Or to be clearer, MIPS owns several patents on instructions in the ISA. Though I think some of them were worked around another way since the patent covers implementation.
But many other architectures are patented as well - x86 is covered by many patents (most owned between AMD and
Re: (Score:3)
And those patents, or more specifically the single patent about the unaligned load and store instructions on MIPS expired years ago. To be specific it expired in December 2006.
So while the patent was an issue back in ~200 when OpenRISC was launched it is no longer relevant, and you would be better off implementing a MIPS32 and MIPS64 bit core.
I would also point out that there are full open source implementations of the SPARC architecture, which never suffered from the patent problems of MIPS.
Re: (Score:2)
I would also point out that there are full open source implementations of the SPARC architecture, which never suffered from the patent problems of MIPS.
...but they do suffer from (a very poor implementation of) register windows.
OpenSPARC? (Score:2)
Is this [wikipedia.org] free to implement?
Re: (Score:2)
" This is just another cause-we-can hobby project on the front page of Slashdot."
OpenRISC is far from a "cause-we-can" project.
Re: (Score:2)
oh? what problem does it solve?
Re: (Score:2)
"oh? what problem does it solve?"
What the fuck is so hard to understand here? The answer is in the name of project: An opensource CPU core. There, was that so hard?
Besides being a snarky ass, what was the point of your post? It sounds as if you would rather spark a flame war rather than do some actual research which would take oh lets say 5-10 minutes.
There are other open source cores but none of them are trying to provide a full blown CPU core that could potentially be used for mobile or desktop use. Most
Re: (Score:2)
You have not even answered the question with all your ranting and hot air. Again, what problem does an open source CPU format solve? I cannot think of a one, my open source software works fine on x86, sparc, MIPS, ARM7 (and anyone interested can get the specs for most of those architectures). I'll even make a claim that open specs are good enough for a CPU, irrelevant whether the particular mask patterns are known.
Re: (Score:2)
and for a couple bucks you can buy an 8 or 16 bit cpu and slap on on a board with your custom FPGA, you're doing it wrongly.
Re: (Score:2)
eh, most of my life was engineering physical things including controllers. You take a couple buck CPU and slap it on a board with your FPGA, in 99.9999% of cases making your on fucking CPU is a waste of time and money. It's like a developer who says "I need to write my own web server from scratch to run my php code"
Re: (Score:2)
And yet we have multiple open source web servers, each with varying levels of complexity, feature sets and usage cases.
Re: (Score:2)
How about embedding a CPU core into your ASIC design, without paying licensing fees to MIPS or ARM?
Re:What advantages? (Score:5, Informative)
What are the advantages of openrisc?
It is free, so if you want to run a softcore, there are no license fees. If you can read Verilog, you can verify that there are no NSA backdoors.
What are the performance of such a softcore?
An FPGA softcore is going to run several times slower, and consume several times as much power, as a hardcore. If you need a small amount of computing, and most of your app is in the FPGA fabric, then that is reasonable, although you might be able to get by with an 8-bit softcore like PicoBlaze, or even roll your own mini 8-bit core with opcodes customized for your app (this is not that hard, and is a fun project if you are learning Verilog and ready to go beyond blinking LEDs). But if you are doing something compute intensive, you may want to look for something with an integrated hardcore.
Can I expect to have something usable?
That depends on what you are using it for.
Re: (Score:2)
It is also possible to use the Verlog to make an ASIC if you go into production.
Trusting the compiler (Score:2)
If you can read Verilog, you can verify that there are no NSA backdoors.
But is there a backdoor in your Verilog compiler [bell-labs.com]? Normally, you might use David A. Wheeler's diverse double-compiling method [dwheeler.com] to ensure beyond reasonable doubt that your compiler isn't backdoored. But diverse double-compiling doesn't work unless the compiler is written in the same language that it compiles. And I don't think the Verilog compiler is written in Verilog.
you might be able to get by with an 8-bit softcore like PicoBlaze
Wikipedia's article about PicoBlaze states that it's not free to use on anything but a Xilinx FPGA. So if you switch to Altera or go into produ
Backdoors can be obfuscated (Score:2)
Re:What advantages? (Score:4, Funny)
"roll your own mini 8-bit core with opcodes customized for your app (this is not that hard"
Not that hard by Verilog standards. The sight of it tends to make software developers run in terror.
Re: (Score:2)
Re: (Score:2)
Exactly. This is very much a hardware thing - and if you want a processor embedded in your chip, it's because you want to run software. Spending time messing around with intricate hardware design is just going to divert you from the important tasks.
Re:What advantages? (Score:4, Interesting)
Another advantage of an open source softcore, is that you can add your own application specific opcodes. You could run your app in a profiler with the standard instruction set, and identify the hot spots. If a big chunk of your CPU time is spent in a single tight loop, you could implement that code directly in FPGA fabric, and execute each iteration in a single clock tick with a custom instruction. For instance, lets say you need to run some sort of CRC or crypto, with involves shifting, masking and adding bits. That would be easy to code up in Verilog into a single instruction, which is then executed by extending OpenRisc for the new opcode. Then just use the "asm" feature of GCC to put that opcode in the inner loop of your C program. Depending on your app, it is possible that you could get better performance from a customized softcore than from a generic hardcore, like ARM or MIPS.
Endianess (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Because everything sane uses big-endian? Really, little-ending is a pain in the ass, something you put up with on x86 family, or on projects where they had a choice and the early hardware dev chose little-endian without consulting with the software people. It's really hard to say which is used the most, but little-endian definitely is not a clear winner at all. It's also a sort of Rorshach test to tell who started programming as a PC programmer versus everyone else.
The internet for example is all big-end