Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

NetBSD Ported to AMD x86-64 (Sledgehammer) 117

Posted by michael from the write-once-run-anywhere dept.
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"
This discussion has been archived. No new comments can be posted.

NetBSD Ported to AMD x86-64 (Sledgehammer) More

NetBSD Ported to AMD x86-64 (Sledgehammer)

Comments Filter:

  • Situation Irony (Score:1)

    by Anonymous Coward
    Somebody once mentioned that this would be a very ironic situation; that is, Transmeta being the first company to offer a hardware implementation of AMD's x86-64 instruction set. :)

  • Re:Erm... (Score:3)

    by Anonymous Coward on Friday June 22, 2001 @11:34AM (#132132)
    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.

  • There are already 256 interrupt lines on the x86. Has been ever since the 8088.

    What are you smoking? Can I have some?

    There is one interrupt line on the 8086. Not surprisingly it is called INTR. When it is asserted the processor finishes its current instruction, releases the bus and asserts INTA.

    When INTA is received the device requesting the interrupt places a 3-bit vector address on the data bus. The processor multiples this by 4 and grabs the vector's address from this calculated offset + the vector base address (usually 0x00000, but can be anywhere in protected mode).

    I'm a little rusty here (haven't done hardware 80x86 development in some years now) but your statement is false. There's only one maskable interrupt line on the x86. There's NMI but it's hardwired to vector 2. So I guess you could argue for a total of TWO interrupt lines. RESET doesn't count. :-)

    Perhaps what you're thinking of is the 256 "software" interrupt vectors? i.e. the 0xcd opcode?

    I was always curious as to why the IBM PC/AT designers decided to cascade they way they did. I would have had the first PIC (Programmable Interrupt Controller) used as a first-stage cascader. I.e. there are no 1st-level interrupts. Then you put the 2nd, 3rd, 4th, etc. PICs on the eight IRQ lines of the 1st PIC. That way you could have gotten to 256 HARDWARE interrupts and not had this "if it comes in on INT9, check the 2nd PIC" problem -- they'd ALL have to be checked.

    Mind you, the task of routing 256 interrupt lines to a 68-pin header would have been tricky. :-)

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

    I believe they (I assume with AMDs help) did this last year. For exactly the reasons you state. I expect they skipped actually supporting more then 4G of physical RAM (or whatever the normal TM chips support) because they would have required real hardware work. I also expect any of the 64 bit instructions are actually kind of slow, but hay probably a lot faster then the pure software emulator (as it is a mostly software emulator with modest hardware assist).

    You might try a google search on comp.arch for more info.

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

    Sure, unless the deciding factor turns out to be how slow the 64 bit code is...

    (not it isn't painfully slow, but it isn't as fast as some of the already shipping RISC machines! It's not called the iTanic for nothing...)

  • I was always curious as to why the IBM PC/AT designers decided to cascade they way they did. I would have had the first PIC (Programmable Interrupt Controller) used as a first-stage cascader. I.e. there are no 1st-level interrupts.

    I would assume they did it to save $27.38 or whatever another PIC and more board traces would have cost. Much like the reason they did the A20 address rollover hack with the keyboard controller.

    FYI this problem is "fixed" on systems that have and use the IO APIC, but they still have to emulate the old two level PIC design so they can run "old" OSes and drivers. (I think the APIC may predate the P-I, but it wasn't integrated on all P-II or even PPro CPUs, and I don't know if Intel clones have them or not...)

    1. Port NetBSD to our chips.CHECK
    2. Actually CREATE one of the chips.
    3. Convince someone to use it in a server.
    Um, considering Frank van der Linden ported this on Wasabi [wasabisystems.com]'s time and money and, when he contacted AMD to mention he was ready to go and make a press release, they were shocked at how quickly the port had happened, I really don't think this was part of AMD's marketing plan. I'd love to think that claiming "NetBSD already runs on it!" meant something, but I really don't think my own favorite OS gets quite enough press to be useful.

    As far as practicality goes, if you don't see why companies will be jumping at 64 bit systems as quickly as they can get them, you obviously haven't been paying much attention to what first DEC and Sun, and now Intel have been doing lately, have you?

    --
  • They're already working on it. [yahoo.com]

    No idea when/if they'll finish the project, tho. Spill it, Linus! ;-)
  • There are already 256 interrupt lines on the x86. Has been ever since the 8088.
  • 64-bit *nix varients have used a 64-bit time_t since time immemorial. The 32->64 bit migration was anticipated.

    FWIW, 64 bits puts the new rollover date well past the probable heat death of the universe.
  • Calm down...he's a good daemon-he converted and even gives bible lessons to Tux
  • It will run them, and run them damn well. They run on the same core (no emulation, seperate core like merced, etc) as the 64-bit, just not using the 64-bit stuff.

    Now, there may be some issues with the 32-bit addressing and extra instructions not being as heavily optimized as they might be on a purely 32-bit processor... But given that this is meant to replace the K7 line across the board, I'd say they will be putting a lot of effort into making the 32-bit smoke. Shouldn't be too hard, since the 64 is just a bit-extension and simplification of the 32 stuff. Time will tell, of course.

  • Put the crack away. The ia32 architecture is currently very problematic for those of us who need to program for it. The basic problem is the 32-bit memory space. Sure, the kernel can address more than that, but no individual process can address that because the pointer is only 32 bits wide. Want to mmap a 2.1GB file? Better get a 64-bit machine. The move to 64 bits gives programmers the ability to write the obvious and natural algorithm, instead of spending their time fretting over their implementation of a sliding mmap window or some other hack.
  • Yes. It can run both 32 bit NetBSD and 32 bit Linux binaries, though of course, given that the simulator is slow, this hasn't been very thorougly tested.
  • Well, I manage to earn enough to meet a pretty large payroll off of what real companies pay us to make the "toy" work on their embedded platforms, and our customers (of which there are a lot) seem pretty happy.

    However, what would I know? I just run a company that exclusively focuses on NetBSD.

    Perry Metzger
    CEO
    Wasabi Systems

  • Why NetBSD? (Score:3)

    by perry ( 7046 ) on Friday June 22, 2001 @01:52PM (#132146)
    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
  • 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?

    So, I'm fishing around in my patented /. Flippant Response Generator, and I'm seeing a 'windows 2005' comment and some obscure '640k' reference.

  • Can we please change that infernal BSD mascot? I like Unix and Unix variants as much as everyone else, but I am very uncomfortable with *BSD's connection to Satanism and demonic figures.

    There is no connection to Satanism. The daemon is not anti-christian or neo-pagan. He's just a mascot. I don't see you complaining about the New Jersey Blue Devils hockey team, or any of the other countless examples in todays society. Some so-called Christians will have you believe that all things that aren't god are evil, or that anything that matches their silly little filters for a devil is wrong. They are not to be trusted as they distort the truth and burn people at the stakes.

    See, old stereo types are easy to pin on people, but utterly without basis in fact. There hasn't been a witch burning in over a hundred years.

  • Obviously you have never seen the Fox special:
    When Penguins Attack

    I'll tell you, it scared me silly. I'm getting goose bumps again just by thinking about it...
  • This is my port for a future processor. Yes, that's right, the NetBSD chip!

    begin source----------
    bsd
    end source------------

    Of course, the chip will only need one instruction, making it a RISC machine.
  • apparently, all they'ed have to do is discontinue support for version 2005 and say "if you don't want to pay cost of the full version, you must purchase Office 2003 in 90 days"
  • did they get rejected for x86? i know they couldn't register 8088, 80286, 80386, or 80486 since those were just numbers, but once letters get added it might be a brand new ballgame... but then it could probably be shown that they haven't defended the x86 trademark....

  • I would love to see Microsoft convince someone to "upgrade" from Office 2005 to Office 2003. Although, I suppose if anyone could they could :)

    Caution: contents may be quarrelsome and meticulous!

  • No, no, no, no............cancer is NOT a virus. It's more like a celluar Pac-Man, running around and eating all the other cells.

    --
  • It would be nice if 32 bit *nix/*BSD distribs be out 64 bit MS product anyhow

    Can anyone translate this to plain old everybody-talk? Babel Fish garbled it up pretty bad.

    --
  • The fact that this impossible OS exits is just causing the earth to collapse on itself.

    Well, we'll just have to lock the door, so it can't get out.

    --
  • MS Rep: Meecrob!

    --
  • Could this be the saviour of *NIX? If time is a long signed int, counting the seconds since UNIX started, by doubling the sizeof(long), don't we automatically change when the time will roll over?

    This is far more effective that rewriting every bit of software out there, and re-defining what time it is. Just change the CPU and compiler, and everything under them gets "fixed" by simply recompiling them.

    Or am I missing the obvious here?
  • hmmm... coming from an m68k/PPC background I find the biggest problem with x86 is the tiny register set, and the wierd instructions that (used to?) only work with operands in certain registers, likesome godforsaken 8-bit processor.
  • US Dept of Retro Warns: 'We May Be Running Out Of Past' [theonion.com]

    According to Williams--best known to most Americans as "Potsie" on the popular, '50s-nostalgia-themed 1970s sitcom Happy Days before being named head of the embattled Department of Retro by President Clinton in 1992--the U.S.'s exponentially decreasing retro gap is in danger of achieving parity with real-time historical events early in the next century, creating what leading retro experts call a "futurified recursion loop," or "retro-present warp," in the world of American pop-cultural kitsch appreciation.

    "Before long," Williams warned, "the National Retro Clock will hit 1992, and we will witness a massive grunge-retro explosion, which will overlap with the late-period, mainstream-pop remnants of the original grunge movement itself. For the first time in history, a phenomenon and nostalgia for that particular phenomenon will actually meet."


  • yeah, and linux's mascot, that fat-ass dumb looking penguin, is so much better.

    bsd's mascot kicks fucking ass.
  • The AMD 64 chip is backwards compatible, it depends on the level of OS support.

  • Re:32-bit (Score:3)

    by Ralph Wiggam ( 22354 ) on Friday June 22, 2001 @11:01AM (#132163) Homepage
    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
  • Some days, I feel like upgrading from Windows 2000 to Windows 3.11. . .
  • I think you're trying to say that moving to x86-64 architecture is going to be a slow process. I've been stormed by 64 bit architecture since the first Sun Sparc V9. Others have had the same thing with the Alpha chip.
  • Not 1901--1970, which is the beginning of the Unix epoch. So the choice is to either buy a new, 64-bit machine that won't think it's 1970 for another gajillion years, or to stock up on bellbottoms and lava lamps.
  • Whoops, my bad.

    I bow to your superior knowledge of negative numbers.

  • of COURSE it runs NetBSD!!

    (sorry, obligitory ;)

    sean


  • ...if you count Sun Solaris and Digital/Compaq DigitalUnix/Tru64, there are popular *nixes that have done native 64-bit hardware and OSes for many years. I remember seeing many early programs which were hard to port to DEC Alphas running Digital Unix because they assumed that 'long int' and pointers were 32 bits instead of 64.

  • To what purpose? I mean, why the hurry? Wait till the hardware is here, I would say.
    I can definitely understand the pragmatic approach you seem to be taking. If your concern lies with the possibility that the eventual hardware could change and efforts could be lost, don't be. NetBSD is well written, and even if the hardware turns out to be something completely different, NetBSD should be able to adapt.

    I run a different UNIX-like operating system, but very much admire the efforts of the NetBSD team. Congratulations to all involved. Such commitment on behalf of both parties shows the true beauty of the community.
  • Interesting ... you be sure to tell Yahoo and Walnut Creek that their business depends on the weakest link.

    I'm sure you're intelligent enough to know that a single test does not give anything more than a rating for those conditions running that software.

    Tests like that are a good thing - I'm pretty sure any of the issues raised have made their way to the relevant developers and I'd expect them to be addressed in the next release :)
  • My guess would be LP64, the same as the existing alpha and sparc64 ports.
    Longs and pointers 64 bits, int 32, short 16, long long probably 128.
  • you've got to be kidding... it has no connection with satan... it's a cute little devil... c'mon. Tux looks more dangerous than the BSD devil.

    --
  • Personally, I'm waiting for the Fox special "When Grass Attacks"... now that will be some scary shit.

    --
  • if by SGI you mean HP then I have a link for you
    here [hp.com]

    Jon
  • What does that \alpha directory on my Windows NT disc mean? I forget.
  • Witches are to be burned, not honored, and I don't think that most God-fearing Christians out there want their children corrupted by such "gateway" groups.

    Haven't turned on your TV in a while, have you?

  • The suffering of actual penguins (the trade-show caged bird) and the defacement of public property (IBM) shows the *REAL* problems with 'the linux mascot'.

    The best you can troll with is daemon == demon, and claim that AMD shouldn't associate with such. Guess what? x86-64.org used to ONLY mention GNU/Linux and after being reminded that FreeBSD/NetBSD Exists, did they change the focus of the page to be INCLUSIVE rather than EXCLUSIVE.

    It is too bad you want to exclusive rather than inclusive.

  • are businesses going to use this? (Score:4)

    by B1ood ( 89212 ) on Friday June 22, 2001 @10:57AM (#132179) Homepage
    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

  • Just because something isn't released yet doesn't mean that is automatically vapourware. This is turning into a f@cking witch-hunt. Please keep your accusations to yourself till it's actually true. Things take time to be developed; also, one of the natures of geek-oriented sites is to report upcoming things. Not being able to buy something in stores doesn't mean a thing. Please try to increase your economic attention span a little more.
  • Its not that i'm humour impared, its that was a pathetic attempt at a joke. I have a funny bone, but it's more sophisticated than the contents of that post. If you expect me to laugh, please be funny.
  • If intel couldn't trademark x86, (that's why they called the 586 "pentium") then why can AMD trademark x86-64?
  • so now you can trademark a hyphen?
  • User: Wasabi?

    Programer: Waaasaaabi!

    User: Wasabi?

    Programer: Waaaaasaaaaabi!

    User: Wasabi?

    BSD Guys: Waaaaasaaaaabi!

    User: Waasaabi!

    Everybody: Waaasaaabi!

    Wasabi!

  • By porting NetBSD to an machine that exists only in the future you are messing up the delicate time-space continuum!

    This is actually becoming a standard practice ... a few mos ago I saw an add for the Sony Playstation 9 :)

  • Bill Gates stole his BASIC code from a dumpster. Most of the world wishes he had left it there. Computers of all types that use his BASIC code STILL don't work.
  • Now I can load more than 2GB of MP3s and porn into memory on an X86 platform... now I don't have to switch to an alpha!

    ---

  • Yes. It'll run 32-bit applications, so anything compiled for NetBSD/x86 will run just fine as long as you have all of the shared libraries and COMPAT_NETBSD32 in your kernel.
  • Pretty soon we'll have the situation where you can get a movie on video before they're even through making it!

    "You're looking at now now. Everything that's happening now, is happening now."

    "What happened to then?"

    "You missed it."

    "When?!"

    "Just now."

    "When will then be now?"

    "Soon"

  • In other news...

    NetBSD guru's have ported their OS to Microsoft's .NET platform.
    Specualtion abounds as to whther to call it ".NetBSD" or "NetBSD-NET", though sources inside Microsoft we reported to be screaming "Damn this Unix virus - it's everwhere!"

  • Actually, the Altair was already fully functional. Bill just didn't have access to one...They wrote the code on a government funded computer.

    Paul Alan wrote the emulator for the Altair while Bill Gates wrote BASIC. Paul Alan was the one to actually deliver the product to New Mexico, and had to write the boot loader on the plane trip there! It did run first time amazingly.

    Matt Newell
  • Look what you did!!! You're so cool...

  • Transmeta? (Score:4)

    by Animats ( 122034 ) on Friday June 22, 2001 @11:24AM (#132193) Homepage
    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.

  • with a beowulf cluster of these for the sole purpose of:

    grep "Natalie Portman" the_entire_internet
  • NetBSD already runs on several other 64bit
    architectures (alpha, sparc64, dunno about MIPS
    and PPC), so this is not the first stab at
    getting NetBSD 64bit clean. :)

    - Hubert

  • screenshot, and a dmesg(8) output (Score:3)

    by hubertf ( 124995 ) on Friday June 22, 2001 @12:04PM (#132196) Homepage Journal
    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 (Score:4)

    by hubertf ( 124995 ) on Friday June 22, 2001 @02:04PM (#132197) Homepage Journal
    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

  • this is great news for bsd.

    SGI had some news the other day about their new itanimum box breaking some records, too -- with Linux, no less.


    Treatment, not tyranny. End the drug war and free our American POWs.
  • Just imagine if the headline read "Linux ported to next gen cpu..." every singe post would say something like yay linux. But BSD is ported and people ask why. Porting the OS means you can learn a lot about the new architecture.

  • So did Bill Gates when he wrote a version of BASIC for the Altair 8800 when it wasn't being sold yet... it ran in a "simulater" of the Altair on a minicomputer (that belonged to a university).
  • I mean, why the hurry? Wait till the hardware is here, I would say. 64-bit architecture is nothing that's going storm us.

    Well, yeah, I guess there's plenty of time until 2038 when 32-bit time() will suddenly start telling us it's 1901. ;-P

  • Sheer curiosity of meeself: how wide are "short", "int", "long" and "long long" in this port? I would guess that decision was made by GCC actually. Right?
  • Whoa, waitasec. Most systems (all?) consider the time_t type (time()'s return) to be signed. They need to, in order to be able to interpret dates prior to 1970 (e.g. births). Try to compile and run the following in your *nix box:

    time_t when;
    when = 0x7FFFFFFF;
    printf("%s\n", ctime(&when));
    when = 0x80000000;
    printf("%s\n", ctime(&when));

    Also, if time_t was unsigned, the wraparound would occur at 4 billion secons instead of 2 -- well into the XXII century.

  • Contender to replace all your base are...?
  • if most of the *BSDs and *nix distribs where able to support 64 bit sooner rather than later.

    On the other hand, It would be nice if 32 bit *nix/*BSD distribs be out 64 bit MS product anyhow.

    Not that this would be *that* hard to do, for those reasonably expert.

    Check out the Vinny the Vampire [eplugz.com] comic strip

  • OK, lemme get this straight! There is a NetBSD port to a chip that only exists in a SIMULATOR!? OK, this could be bad, for these reasons:

    1) It's a simulator. We can't really assume 100% correspondance to the actual pysical archatecutre. (ie, "bug-for-bug", etc.) Do we know if there are any -flaws- in the software?

    2) The archatecture in a simmulator NOW may not be the end product. What if some things happen to change? After all we can't say that it'll use DDR or have the same specs in the end.

    OTOH it's good for these reasons:

    1) It's the first there, and gives the BSD crowd a jump on making clean 64-bit code for when the CPU is released.

    2) Now they may get others to follow suit...

    So that's my $0.02 USD.

  • I think that calling Catholicism a "cult" is pretty bigoted...
    Just in case you doubt my credentials on this, I live in Glasgow, where two or three times a month we seem to get all our traffic interrupted by an "orange Walk", where Protestants symbolise their capture of the (at the time) predominantly Catholic Ireland.
    The sad thing is, most of them have never and will never understand the true meaning of what they do, preferring to rant about "all those bloody Tims" in pubs.
    Oh, and to clear up any possible confusion, I *am* in fact a Christian. No I don't have a "Jesus Saves" sticker on by rear windscreen. Yes, I do use BSD.
  • Would you like a job as a professor? I like your theory.
  • what about Itanium?
  • Just great. Now Microsoft can just 'innovate' some parts of NetBSD and claim to have invented a 64 bit OS.


    Viv
    -----------
  • hmmm... ok troll I'll bite. First, I have a very hard time believing that you really and truly think this way. The first thought in my head when I read this was "This guy has to be kidding right?" So now, let's go through some of your complaints.

    "I am very uncomfortable with *BSD's connection to Satanism and demonic figures."

    Exactly how is BSD connected with Satanism? I don't know any Satanists who use *BSD nor are any of the original developers satanists. The demonic figure of which you speak is a daemon, not a demon. The symbol is meant to be satirical. Daemons are processes that run in the background and keep the system running clean or offer services. Examples would be syslogd, inetd, httpd, etc.. The pitchfork he's holding represents the fork() function which is how processes are executed in the first place.

    "It is morally wrong to associate a piece of software with such an image, and I sure as hell do not want my children coming into contact with it."

    hmmm... this image? Have you ever seen a demon to know exactly what one looks like? Can you even prove that such a creature even exists? Oh I forgot, your religious and cultural background lead you to believe such nonesense. I guess unicorns, dragons, trolls, gnomes, elfs, leprechauns, vampires, zombies, and boogie monsters exist too. After all, by this logic they should exists since they are part of somebody's popular culture. I guess the Taliban was justified in destroying the Buddhist statues in the Bamiyan valley of Afghanistan because graven images are unislamic.

    "Witches are to be burned, not honored, and I don't think that most God-fearing Christians out there want their children corrupted by such "gateway" groups."

    Yes, typical Christian bigot attitude. I bet you read Arthur Millers "The Crucible" with pride don't you. The Spanish Inquisition which killed more non-Christians and Jews than Hitler probably pleases you. After all, these other people don't deserve to exist do they. The early white Christian settlers killed the native Indian populations because they were heathens and unchristian. Christianity has been responsible for more cruelty and barbaric acts than any other force in history. But, I'm sure this is a source of pride for you. Witches being burned, the Spanish Inquisition, The Crusades, The Holocaust, The destruction of Native American culture, and the enslavement of millions of African Americans are all examples of how Christian bible verses were used to justify the horrible things.

    Finally, your statement "I don't think that most God-fearing Christians out there want their children corrupted by such "gateway" groups".

    Well, I'm sure most God-fearing Christians don't share your extremist viewpoints. I consider your group, whatever that group is, a "gateway" group. I'll be sure to not allow my children to grow up being close-minded bigots such as yourself and I'll make sure they know all the cruel barbaric acts that your group has committed in the name of God.
  • 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?

    Nice troll. I mean, I hope, anyway. You do know that, aside from the mundane DBMS application, there are all kinds of simulation software, rendering, etc that can use every GB of RAM you can throw at them.

    too bad x86 will probably always be faster.

    ROTFBMDOOMN

    Yeah, right. We'll never need a different architecture. x86 will always be there.

  • It breaks structures with time_t in them.
    They're prolonged.

    And as simply you can recompile any programme
    with a modified time_t.

    This still doesn't solve binary programmes.

    --
  • It IS NO "BSD Devil", neither is there a
    "BSD Demon".

    There exists a (I know of four, but I know that
    at least five must exist) "BSD Daemon" which are
    different.
    Three red and one blue... and several more?

    [OT]The OpenBSD daemon parodies deraadt?

    From the pure pictures I like the FreeBSE daemon
    most, but the OS's not to great...

    --
  • Use lynx and/or light-html option.

    --
  • What me? I'm only 13! And I have to go to work in a second... Though I would make a good conspiracy theorist...

    --Volrath50

  • Nooooooo!!!! (Score:5)

    by V50 ( 248015 ) on Friday June 22, 2001 @11:26AM (#132222) Journal
    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

  • Always funny, when people refer to themselves in the third person:

    fvdl writes: "[...] The porting was done by Frank van der Linden of Wasabi Systems [...]"

    Well, hey, Frank you deserve the publicity!

    -Kraft
  • Well considering the simulator CAME from AMD, I'd say they're off to a heck of a start - of course there will be some bugs when teh actual chip comes out, but they are WAY ahead of the pack right now - most excellent.
  • So, um, well the x86-64.org website talks about an experimental GCC being available in CVS. My question out of curiosity is did they use that compiler or is there a more advanced GCC that is um well, more complete. I guess it boils down to how experiemntal is this version?

    It'll be interesting to see how fast x86-64 GCC takes to be stable enough for production use.

    But this is REALLY cool stuff - don't take the above as criticism, its not - just curious.

  • fdvl replies...

    Answers right from the author on /. no less! Great concept :) :) Thanks for the info and great work!

    As a true green AMD fanatic I can't wait to get my hands on one of these processors - just gotta find the right job :) :)

  • Re:Good for AMD (Score:3)

    by baptiste ( 256004 ) <mike.baptiste@us> on Friday June 22, 2001 @11:07AM (#132227) Homepage Journal
    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... (Score:3)

    by fvdl ( 263763 ) on Friday June 22, 2001 @11:37AM (#132228)
    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 (Score:3)

    by fvdl ( 263763 ) on Friday June 22, 2001 @12:11PM (#132229)
    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 ... (Score:3)

    by fvdl ( 263763 ) on Friday June 22, 2001 @12:42PM (#132230)
    Actually I replaced Linux with NetBSD on the machine that AMD sent me, and ran the simulator under emulation ;-) Sorry..

  • Re:Alright! (Score:3)

    by __aaahtg7394 ( 307602 ) on Friday June 22, 2001 @10:57AM (#132231)
    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.
  • It's quite common for system software bring-up to happen on simulators before the chips come out. In a lot of ways, its a much more desirable approach than *having* to deal with buggy, early-rev. hardware.
  • Why? Because it's there. People are going to want to run software for their shiny new expensive processors in 64-bit mode, and since other companies [microsoft.com] will not provide the service for a while, you've got to run something. Besides, there were Linux distros that ran on IA-64 processors a full year before their release. It gives people a chance to clean up their code and make it 64-bit clean (there are some differences) before the release of the processor.
  • you know...the Society for the Prevention of Incessantly Repeating Annoying Crap.

    --
  • Congratulations to the BSD team for this remarkable achievement, following in the footsteps of some of software engineering's legends. In 1975, Bill Gates wrote a version of BASIC for the Altair 8800 [slashdot.org] that was totally debugged before the Altair was even functional. The BSD team is now following in the footsteps of the computer industry's greatest programmers, by writing code for an (as-yet) nonexistent platform.

    Given that Gates was operating without modern compilers and debuggers, his achievment is indisputably more impressive, but kudos to the BSD team for being almost as good as Bill Gates.

    Way to go guys!

Slashdot Top Deals

"Tell the truth and run." -- Yugoslav proverb

Close