Slashdot Mirror

← Back to Stories (view on slashdot.org)

NetBSD/sparc Now With SMP

Posted by timothy on from the soon-you'll-have-a-fire dept.

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

6 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 Anonymous Coward · · Score: 1, Interesting

      The other day I was shopping around for printers and I ran across the spec sheet for an epson laser printer that claimed it was using a "SPARClite (MB 86935-50) 50 MHz RISC" processor.
      I thought it was curious at the time, and I wondered if it was really a Sparc CPU or if it was some company just calling it a sparc. If you want to check it out, here's the URL:

      http://www.epson.com/homeoffice/laser/2000/

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

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

      --
      Healthcare article at Kuro5hin
  2. 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.