NetBSD Ported to AMD x86-64 (Sledgehammer)

fvdl writes: "Last week, a port of NetBSD to the x86-64 (tm) architecture was committed to the NetBSD CVS repository. The x86-64 is AMD's upcoming 64bit line of CPUs. For now, it is only known to work on the Virtutech simulator, since no x86-64 hardware is available yet. In this environment, it runs multi-user. NetBSD/x86_64 is the 44th architecture that NetBSD runs on (12 different families of CPUs). The porting was done by Frank van der Linden of Wasabi Systems, with kind support from AMD, who provided the simulator and fast machines on which ro run it. The Wasabi press release is here. For more information on the x86-64, see of course AMD's website and x86-64.org"

Re:Erm...

It is standard practice to port software to a simulator while the hardware is being developed. It allows the hardware/software development process to be parallelized. If there are nits and changes in the released product, then you fix them. And it takes much less time that doing the whole port from scratch.

Also, different versions of CPUs differ too -- so there is often a little work to be done when a new CPU is actually produced.

But these changes are minor compared to getting the whole operating system to run, and hence don't take very long.

And as a short note: NetBSD is already 64 bit clean and has been for many years. (check out the alpha port [netbsd.org], which has been available since 1995.) At that time, the code-base was made 64 bit clean.

Why NetBSD?

Replying to trolls is always a deadly business, but what the hell. I'm bored.

I don't know how many NetBSD users there are, but somehow, I suspect you don't either. NetBSD is in use every day in far more places than you think. Your DSL router or a cache box at your ISP may very well run NetBSD without your even knowing it. Ditto for large numbers of users of NCs -- NC/OS is NetBSD 1.3. There are users of hundreds of thousands of things like airline reservation terminals and such that use NetBSD every day and don't even know it. NetBSD is a very portable, very clean OS with a BSD license attached, so it gets put into LOTS of embedded hardware.

There are also a pretty large number of people who use NetBSD day to day and are very well aware of the fact. Just look at the NetBSD mailing lists if you don't believe me.

Why do people like NetBSD? Well, that would be a very long discussion. Suffice it to say, though, we've done a lot of careful architectural work on NetBSD over the years and it has paid off handsomely. There is a reason we port to new hardware quickly for instance, and it isn't that we have more fanatics than the Linux crowd. We've also got a BSD license on the code, and without trying to start a fight some people prefer the BSD license to the GPL. There are also other people who like having their whole OS build out of a single coherent source tree -- Linux code integration is a big pain which is why most people don't build full Linux systems from sources on their own.

Why is it news that there's now an OS that's gone multiuser on the x86-64? Well, that's probably more to do with the x86-64 being a neat new design than to do with us. We do a lot of ports and most of them don't get slashdotted. However, I'd say that given the fight brewing between Intel and AMD, this wasn't the silliest story for slashdot to cover.

Why do lots of people seem to think there are no BSD users in the world? I don't think anyone but a troll would claim that with a straight face...

Perry

Re:32-bit

My understanding is that AMD's 64bit CPUs will run old code beautifully. This may be the deciding factor against Intel's Itanium, which by all the accounts I've seen, runs 32 bit code terribly slow.

-B

are businesses going to use this?

I can imagine the engineers and marketing dept at AMD looking at a checklist:

1. Port NetBSD to our chips.CHECK
2. Actually CREATE one of the chips.
3. Convince someone to use it in a server.

They're still working on the last two...

B1ood

Transmeta?

Transmeta, which has a soft architecture, ought to be able to convert their code morpher to process the AMD 64-bit instruction set, which is basically x86 with longer words. This would be useful mostly as a test environment until AMD gets the real machine out the door.

Since the Transmeta "code morpher" is closed source, and the actual machine interface is propretary, only Transmeta can do this port.

screenshot, and a dmesg(8) output

Here's a screenshot [netbsd.org]
and a dmesg output [netbsd.org], right off the NetBSD [netbsd.org] site.

Also, check out the NetBSD/x86_64 port page [netbsd.org]!

- Hubert

"just" a port - portability

I'd like to add a note on the "it's just another port" comment.

For NetBSD to be portable to all the various platforms, it has to abstract the properties of these platforms, and provide interfaces between machine dependent and machine independent code, so that not every port to a new platform results in copying the whole code, and modifying it until it works on the platform, as that would give you a lot of code redundancy.

Instead, NetBSD does a (IMHO) pretty good job to avoid code redundancy, and with abstract interfaces for bus-access, DMA etc., it's amazing to see lots of code written once, and running on platforms of either endianness, CPU, bus structure, etc.

NetBSD currently runs on 44 different hardware platforms, and 12 different CPUs. If you think adding a new one is "just" a port, you miss something.

If you feel bored, you can read a bit more about what makes an operating system here [feyrer.de].

- Hubert

Nooooooo!!!!

By porting NetBSD to an machine that exists only in the future you are messing up the delicate time-space continuum! The fact that this impossible OS exits is just causing the earth to collapse on itself.

If this goes on we are going to have the Pentium 9 avalible before the Pentium 5, Office 2005 before Office 2003. And when that happens any Pentium 9 computer will collapse on itself, being so fast that the universe will not have sped up to account for Moore's law! Don't you ever wonder why Windows 3.11 on a 386 with 4MB of RAM was as fast as Windows XP on an Athlon 4 with 512MB of RAM???

By running NetBSD on an x86-64 simulator you are creating a gap in time. The more people use the x86-64 simulator the bigger the gap will be. Eventually the gap will become so big that stuff will start coming through. First software such as WindowsZX/2023. Unfoutonetly WindowsZX will require a 2.4 THz Pentium 13(801986) with 512GB of RAM.

So of course Intel or AMD will build a 1986/P13 simulator to run WindowsZX. The motherboard of the computer will collapse causing a HUGE reverse black hole to spit out a a REAL Pentium 13. As well as 512GB or RAM.

If you thought running an operating system from 2023 was bad you can't imagine what a Pentium 13 would do! When they turn the Pentium 13 box on it would completly deplete California's power supply. That is until the entire California from 2099 gets sucked to where California is now.

Now that California has technology from 2099 such as WindowsBLT and the Pentium 86, the Universe hasn't ajusted to Moore's law and part of the world is running 3GGLHz (Googol Hertz) machines. California is now running 300 times slower than the rest of the world, and is causing random stuff from the future to appear. Which sets those parts of the world out of sync.

By now no part of the world is in sync and parts of the future are appearing everywhere. As you probably have figured out, this will eventualy spread to the rest of the universe. Destroying it.

Motto of this story: By running NetBSD on an x86-64 simulator, you have already doomed the universe.

Have a nice day!

--Volrath50

Re:Good for AMD

Absolutely - getting the simulator out when they did and embracing the open source community was a brilliant move. I think efforts like this will help AMD later on in a big way when they try to crack the server market - though I expect the 760MP is gonna get those cracks started.

Must resist .. Imagine a Beow .. no .. no .. clust .. not gonna ... say ....it!

Whew - made it!

Re:Pardon the ignorance...

The toolchain is getting to be more and more stable thanks to the good work of the guys at SuSe. There are some problems left, but I'm not sure if they are due to the "-current" nature of the binutils and gcc that they're based on.

Re:Us, Frank .... or ..... Frank on Frank

Worse.. I am now replying to a post about me in reply to an blurb I wrote about something I did. I'm lost in an egocentric spiral.. Seriously, I wrote it originally to be posted by someone else. I wanted to avoid the "look what I have done, I am so cool" syndrome.

Re:What they didn't tell you ...

Actually I replaced Linux with NetBSD on the machine that AMD sent me, and ran the simulator under emulation ;-) Sorry..

Re:Alright!

aww... all you have to do is fork some children processes off and manage some domain sockets or pipes, and voila, you've got more than 2GB addressable on ia32! speed? who needs speed with datasets that large? it's not like you're going to be doing anything more than playing large mpegs, right? i mean, why else would you need more memory?

of course, having more than 2GB of memory on x86 can only be bad news... software is already too bloated as it is.

/me pants anxiously at the prospect of buying a Real Computer someday... too bad x86 will probably always be faster.