OpenBSD Journal

KernelTrap: Supporting The UltraSparc III

Contributed by jolan on from the cache-aliasing-sucks dept.

Jeremy Andrews has interviewed Jason Wright and Mark Kettenis about one of the on-going hackathon projects, adding UltraSparc III support to the OpenBSD/sparc64 port. At this point, UltraSparc III machines are self-hosting, but there's some problems concerning the cache. The story goes into quite a bit of detail about the cache on these machines as well as the history of UltraSparc III support within OpenBSD.

(Comments are closed)


Comments
  1. By Nate (65.94.99.88) on

    At least all that work pays off, we get a new Theoism in mg: "Cache aliasing is a problem that would have stopped in 1992 if someone had killed about 5 people who worked at Sun." - TdR

    Comments
    1. By Anonymous Coward (72.154.176.103) on

      What's mg? If i can find more Theoisms there, i'd love to know where to find it.

      Comments
      1. By Anonymous Coward (156.34.219.151) on

        > What's mg? If i can find more Theoisms there, i'd love to know where to find it.

        'mg' is the emacs-type text editor included with OpenBSD. Just for fun, it includes an assortment of ... uh .. sayings. Check it out:

        http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c

        Comments
        1. By Anonymous Coward (128.171.90.200) on

          You can see it in action by running `mg` and typing `M-x theo`

          ( M-x means press the <ESC> key, release it, then press x. )

        2. By Venture37 (217.22.88.123) venture37 # hotmail com on www.geeklan.co.uk

          > > What's mg? If i can find more Theoisms there, i'd love to know where to find it.
          >
          > 'mg' is the emacs-type text editor included with OpenBSD. Just for fun, it includes an assortment of ... uh .. sayings. Check it out:
          >
          > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c


          "in your world, you would have a checklist of 50 fucking workarounds just to make a coffee."

          Brilliant!!
          rofl! :)

      2. By Nate (65.94.99.88) on

        > What's mg? If i can find more Theoisms there, i'd love to know where to find it.

        http://en.wikiquote.org/wiki/Theo_de_Raadt has others.

  2. By gwyllion (134.58.253.130) on

    The article mentions Jason and Mark looked at the FreeBSD implementation. I don't code to support Ultrasparc III in the public FreeBSD CVS. I only found this reference: http://marc.theaimsgroup.com/?l=freebsd-sparc64&m=113388157527375&w=2

    Comments
    1. By Jason Wright (65.202.219.66) jason@openbsd.org on http://www.thought.net/jason

      > The article mentions Jason and Mark looked at the FreeBSD implementation.

      Part of what we were looking at in FreeBSD was the locore <-> C boundary and their implementations of flushing, etc. Those bits are processor specific, but, frankly, a ton more readable than OpenBSD's locore (inherited from NetBSD).

  3. By Anonymous Coward (66.11.66.41) on

    Why? Theo was all upset and crying because Sun didn't want him to support their shit. So why is he going through the effort of supporting it now? Why would anyone choose an ultrasparc III over an amd64 machine for running openbsd? To have a slower machine with no SMP support?

    Comments
    1. By Chas (147.154.235.52) on

      OpenBSD leaves none behind - the ports for VAX and 68k Macs are still supported. Instead of bailing on the Alpha, it was just moved to GCC 3. This has two benefits: a) the user community can re-task old hardware if they wish (like an Aviion), and b) it catches bugs in the source.

      Comments
      1. By Anonymous Coward (70.27.15.123) on

        > OpenBSD leaves none behind - the ports for VAX and 68k Macs are still supported. Instead of bailing on the Alpha, it was just moved to GCC 3. This has two benefits: a) the user community can re-task old hardware if they wish (like an Aviion), and b) it catches bugs in the source.

        This is all very irrelivant. Sparc64 is already supported. They are just adding support for a particularly buggy, broken, worthless chipset. This is like suddenly adding MCA support to i386, not like maintaining support for mac68k.

        Comments
        1. By Chas (147.154.235.51) on

          > This is all very irrelivant. Sparc64 is already supported. They are just adding support for a particularly buggy, broken, worthless chipset. This is like suddenly adding MCA support to i386, not like maintaining support for mac68k.

          I wouldn't agree - see the previous story on the m88k-based Aviion. There are undoubtedly more us3-based systems in the field than working Data General Aviion workstations. If an Aviion can draw the interest of a developer, then the us3 should be irresistable.

          Comments
          1. By Anonymous Coward (66.11.66.41) on

            > > This is all very irrelivant. Sparc64 is already supported. They are just adding support for a particularly buggy, broken, worthless chipset. This is like suddenly adding MCA support to i386, not like maintaining support for mac68k.
            >
            > I wouldn't agree - see the previous story on the m88k-based Aviion. There are undoubtedly more us3-based systems in the field than working Data General Aviion workstations. If an Aviion can draw the interest of a developer, then the us3 should be irresistable.

            Aviion didn't intentionally try to stop openbsd from running on their hardware. Miod had actual docs for it. There are no docs still for the shitty, buggy, broken schizo chipset. And the interest developers did have way back when, was because it would be the fastest arch with proper NX support. AMD64 now has that distinction.

    2. By Anonymous Coward (216.175.250.42) on

      Perhaps because there's a developer interested in it, who has the hardware and the skills to make it happen? As well as the fact that, with each new set of hardware supported, new bugs get flushed out and ganked Dick Cheney style?

      Or, y'know, you can bitch about someone doing something interesting and useful some more.

      Comments
      1. By Anonymous Coward (70.27.15.123) on

        > Perhaps because there's a developer interested in it, who has the hardware and the skills to make it happen? As well as the fact that, with each new set of hardware supported, new bugs get flushed out and ganked Dick Cheney style?
        >
        > Or, y'know, you can bitch about someone doing something interesting and useful some more.

        Nobody is bitching, its a question. And no, bugs are not fixed by adding support for another shitty, broken chipset. Or, y'know, you can just make up stupid nonsense since you don't have an answer to the question.

        Comments
        1. By Anonymous Coward (216.175.250.42) on

          No, a question is along the lines of 'I don't understand why X is being done; my understanding is such; what am I missing.' You were bitching, albeit with a question mark on the end, turning a bitchy statement into a bitchy rhetorical question.

          Christ, from the vitriol, you'd think that the devs were pouring sugar in your gas tank as they coded.

          Comments
          1. By Anonymous Coward (66.11.66.41) on

            > No, a question is along the lines of 'I don't understand why X is being done; my understanding is such; what am I missing.' You were bitching, albeit with a question mark on the end, turning a bitchy statement into a bitchy rhetorical question.
            >
            > Christ, from the vitriol, you'd think that the devs were pouring sugar in your gas tank as they coded.

            What vitriol? Read it again, this time without your bizzare desire to see it as something its not. Its a simple question. Given that the schizo chipset is undocumented, horribly buggy and broken, is produced by a company openbsd dev's hate, and is no longer interesting like it used to be since amd64 is now a much faster platform with real NX support, why bother spending the time and effort to add support for it?

            Comments
            1. By Nate (65.94.99.88) on

              > What vitriol? Read it again, this time without your bizzare desire to see it as something its not. Its a simple question. Given that the schizo chipset is undocumented, horribly buggy and broken, is produced by a company openbsd dev's hate, and is no longer interesting like it used to be since amd64 is now a much faster platform with real NX support, why bother spending the time and effort to add support for it?

              Cause, it's there.

    3. By Anonymous Coward (128.171.90.200) on

      I would rather have an UltraSparcIII than an AMD64 machine any day of the week, if it had full OpenBSD support. Dual processors and fast chips aren't the be-all-and-end-all of computing.

      Comments
      1. By Anonymous Coward (128.171.90.200) on

        ... not that I have anything against fast multi cpu machines

      2. By Anonymous Coward (70.27.15.123) on

        > I would rather have an UltraSparcIII than an AMD64 machine any day of the week, if it had full OpenBSD support. Dual processors and fast chips aren't the be-all-and-end-all of computing.

        But yet you can't name any reasons? Its just "I like crappy machines for no reason"?

        Comments
        1. By Chas (147.154.235.51) on

          > But yet you can't name any reasons? Its just "I like crappy machines for no reason"?

          There is at least one extra security feature available on Ultrasparc. I'm fuzzy on the details, but it has to do with the chip's register windows and the OS saving them off when the depth of function calls becomes too large. This extra security is not available on any i386 variant.

          There was a previous writeup on this on undeadly. You will also find no lack of i386 architecture criticism from the main developers on the mailing lists and in interviews.

          Comments
          1. By Anonymous Coward (216.175.250.42) on

            It's called StackGhost, and is really pretty neat.
            The paper that originated it (and details the OpenBSD implementation) can be found here:
            [ps] [pdf] [html]

        2. By Anonymous Coward (128.171.90.200) on

          > But yet you can't name any reasons? Its just "I like crappy machines for no reason"?

          because I didn't name any doesn't mean I don't have any, just like just because you have one doesn't mean you have to be one.

          Most non-x86 derivatives, have a more sane design all round ( UltraSparcIII cache aliasing not withstanding. )

          Comments
          1. By tedu (69.12.168.114) on

            > Most non-x86 derivatives, have a more sane design all round

            yeah, requiring strict alignment is such a great feature. makes working with byte streams so much more convenient.

            not to mention all the time incoherent caches have saved software developers.

            Comments
            1. By Anonymous Coward (128.171.90.200) on

              > not to mention all the time incoherent caches have saved software developers.

              incoherent caches ?

              are you honestly trying to tell me that x86 are the only platforms that do not suffer from incoherant caches ? I find that hard to believe

          2. By Anonymous Coward (70.27.15.123) on

            > Most non-x86 derivatives, have a more sane design all round ( UltraSparcIII cache aliasing not withstanding. )

            Maybe you should read the cvs commit messages. There is nothing sane about the hardware in question. Its braindead, apparently buggy, and undocumented. AMD64 ain't perfect, but its a hell of a lot better than the ultrasparc 3 crap.

            Comments
            1. By Anonymous Coward (128.171.90.200) on

              If you read the comment you quoted you will see that UltraSparcIII is a bit of an exception as, admittedly, the Sun engineers were probably smoking crack when designing it.

    4. By Jason Wright (65.202.219.66) jason@openbsd.org on http://www.thought.net/jason

      > Why?

      Why not? I like Sun gear. I like Sun processors. I like the challenge of making stuff work... even if it's buggy and poorly documented. It fits into my view of OpenBSD, and if it fits yours, great. If not, oh well.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]