Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Hardware Hacking Build

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."
This discussion has been archived. No new comments can be posted.

OpenRISC Gains Atomic Operations and Multicore Support

Comments Filter:
  • by mwvdlee ( 775178 ) on Wednesday May 14, 2014 @09:18AM (#46998447) Homepage

    RTFA.
    With a single core, it worked without atomic operations (albeit non-optimal. But then, which CPU is optimal?).

  • Re:What advantages? (Score:5, Informative)

    by ShanghaiBill ( 739463 ) on Wednesday May 14, 2014 @09:45AM (#46998641)

    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.

  • by Node ( 9991 ) on Wednesday May 14, 2014 @12:14PM (#46999977)

    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."

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Working...