Slashdot Mirror


NetBSD/sparc Now With SMP

jschauma writes "Largely due to the efforts of Paul Kranenburg, NetBSD -current now supports SMP on sparc. It has been tested on a SPARCstation 20/712, sun4/690 and other systems. See Matthew Green's message to the port-sparc mailing list." (i386 got this back in October.)

13 of 29 comments (clear)

  1. Curious about SPARC... by mcgroarty · · Score: 3, Interesting

    Out of curiosity, where are SPARCs being used the most? What are some of the unique characteristics of SPARC processors?

    1. Re:Curious about SPARC... by mcgroarty · · Score: 3, Insightful
      Okay, register windows are interesting. That means very fast context switching. So between that, Sun's use of SPARCs and the running profile of most Java apps I've seen, I'm guessing that SPARCs are geared toward software with nasty-obscene thread counts. :)

      I could see why SMP would be a priority.

    2. Re:Curious about SPARC... by mcgroarty · · Score: 4, Interesting
      There's some info related to the SPARCLite here. It claims that Fuji's SPARCLite core is used in a large number of embedded devices.

      Is this related to the embedded Java processor Sun announced a while back? I never read up on that, and I wasn't sure if they really meant it was running Java bytecode, or if it was merely a processor that was well-suited for Java. Native bytecode sure sounded unlikely.

    3. Re:Curious about SPARC... by Guy+Harris · · Score: 2
      There's some info related to the SPARCLite here .

      There's also some on Fujitsu Semiconductor's Web site as well.

      Is this related to the embedded Java processor Sun announced a while back?

      No.

      I never read up on that, and I wasn't sure if they really meant it was running Java bytecode, or if it was merely a processor that was well-suited for Java. Native bytecode sure sounded unlikely.

      "Sounds unlikely" does not necessarily imply "not true"; picoJava does, indeed, run Java bytecode as a native instruction set - or, at least, did, or was intended to; I can't find anything from Sun's home page that speaks of them selling any processors other than UltraSPARCs. A Google search for "Sun Microelectronics" found, as the topmost hit, a page for UltraSPARC processors, so perhaps they've killed off picoJava and microJava (I think microJava might not have had bytecode as its native instruction set), along with the MAJC chip (some VLIW thing) they were working on at some point. (You can still find stuff about picoJava, microJava, and MAJC on Sun's web site from the search box, but the papers you find look suspiciously orphaned.)

    4. Re:Curious about SPARC... by Guy+Harris · · Score: 3, Interesting
      That means very fast context switching.

      Well, that depends on how you use them. Solaris does not, as far as I know, assign particular register windows to particular processes/threads, but uses them to avoid register saves/restores for short trips up and down the call stack. (For sufficiently long trips, of course, you'll need to do them.)

      They may have a clever way of avoiding saving all of a process's windows on a context switch (it's been ages since I dealt with SPARC or context-switching code for SPARC), and they might be able to avoid that for threads running in the same address space, but I suspect register windows, used the way Solaris uses them, are, at best, no help for context switching, and they might hurt.

      I don't know whether NetBSD uses them differently.

    5. Re:Curious about SPARC... by pmz · · Score: 4, Interesting

      One thing I find interesting about SPARC is that it looks like it was designed for UNIX. Register windows, priviledged mode, many SMP implementations, and the RISC approach in general just makes SPARC a shoe-in for C-language based multi-user multi-processing systems.

      Also, SPARC is far from the kludge that is x86. The transition from 32-bit to 64-bit looks like it went smoothly, and there is 32-bit compatibility built into the 64-bit instruction set.

      Additionally, RISC ISAs are easy to read and understand.

      You can license the SPARC brand for $99 and make your own compliant implementations with only encouragement and a pat on the back from Sun, Fujitsu, etc. Try getting that from Intel! In fact, I see SPARC as one of the get-a-way vehicles if/when Palladium becomes standard on x86 systems. A group of determined people can create a Free SPARC implementation for Free software, and Microsoft and Intel can only pick their nose and cry about it.

  2. Cool! by CoolVibe · · Score: 2

    Now I can finally _use_ that extra processor card in that rickety old SS10 of mine :)

    1. Re:Cool! by SN74S181 · · Score: 2, Informative

      My rickety old SS10 is a SS10BSX, so it would be a true waste to run anything but Solaris. In addition to two processors it has dual CG14 video hardware on the motherboard and there isn't a 'free' X server out there that supports single, let alone dual CG14 on a SS10.

    2. Re:Cool! by SN74S181 · · Score: 2

      Well, yeah. It has. In 256 color mode.

      Now why would I want to run a dual-headed Sparc box with 24 bit color framebuffers in 256 color mode?

      The CG14 'support' in XFree86 should be stamped 'broken' with a big red rubber stamp. Not that I complain loudly very often, as *I* haven't dug in and done it myself...

  3. SMP? by smartfart · · Score: 2

    Someone wanna help me out here? This is just for sparcs, right? Which BSDs do SMP on i386 hardware?

    1. Re:SMP? by CoolVibe · · Score: 4, Interesting

      FreeBSD and NetBSD at the moment. Dunno about BSD/OS though, it's been too long ago since I meddled with that.

  4. Darn! by nutznboltz · · Score: 2

    And I had just installed FreeBSD/sparc to get SMP.

  5. The "BSD is dying" troll is dying. by nutznboltz · · Score: 4, Funny
    News flash: The frozen body of the "BSD is dying" troll was discovered in an alley yesterday along with a cardboard sign saying "will cut-and-paste anything for food".

    Film at 11.