AMD and SuSE Porting Linux to Sledgehammer

-|Oblom|- writes "AMD has partnered with SUSE to port Linux to its upcoming 64-bit Sledgehammer chip. The story is on CNET and the projects site is here www.x86-64.org Well... I have been waiting for a while for this announcment. Hopefully by the end of next year I'll be running dual-core 1.5Ghz(at least) Sledgehammer with Linux on it"

Comments

Re:Once again, the AMD loving ruskies rejoice.

[sterwill]

0%? Surely you're rounding your numbers down a bit, because I can name quite a few web servers running on AMD Athlon processors. www.lloop.com is just one example. Linux runs just fine on the Athlon; the only problems I've witnessed in Athlon systems had to do with substandard mainboard chipsets.

--

Re:NONONONONONONO

[snort]

well, thats why i said 6 drives :)

Re:This is Big

[smolix]

Don't get too excited about Linux supremacy. MS has still the lion's share of the market and most customers wouldn't buy a PC if they couldn't run M$ products on it.

Just have a look at what happened to Alpha. Since most programs didn't run natively on it (only via an x86 emulator) nobody bought the boxes. They're great for big numerical simulations, if you're willing to code everything on your own, though.

Re:Good Work SUSE

[gnugnugnu]

AFIAK Suse is (was about a year ago) one of the more profitable Linux companies, whereas RedHat has gone for expansion and market share.

Re:Thanks for the info...

[EisPick]

> A DSL provider who actually delivers

Might as well ask for a car that gets 5000 mpg.

Re:Why Sledgehammer?

[SEWilco]

"The following kernel update takes begins five revisions before the filesystem rewrite branch..."

-- And Beowulf with sledgehammers would be extremely messy. Bring a mop to the battlefield.

Re:Shouldn't be too long

[Misch]

If the app is distributed as source and the toolchain is 64 bit the app will be promoted automagically

Like my CS professor said... "and everybody thought having C++ be backwards compatiable with C is a great thing! Now you can get all the benefits of Object Oriented programming without having to rewrite any of your C code!"

It should be noted that he said this sarcastically.

Re:Why Sledgehammer?

[Covener]

Holy shit that show was tight.

Didn't it get cancelled in the middle of a cliffhanger?

W/ an atom bomb about to go off?

Re:This is great.

[ackthpt]

NT has been running on Alphas in a sort of interpreted mode, um, iFx86, or somesuch and is most definately NOT native. Witness that Win2k is available only for x86 platforms.

You're referring to FX!32. Per my understanding from discussions with DEC personnel, DEC granted M$ license to VMS internals, which are the foundation of NT. For M$'s part they agreed to develop NT for the Alpha platform and to support it. How else are you going to explain the very pragmatic goons at M$ providing an O/S for such a small population of processors?

I also don't believe it would be possible to run an entire O/S, libraries, etc. through FX!32 as the O/S is tied to the architecture. Although such blantant stupidity didn't stop M$ from passing off faulty basic ROM's back in the late 70's.

Vote Naked 2000

[OT]Speaking of IDEs

[ethereal]

• X with xterms (courtesy of XFree86): $0
• cscope (courtesy of SCO): $0
• vim (courtesy of Sven Guckes): $0

The best IDE that money can't buy: priceless

This post brought to you by the letters v and i.

Re:[OT]Speaking of IDEs

[ethereal]

My fault - Sven's name is all over the web site, and Bram's is only in one place that I saw. I guess I could have fired vim up and checked, but I'm at work where we only have the HP-UX excuse for vi.

Boy, is my face red...

More bits != More speed

[Chris Burke]

The reason to switch to 64 bits is not performance. Extra bits don't give you more speed. It only increases what you can do (which might possibly give more speed, but generally wider datapaths are slower, not faster).

The most important reason to want 64 bits is for server applications which want an address space larger than 4GB. 64 bits of virtual address space is the main attraction of these chips, and only for servers. Which is why Sledgehammer is being pushed as a server-only proc to compete with Merced.

You might get other benefits, like 64 bit integer ops being faster (but not necessarily... adequate bypass networks in a 32-bit proc might make this a wash). Which is only a benefit if your app uses lots of 64 bit integer ops.

There are also penalties -- for example, the page table hierarchy has 4 levels, which means more memory accesses on a TLB miss.

16->32 was different, because it also gave you all kinds of benefits like protected mode, virtual memory, and other stuff i'm too lazy to remember.
And 16 bits was never really enough.

Anyway, the point is that there is no real reason to worry about current apps moving to 64 bits when Sledge hits. Those server apps that will benefit will switch, and those that won't have no reason to (which is the true beauty of this processor).

Re:More bits != More speed

[um... Lucas]

Right. I wasn't meaning to imply that a 64 bit CPU would be implicitly faster than a 32 bit one. Just that a 64 bit proc can access a whole lot more memory than a 32 bit one, which therefore implies huge performance leaps for things like databases and such. Of course, all of the mainstream databases already run on 64 bit platforms, so Sledgehamemr in effect only gives vendors and customers another CPU choice... (Sparc, MIPS, Power, Alpha, Itanium, PA-RISC, the list goes on and on...)

Re:More bits != More speed

[Chris Burke]

IA32 already supports 80-bit FP, and has 80-bit FP registers. nobody uses that, but the upshot is double precision is already there and cooking. doubleint conversions will probably be easier with 64bit int registers, but those really aren't the critical path.

Though getting away from the stack-based FP architecture _will_ be an improvement. ^_^

Re:More bits != More speed

[Chris Burke]

Sigh.

Look, I'm talking about 64 bit wide _instruction data paths_ inside the core of the chip, not system busses. It's the thing that becomes 64 bits in Sledgehammer, which as you may recall was the topic of discussion. A datapath includes things such as ALU's, bypass networks, mult's, etc. These structures get slower as you make them wider.

In a system bus, every byte counts. You need to send every byte from the buffer to the video card, so moving twice as many bytes in a cycle is a good thing. And you can widen a system bus without widening your core (Wmt has 128 bit wide bus, but is only a 32 bit processor).

But in a datapath, you don't often use the upper bits. How often do you think the upper 32 bits of a 64 bit ALU (in, say, Ultra Sparc) get used? Not very often, it turns out. So you don't gain any more 'bandwidth' from your 64-bit ALU.

Even 64-bit loads and stores don't buy you anything, thanks to write-back cache policies. For uncacheable accesses, 64 vs. 32 bit mem accesses will still be a wash because the bottleneck will be the FSB, not the ld/st unit of the core.

But I understand you're misunderstanding, since you can't learn the above by casual perusal of Tom's Hardware.

Re:More bits != More speed

[Zurk]

its not memory you dolt. tried to create a file greater than 2 GB on a 32 bit platform ? you cant. tried using a database ? see those huge files ? yup. thats right. you need 64 bits.

Re:More bits != More speed

[andr0meda]

Hmm.. I'm not totally convinced that you can say they will be slower. Essentially what happens is that most logic is doubled up in parallel to what is allready there. However, this only works for 0 or 1 operand instructions. More operands imply dependencies and then things get tricky. But processors with 64bit instructions will take advantage of the longer instruction words to cram in even more arguments, and thus be able to do more complex tasks with them. In that regard, the instruction procesing might be slower, but the task completed will essentially also require more instructions on a 32bit processor, because the 64bit chip now has dedicated hardware which typically will take less cycles to complete.

But you allready hinted for my next question: How long will it take before hardware manufacturers switch over to 64bit as well?

Cheers..

Re:More bits != More speed

[Chris Burke]

Okay, as a basic rule, wider=slower in datapaths. A 64-bit alu will take longer to finish than 32. You can pipeline it, or have a slower clock, but either way it takes longer.

A clever way to mitigate this is to obsevere that most of the time the upper bits of the add aren't needed (most adds are of small numbers). So you can speculate on that, and try to save yourself time. So your typical alu time will be lower, but you need a mechanism to detect when you were wrong and correct that.

Now, if you _need_ 64-bit adds, then that's different. Though add is a bad example then, because 32-bit procs can handle 64-bit adds, and thanks to bypass networks it operates as quickly as a pipelined 64-bit alu in a 64-bit proc. Multiply is more compelling, because storing all of the result becomes tricky. So when you need 64 bits, 64 bit procs are better.

More complicated instructions (as in more arguments) don't really help. You're going to implement the extra functionality as extra steps that may as well be a separate instruction. There are special cases (the MAC inst on DSP's which has specialized hardware) but I'm talking generally here.

You'll notice that 64-bit RISC architectures don't give you any more operands than 32. That's because more arguments means more ports on your register file, more complicated dependency analysis and schedulers, and no benefit except maybe saving an instruction or two. But if you used a 32-bit core, all you're instructions would be half the size, saving you much more space.

In the CISC world... well, x86 already has very complicated instructions with lots of arguments, but all that happens is they get split up into many smaller RISC-like instructions inside the core.

Sledgehammer doesn't actually have 64-bit instructions... it's variable width, being x86-based, and implements all the 64-bit goodies using a special prefix. And, taking the cue from the RISC world (which x86 has queitly and surreptitiously joined), all the new insts are fairly simple. The uOps it converts the x86 insts into will be whatever optimal size they need, but probably less than 64 bits.

Re:More bits != More speed

[Inoshiro]

"Extra bits don't give you more speed. It only increases what you can do (which might possibly give more speed, but generally wider datapaths are slower, not faster)."

No true at all. Wider data paths are faster because they can move more data per tick. Compare: NARROW FAST SCSI -> 10Mbps, WIDE FAST SCSI -> 20mbps.

And if you increase the number of clock ticks by 2, you get ULTRA WIDE SCSI -> 40Mbps!

It's a choice of pumping more bits per tick, or having more ticks with which to pump bits. An AMD Athlon may have 1 billion ticks with which to pump bits, but the bus it's connected to is incredibly slow compared to it. Widen the path, and you get double the performance with today's technology.

I think your flaw is in thinking based on what you know. As most first year chem students, and they'll say that wet air is heavier than dry air because a wet towel is heavier than a dry one. This is flawed logic.
---

Re:AMD and Intel

[randombit]

Since AMD and Intel are each making their own instruction set for 64bit, does that mean that software will have to be written for both?? Or is there going to be some compatability layer that allows AMD chips to run Intel code and vice versa??

I doubt it. Both will support IA32 code, so there is significant overlap. But if you want to run IA64 code on a Sledgehammer, or vice versa, you'll need emulation of some sort (probably in software, which if the Sledehammer is as fast as I'm betting it is, will not be a problem).

I couldn't help it..

[Mtgman]

I saw the title and even though I knew the Sledgehammer was a new CPU, I just thought "How sweet would it be to LART some spammer with a Linux-based sledgehammer."

SuSe on a Sledgehammer, For those times when you want to do more than just ping someone.

Steven

Re:SuSE

[wilkinsm]

SuSE rules - this American ain't going back to dorkyhat.

OT: I'm on 6.3 - any reason to go 6.4?

Re:SuSE = 6.4

[bstadil]

OT: I'm on 6.3 - any reason to go 6.4? Yes XFree86 4.0 support. 7.0 is out and will be on the ftp servers here shortly.

TLB misses.

[Christopher Thomas]

There are also penalties -- for example, the page table hierarchy has 4 levels, which means more memory accesses on a TLB miss.

While this is true, its impact can be reduced by having a multi-level TLB (cache the physical addresses for lower level pages of the page table as well as the physical addresses for the destination page). Several architectures already do this.

This would allow me to get a new page's physical address with a single lookup, as long as it's within the same block of pages as another page I've already accessed.

Re:Why Sledgehammer?

[human bean]

Aside from being a really cool trade-mark, the answer may be tradition.

Designing a circuit with way, way more of a particular resource (speed, memory, etc.) than actually required is referred to as "using the sledgehammer" or "sledgehammer design".

One of the first print examples I can think of was a chapter in Don Lancaster's "TTL Video Cookbook" entitled "Use a sledgehammer", where the suggested solution to a video program that didn't work quickly enough was to simply add another processor and memory

Re:SuSE

[rbrito]

Indeed. I rarely post here to Slashdot, but I think that people should give more credit where credit is Due.

I'm an avid Debian GNU/Linux user (and I do intend to be a Debian Developer if I can in the near future), but I can't help but recognize all the good things that SuSE Linux has been paying kernel hackers for.

They seem to be incredibly commited to the Free Software movement, yet they get very little credit.

Indeed, people wouldn't have support for many high-end devices and methods if it were not for the support that SuSE is putting into Linux. I won't mention all them, but there are some of the things that I remember:

• Funding for development of drivers for X;
  
• Funding for development of ReiserFS;
  
• Funding for the Alsa Project;
  
• Funding for IDE/ATA Drivers.
  

Many people need those things (which shows the relevance of the support) and I'm sure that there are many other projects with which SuSE may be involved. Congratulations!

Roger...

Re:Shouldn't be too long

[pf kro]

Right, the kernel needs to support the architecture to get out of AMD's "legacy mode".
In order to compile the kernel for x86-64, gcc has to support it.
If gcc supports it, the distributions will be able to recompile all of their packages to be 64-bit Linux.

Granted, you'll receive performance benefits once the kernel is recompiled (i.e. the processor will be in the other mode of operation) and you could still run the old 32-bit binaries, but once the entire OS is recompiled, you'll get all of the benefits of 64-bits out of the processor.

Re:Sledgehammer as a high end server platform?

[spiro_killglance]

Sledgehammmer will start off high end, but because the core is only a little larger than the athlon core, I expect the sledgehammer core to be an all new AMD chips within a year of release. Products in 2002 might look something like this (This is a guess by the way) Sledgehammer, Duel core 2GHz-2.5GHz 2M Cache Athlon Pro 64, Single core 2GHz-2.5GHz 1M Cache Athlon 64, Single Core 1.6-2.2GHz 512K Cache Duron 64, Single Core 1-1.5Ghz 256K Cache Now the average business user isn't going to need the 64bit core on a low end Duron machine, but they'll fall of the marketing hype. While the tech savy student with not to much money will love the Duron 64.

Re:Shouldn't be too long

[Ben Hutchings]

Window messages used to have two parameters, a word and a long-word which could encode integers or (16-bit) pointers. In Win32 these are given the types WPARAM and LPARAM, and they are both 32-bit. In Win64, WPARAM and LPARAM are both 64-bit. The names don't make much sense any more, but as long as you use them you'll be OK.

There are a whole lot more named types. If you use the right ones then you shouldn't have any trouble. If you use MFC then it'll pretty much take care of that for you. It's the application programmers that screw this up.

Re:Thanks for the info...

[ackthpt]

Fixed costs to the wind, recurring costs I gotta keep an eye on ;-)

It's gonna be a long year, the Hammer won't be out until late '01.

Link

Vote Naked 2000

Re:Shouldn't be too long

[um... Lucas]

But how many years after the 386 was introduced did 32 bits become the norm? Not until Windows 95, even though the Win32 DLL's were available for quite some time before then... Not just that, but adoption also waited two generations (til the pentiums came upon the scene).

Not just that, but for all their technical superiority, Intel is still king of the hill as far as x86 processors goes... ANd AMD is just stumbling into this position by sheer luck, since Intel's finally decided to pump resources into an architecture besides x86. It'll be interesting to see how many vendors look blindly away from AMD and follow Intel onto the "next great thing".

there could be a great chance, though, if AMD doesn't keep it in the high-end niche. If every chip, Duron or Athlon, they sell is 64 bit, it'd do great for market penetration...

I wouldn't expect this 1st generation chip to change much... after it's gone through a few iterations and there's quite a few million of them deployed, we'll be able to expect to see a plethora of 64 bit apps. But not for a few years...

One other thing is how will this stand up to Itanium? performance wise? Since performance is really the only incentive for people to move to 64 bit chips?

Off topic, but when will we ever see dual processor Athlon motherboards, anyhow?

Re:Why Sledgehammer?

[gnugnugnu]

Why Sledgehammer?
After the cheesy 80's TV show of course

Sledge Hammer!

--
and of course the obligatory "Wow, imagine a beowulf cluster of these"

Re:This is Big

[Fnord]

But MS can't kill this by not running on it. They already do run on it. Its completely IA32 compatible. It just has the capability to do more with some 64bit instructions. If this chip just catches on thanks to the fact that its all around fast and people realize "hey....on linux its even better" then things could happen.

Re:Porting from 16 bit to 32 bit

[treke]

In terms of Linux, everything was 32bit from the start. Now things took longer in Windows land(taking longer?) where 16 bit dos and Windows programs are still being written.
treke

Binary compability

[maligor]

Will the 64bit Sledgehammer-Linux be able to run binarys compiled on a 32bit x86?

Obviously programs compiled for 64bit would work faster in a 64bit platform, but how far will companies go? Support all Intel IA-64, AMD x86-64 and normal 32bit x86 prosessors? Now there are major differences between IA64 and x86, so you might have less problems porting to Sledgehammer since it's closer to the old and most likely less of a change to run into compability problems.

Might well be a deciding factor witch wins, but then isn't the IA-64 supposed to be for Webservers?

Re:Binary compability

[Yhcrana]

Yes... that is one of the things that AMD has been pushing for with this processor... you won't NEED to recompine the binaries for the newer processor, but that particular binary won't be able to take advantage of the advanced features the Hammer series contains (more registers and such)

IA-64 would require you to re-compile all the binaries in the IA-64 Instruction set as it isn't truly an extension of the 32 bit system we use now. AMD will be able to jump quickly into the 64 bit field, but Intel might be able to edge them out on performance when the 64 bit compilers hit the scene for the IA-64 chip.

Yhcrana

Re:Why Sledgehammer?

[Bun]

'Cavalier' is another word for 'knight'. I'd say that's fairly positive.

Re:Sledgehammer as a high end server platform?

[Chris Burke]

Sledgehammer is aimed at the same market space as the Itanic (sorry, reg, but I love this name). Only big servers really care about 64 bits at this time, but 'this time' seems to be the forseeable future.

As far as ports... according to the docs, it should run any 32 bit OS that runs on current x86 hw. They won't take advantage of the 64 bit features, but if you don't need em...

This is a very smooth move by AMD.

Re:Sledgehammer as a high end server platform?

[Ded Bob]

I could only find this mention about some preparation for FreeBSD: Usenet post. I did not search for OpenBSD or NetBSD.

P.S. Has anyone else had trouble with Deja's power search? It won't recognize group searching, and it refuses to sort by date.

Thoughts...

[Deflatamouse!]

Sledgehammer is supposed to be backwards compatible with all the previous x86 platforms. That means even if no one ports anything, it should be able to run all existing x86 software just fine. Obviously if one is to take advantage of the 64-bit processing power, it would be useful to have a 64-bit operating system. Isn't this very similar to pre-windows 95 days where the operating system (Win 3.xx) is 16-bit while the processors, i.e. Pentium Classics and 80486s, were 32-bit processors?

If that is true, the transition from 32-bit CPU to 64-bit CPU would be very smooth for the average consumers. However, how many of us really need 64-bit memory addressing or even 64-bit arithmetic operations? If any transition is to occur in the general consumer market, the Sledgehammer would have to outperform the Willamette (either in performance/cost or clock for clock) in order to win the market. Most people will still be running 32-bit applications for the next year or two. The performance (and cost!) winner between the Willamette and the Sledgehammer would determine which company will ultimately come out on top.

Just my $0.02.

Re:Thoughts...

[ackthpt]

Expect Linux powered Sledgehammer to be pushed out into the server market, initially. Probably into the workstation market. Price will determine how fast it appears in this order:

A. Hobbyist/Gamers
B. Executive who just has it for prestige
C. Engineering Workstations
D. Mindless drones
E. People who actually need one
E. Web Developers ;-)


Vote Naked 2000

Re:This is great.

[ackthpt]

MS should have fun playing catch up with the Windows monstrosity

Sorry to bust your bubble, but NT has been running on Alphas for years. (A condition, I understand, of DEC granting M$ a peek at VMS) Probably not a big deal for M$ to gum up the Sledgehammer with NT. That it follows x86 architecture, AMD probably has not been busy running from a gift horse, expect all M$ stuff to already have been tested in 32bit mode.


Vote Naked 2000

SuSE has it's priorities a little off

[discore]

Don't get me wrong, I _love_ SuSE. I run it only my webserver and my gateway. It's an amazing distribution and I would say a close call with Debian.
But I have a problem with SuSE wanting to port things to a chip that isn't even out yet, when they don't have a SPARC port out =(
I've read for a while now that they are working on it. It's just sort of disappointing I'll have to wait even longer before I can get SuSE on my couple Sparcs that are lying around.
Anyone else agree maybe SuSE should port things to a platform that has been out for years and years before they port to something that isn't even out yet?

Re:SuSE has it's priorities a little off

[LenZ]

I've read for a while now that they are working on it. It's just sort of disappointing I'll have to wait even longer before I can get SuSE on my couple Sparcs that are lying around.

We are already showing it off on our booth at Linux World San Jose. And SuSE Linux for Sparc will definately be out before SuSE Linux for x86-64.

Re:SuSE has it's priorities a little off

[Anonymous Coward]

?, You been smoking crack? Even if the Sledgehammer is a flop it will sell more systems than all the Sparcs ever sold. I'm afraid Suse has their priorities straight. Not to mention the boost to their share of the Sledgehammer market being much bigger due to having the longest experience porting to it, and the increased publicity from being the most visible early port.

Intel's doom?

[Phalse Impressions]

Well it has always been long noted that anyone trying to start something new with little backwards compatability is doomed to fail. Look at the long legacy of it.

What will make more sense to to is build a processor that has near equal performance then that of the old cips when it comes to 32-bit code as well as support 64-bit code. Once you are in the market and have wide support on the next generation of processors drop the 32-bit support and have a new 64-bit processor thus giving a boost on performance and improving what is already there.

If this really is the route that AMD will be taking then all the more power to them. I don't want to have to run 2 computers just so I can use 32-bit apps AND 64-bit apps.

Re:Could this also mean 3DNow! support in gcc?

[dripton]

Some Athlon support has been added to gcc over the last few months by SuSE's Jan Hubicka. (There hasn't been an official gcc release since 2.95.2 last year, so you need to grab a recent weekly snapshot, or pull from CVS.) I wouldn't bet on 3DNow! support in gcc. 3DNow! (and SSE) still seem to be supported primarily through inline assembly. But I think there's a decent chance we'll get an Athlon-optimized (i.e. recompiled with Athlon flags) SuSE distribution. That would be an easy way for SuSE to grab a bit of market/mind share among Athlon users from Red Hat/Debian.

Re:Nice

[lalas]

AMD is being pragmatic. x86 doesn't inherently suck. x86 is not a bottleneck that is keeping the hardware industry back. It has taken a lot of heat recently, but its critics have other options.

Re:This is great.

[Bun]

NT has been running on Alphas in a sort of interpreted mode, um, iFx86, or somesuch and is most definately NOT native. Witness that Win2k is available only for x86 platforms.

Re:This shouldn't be hard

[Fizgig]

Well, it'll work with Linux right now, but you can't do anything 64-bit at all with it without a port. Sledgehammer has 3 modes. The first is legacy mode. You use that to run a 32-bit operating system and 32-bit applications. Linux will run in this way out-of-the-box. You can't run 64-bit applications in this mode and have to reboot to change. Then they have "long mode " which is split into two other modes, whose names I don't remember. Long mode runs a 64-bit operating system. The first of the long modes (compatibility mode or something) runs 32-bit applications on the 64-bit operating system. The second mode runs 64-bit applications. The two long modes can be changed by a context switch, so you can be running 64-bit and 32-bit applications on the same 64-bit OS.

Re:AMD and Intel

[Fizgig]

Anybody else notice that this might be the single biggest advantage of Microsoft's .NET program? Most of their program sounds vague, but the platform independent binaries actually sound like a good idea. They'll distribute the binaries in a java-bytecod-esque form and they'll be compiled native to the machine on installation (oo, that's going to make installing big things fun).

Of course, you can do basically the same thing with open source (I can't see how you wouldn't have similar portability problems), but this would be the solution for closed source stuff. So your new database or game or whatever will compile to your itanium/sledgehammer/z80/whatever. Well, I guess they can hope.

Re:AMD and Microsoft

[Josh]

Microsoft will initially favor Intel's IA64 over x86-64 for economic reasons: in order to get any kind of performance from IA64, people will need to buy all new software. For the same sort of reason, Linux is strategic to both AMD and Intel because once compilers are ready, it will be possible for distros to come out that have performance critical apps all ported to the new 64 bit instruction sets. Because of this, and the fact that Linux is big in the server market, Linux will be very well represented among early adopters of either architecture.

Re:This shouldn't be hard

[SEE]

Well, the Linux code base currently supports x86, and it has already been adjusted to cleanly compile for 64-bit processors. So a 64-bit extension to x86/IA-32 shouldn't require very much in the way of new code; probably the most work would be getting gcc to compile for x86-64.

So, it isn't necessarily because Linux is/isn't easily ported, but that it's being ported to an architecture that doesn't differ very much from what the Linux code already supports.

Steven E. Ehrbar

BIOS ? please not ...

[otmar]

I hope the X86-64 architecture finally scraps the old PC-type BIOS system. If they plan to target the server market, I hope they have enough clue to use something like OpenPROM or ARC.
A server must be remote manageable by a serial line. That's what's stopping us from rolling out intel-based servers.

(Yes, I know there are certain workarounds, but they are just that: workarounds.)

/ol

Re:BIOS ? please not ...

[OpenFirm]

CodeGen is looking at supporting a 64-bit native version of SmartFirmware
on the Hammers. You would be able to directly boot a long-mode x86-64
O/S from either flash, disk or the network, without any intervening
boot loaders. Certainly not the current mess of boot into 16-bit real
load the 512-byte L1 boot loader, load the L2 boot loader, switch to
32-bit protected/flat-mode, load the L3 bot loader, load the O/S, or
variations thereof, that are currently done. The O/S would then
be able to use the client interface to query every attribute of
the system just like Sparcs and PowerMacs.

How much support would there be for this project?

Re:BIOS ? please not ...

[photon317]

[ This is so late nobody will read it but the poster, but that's what it's here for ] I recently bought some VA FullOn 2x2 servers to testbed some Beowulf stuff. The Intel motherboard in these things is capable of a certain level of serial management.

You still have to configure the BIOS via VGA... but once you've got the config done, you can check status (is machine up), power on/off/reset, etc... via a serial port. Of course, if you run linux you also get serial console from the boot loader onwards.

I think it's called IPMI (Intel Platform Management Interface???)... check VA's website for their VACM server management product,which lists supported boards for serial management, etc...

At least it's a step in the right direction.

Re:Sledgehammer as a high end server platform?

[darkonc]

64-bit windows will not happen in the next few years. Even if Microsoft should ship a native 64-bit NT, _and_ actually finish up Win64. It's the applications that matter, and that is one thing that Windows just do not have (despite popular (trash-media) belief).

I'm willing to bet that we'll see the MS Office suite ported by the time (if) it's released, as well as just about any other heavily-used M$ product.

AMD

[B00yah]

AMD has Linux POWER!!! FINALLY!!!!

Nice

[lalas]

It's nice to see the relative ease in which the transfer to AMD's new architecture will be made. I can't imagine that Intel will be so easy.

Re:Nice

[Pink Daisy]

Intel abandoned x86 because it sucks. If AMD doesn't have the market clout to do the same thing, that's understandable, but it's not something to congratulate them for.

Re:Nice

[Pink Daisy]

I've only taken two courses on architecture so far, and no practical design experience, so I'm not a huge expert, but applying the relevant parts of my education tells me that, yeah, x86 in fact does inherently suck. I'm not sure the order of difference between IA32 and IA64, so I can't say if Intel has gone far enough, or even in the right direction, but my somewhat informed opinion is that leaving x86 was a good move.

Re:SuSE

[DickBreath]

I loved the 6.4 upgrade because of things I really wanted to try, like PHP4-betas, JServ, etc.

YaST2 could finally configure my sound properly. Use YaST1 for everything else. (You'll be glad you did.)

The standard various updates of many odd packages. Various minor improvements in KDE, etc.

Overall, nothing is *radically* improved.

If you can find 6.4 on clearance somewhere for $10 (because of upcomming 7.0) you should jump to 6.4.

SuSE

[MicroBerto]

It seems that SuSE is so involved in many projects out there, and doesn't get much credit. And they don't have a very large market share on the distribution level either. My favorite thing that they help a lot in is The Alsa Project (great sound drivers). SuSE certainly deserves more credit for helping keep Linux on the bleeding edge, so I just thought I'd toss that in.

Mike Roberto
- GAIM: MicroBerto

Re:SuSE

[Dan93]

Agreed. After using Redhack for 2 years, and trying out other distrobutions (Debian, Turbolinux (YUCK!!!!!!), and Slackware), I agree that SuSE ROCKS!

Re:SuSE

[one61803]

Actually, SUSE is pretty big in the European market like Redhat is here.

I do believe though that SUSE should get more credit for helping out linux development. I believe they also made significant contributions to Xfree86 especially the drivers.

This shouldn't be hard

[cvd6262]

One of the comments (it might have been from Linus), when AMD announced their 64-bit chip was that this should be the easiest Linux port ever.

Is this because Linux can be so easily manipulated for it's host environment, or because it's just powerful enough to run already on a 64-bit machine?

Re:This shouldn't be hard

[Anonymous Coward]

The 4 level page tables might be a problem: The Linux kernel assumes either 2 or 3 level page tables. The rest should be fairly simple.

Re:This shouldn't be hard

[lupine]

Correct me if Im wrong, but the sledgehammer runs 32bit code native and so it seems to me that linux should work right now(might need to be recompiled?).

The only real work that should be done is to optimize the source to make use the the new 64bit operations. This is needed so that the sledgehammer can compete against itanium and so linux can compete against win2k. This will also force ms to produce an optimized win2k version unless they want to loose a boatload of server installs.

Watch movies made with the games you play http://www.machinima.com/

Re:This shouldn't be hard

[jallen02]

I shall hazard a reply :)

Linux has already been ported to 64Bit architectures.

Linux can already run x86 instructions.

So really the asquired knowledge is already there no real ground breaking stuff, just porting to a new architecture, *nixes are used to do this.. nothing new to see here move along move along ;)

I am partially kidding, its not really new moving to a new architecture its just exciting because its x86 and it is widely accepted by the rest of the world.

Jeremy


If you think education is expensive, try ignornace

Why Sledgehammer?

[kwsNI]

Why did AMD name their new processor something like that? I mean, normally, you'd associate sledgehammers w/ something you'd want to keep AWAY from your computer.

And Chevy? WTF is up with the Cavaliers? Who's brilliant fucking idea was it to name a POS car after the losers of a civil war?

kwsNI

Re:Why Sledgehammer?

[netbiker]

In Switzerland, there's a drink called "Williamine" made from distilled Williamine pears. It gets you very, very drunk, after which you feel the Sledgehammer in your head...

So the Sledgehammer seems to be the natural successor...?

- netbiker

Re:Why Sledgehammer?

[jallen02]

Its simple, its functional.

The name implies strength

You dont forget about it

Those are most of the major tenets of a good trade mark / advertisement.

I like it ;)

Jeremy


If you think education is expensive, try ignornace

Re:Why Sledgehammer?

[Rayban]

Remember Peter Gabriel?

o/~~ I wanna be... a sledgehammer... o/~~

I can just picture that as the new AMD themesong in the ads. :)

Re:Why Sledgehammer?

[kwsNI]

The name implies strength

To me, it implies that the system will be so loud, you need gas filled ear protectors to use it ;)

kwsNI

Re:Why Sledgehammer?

[iceT]

"Why did AMD name their new processor something like that? I mean, normally, you'd associate sledgehammers w/ something you'd want to keep AWAY from your computer."

Obviously, you've never worked with WindowsNT, have you?

Re:Why Sledgehammer?

[snort]

Well, Sledgehammer sure as hell beats "Willamette" right? And it kind of fits in with the Thunderbird, Spitfire naming scheme (yes, one was a car, the other was a nice airplane, but they SOUND cool).

And Chevy has a long history of naming they're cars weird things. Like the Nova that didn't sell very well in Mexico. ("no va" in spanish means, literally, "no go").

Re:Why Sledgehammer?

[fsck]

I miss that show so much. Such a cheesy spoof on dirty harry.
We need to bring back quality programming like Sledge Hammer and MacGuyver, although Buffy The Vampire Slayer is the only reason I have cable TV.

The price of power

[leonbrooks]

AMD has Linux POWER!

Hmmm... this might be better for Linux than it seems. I priced an MS Web server on Monday:

• Windows 2000 Server Edition, $Oz1400
• MS-SQL 7, $Oz1600
• Internet Connector Licence for SQL, $Oz2500 per CPU

Total, $Oz5500 plus hardware (around $Oz2000-2500) (-: all prices include GST :-) == $Oz7500-8000.

Now, if Microsoft count a Sledgehammer as two processors, that becomes $Oz10,000-10,500. Ouch.

Contrast with Linux: Cost of system: $Oz2000-2500, plus maybe $50 if you buy somebody's boxed set. Given a choice of:

• one Windows K6-II for $Oz7500-8000; or
• one Windows Sledgehammer for $Oz10000; or
• one Linux K6-II for $Oz2000-2500; or
• one Linux Sledgehammer for $Oz2500; or
• two Linux Sledgehammers and failover for $Oz5000; or
• two Linux Sledgehammers and failover, plus a Linux Sledgehammer with a GeForce2 for "administration purposes" for $Oz8000...

...which would you pick? (-:

If you were a supplier working to fit a $10,000 budget, which would you pick?

Sinking point

[leonbrooks]

However, how many of us really need 64-bit memory addressing or even 64-bit arithmetic operations?

Me! I want to do single-cycle scaled-64-bit-integer arithmetic to sort out my 3D graphics, instead of multi-cycle or floating point, thanks. Better still, I want to do two of those on each clock cycle so my CPU is doing more than a 3GHz Athlon would, in the nanoseconds before it melted a hole through the floor.

Speaking of which, I hope this monster won't require a 500W (!!) power supply and a wind tunnel like an iTanium does.

If the CPU uses less than about 20W it will be feasible to integrate one with a 3D card (geForce 2001 anyone?) so most of the game logic lives on the video card. Propagation delays? We don't need no steenking propagation delays! Your other x86-64 CPU could be busy pushing really cool noises (doppler/phase-distorted SFX to match fast screen action, for example) into a sound card when it's not handling the network and control interfaces.

AMD and Intel

[LordDartan]

Since AMD and Intel are each making their own instruction set for 64bit, does that mean that software will have to be written for both?? Or is there going to be some compatability layer that allows AMD chips to run Intel code and vice versa??

Re:AMD and Intel

[Joe Groff]

GCJ is working on this sort of thing; it compiles Java source to native code, and can also compile Java .class bytecode into native code as well. It also has some cool features, like the ability for native compiled code to call on Java bytecode, etc. It's a cool project, check it out.

- Joe

Good Work SUSE

[drenehtsral]

I have to say, although i don't particularly care for the SUSE distribution (to be fair, i haven't tried it in a year or two...), they do seem to do a lot of really good work on X, Porting, and several of those other really hairy areas where it really takes full time programmers to make a real dent in the problem.
Also, has anybody tried SUSE lately? When i last ran it, it used a very odd combination of library versions, so it was a pain to get and build about anything on it...
Also, does anybody know if SUSE is a profitable company?

Re:Good Work SUSE

[Brigadier]

I chose SuSE for this very philosophy, at the time it was their support for the G200 cards, free support that is. Just my tidbit to promo my favorite distr.

Re:Good Work SUSE

[ackthpt]

Oh gosh. There was a review of various Linux flavors I was just reading last week... Ah, here it is... a bit dated, but something to start from.

Link

HTH

Vote Naked 2000

This is great.

[Th3 D0t]

This should accelerate the mainstream acceptance of the 64-bit architecture greatly. It will easy to port applications from current x86 linux to this architecture. Now if they'd make a 64-bit version of Kylix, we'd be all set! MS should have fun playing catch up with the Windows monstrosity.
---

Re:This is great.

[one61803]

I personally don't think Kylix will get anywhere. Not to sound like a troll but I seriously think the majority of Linux users are cheapskates who see Open Source software as stuff they can take and use with a clear conscience. Thus, I don't see any chance of a Linux user paying >$50 for an IDE.
In fact, Cygnus has been selling a pretty good IDE (Cold Warrior I believe) for a good while and look at the success of that. StarOffice and Applixware haven't exactly been much of a success either despite the need for a Linux-based Office application.

Re:This is great.

[Down8]

MS is working on full 64 bit support, I believe Whistler will have a native 64 bit version, and it's already in alpha. -bZj

Re:This is great.

[Bun]

I'm sure their 64-bit support is more geared towards the Itanium, rather than the Alpha. Still, it could well that Compaq might yet see a native Alpha port of Win2k.

Re:This is great.

[Bun]

I'm sure MS ported portions of NT to the alpha, but it was my understanding that the bulk of it ran under FX!32. My memories of this are a bit vague, however, and stem from an old PC World magazine article which tested NT on a 500MHz Alpha.

The Chameleon?

[pigpogm]

The chameleon has got itself a sledgehammer? Is this the violent chameleon from the Bud ads?

"Hey, Louie, what have you done to Bill Gates? I know none of us liked what Bill was trying to do to the Penguin, but Louie..."

"Bud"

"Er"

"vies"

Shouldn't be too long

[_Mustang]

after that the rest of the distro's get support for it as well. Based on the article, I would question just how much effort is going to be put into the actual applications. Sure the OS will support this, but since this new X64 will run X32 apps just as well where is the incentive for writing enhanced applications..?

Re:Shouldn't be too long

[NRLax27]

Right, we didn't see widespread 32 bit adoption until around the time of the Pentium, but that was when the compilers changed their defaults. Like I said in the parent post, when compilers start outputting 64 bit code, most people aren't going to force it back to "32 bit compatibility mode".

Re:Shouldn't be too long

[-|Oblom|-]

Nd AMD is just stumbling into this position by sheer luck, since Intel's finally decided to pump resources into an architecture besides x86
It's not like Intel stop all development on x86. They still have Willy that supposed to come out in the Q4 which is supposed to be 7th generation of x86 in Intel. And tweaked once more P3 (to 0.13 micron process this time). And it's not luck that brought AMD to his current position but lot's of hard work. They did product that had better bang for backs, and they made it widely available. And it's not something that you can say about paper luanches of 1Ghz and 1.13Ghz P3. Intel's plan was going according to Moore law. Now it's supposed to be time for ~900Mhz cpus according to it. So it's what is available from Intel now. The rest is mostly paper (or "limited quantities")
It'll be interesting to see how many vendors look blindly away from AMD and follow Intel onto the "next great thing".
Enought. Dell, SGI for example. But the problem that "next great thing" was supposed to be released in 1998

there could be a great chance, though, if AMD doesn't keep it in the high-end niche. If every chip, Duron or Athlon, they sell is 64 bit, it'd do great for market penetration...
Hammer supposed to became common CPU that will be available in desktops.Unlike Itanik

Re:Shouldn't be too long

[NRLax27]

Well, 32 bit x86 machines will run 16 bit x86 apps also, however people don't write 16 bit apps anymore. When 64 bit becomes the standard, the compilers will default to 64 bit code, then people will not write 32 bit anymore (at least not unless they need to use it in special situations)

Re:Shouldn't be too long

[NRLax27]

Just one more thought...concatinating the title of the post and the first sentance:

Shouldn't be too long after that the rest of the distro's get support for it as well

I would think that the Sledgehammer modifications would be kernel patches. So once Linus adopts the patches, all the distros should have them at the same time.

Re:Shouldn't be too long

[arivanov]

ust as well where is the incentive for writing enhanced applications..?

In the binary only commercial world - none. Sun is already locked up in this paradigm. Have a look at solaris. 64 bit kernel, most of the apps are 32 bit in order to be compatible with older sparcs.

If the app is distributed as source and the toolchain is 64 bit the app will be promoted automagically.

Re:Shouldn't be too long

[fsck]

Linux was running in full 32 bit mode on 386 and 486 processors while MessDOS and Windows3 was crashing in its single-user-only glory.
Innovate? Fuck that, Win9x is still 16bit and NT is still single user.

Sledgehammer as a high end server platform?

[cheezus]

It's nice to see that the linux community is getting help from a corporation in supporting new hardware. It's a nice change from hardware vendors having to make sure their product is MS compatable, instead of vice versa like it should be

So what is AMD's plan? Is Sledgehammer going to be used in highend servers? If this is the case, I think they are definelty taking the right course in not only helping out linux, but also protecting their interests. It would be hard for other chip manufactures to compete with a more powerful platform that had multiOS support. Linux and (i'm gonna assume here) NT/2000 are a good start. Has there been any news from the BSD camp on a port? I mean, "of course it runs NetBSD", doesn't it?

---

Re:Sledgehammer as a high end server platform?

[Oestergaard]

Don't expect NT/2K to run in ``real 64-bit mode'' on the sledgehammer anytime soon. NT never ran 64-bit on the Alpha either, user-space processes were always 32-bit.

Porting NT to a 64-bit CPU may be doable, and it seems MS is doing just that. With Linux that took some effort too, but luckily that was done while Linux was still young.

However, there's a lot more to 64-bit computing than just the kernel. You want your user-space to go 64-bit as well, and this is where it gets innteresting... Why didn't NT on the Alpha run 64-bit processes ? Well, does Win_32_ ring a bell ?
In POSIX-like systems such as GNU/Linux, you use data-types such as int and char* for passing integers and pointers to data. In Win32 you use DWORD and LPxxx etc. The Win32 DWORD is _exactly_ 32 bits, and every program written for Win32 will tend to depend on this. Even worse. the LPxxx pointers are _also_ assumed to fit in the same space as a DWORD, namely 32 bits. A program using char* to reference a block of data, will be equally valid on 16, 32 and 64 bit architectures, because the datatype states it's just a pointer. In Win32 your LPxxx types are 32 bits, meaning they make no sense in a 64-bit environment. Tough.

What I'm getting at (slowly I know) is, that while Microsoft is currently trying to design a Win64 API that everyone must now port their programs to in order to take advantage of the 64-bit environment, the GNU/Linux community will hit the ``make; make install'' combination, and the vast majority of applications will only need minor fixes if they have not already been ported to a 64-bit architecture. But chances are, of course, that the vast majority of GNU/Linux apps have been working just fine on 64-bit architectures for years.

64-bit windows will not happen in the next few years. Even if Microsoft should ship a native 64-bit NT, _and_ actually finish up Win64. It's the applications that matter, and that is one thing that Windows just do not have (despite popular (trash-media) belief). Go easy :)

AMD SMP

[Rayban]

Will we be able to finally get SMP with these AMD chips? Right now we have these amazing Athlons capable of symmetric multi-processing, but no mobo hardware support for them.

IMHO, AMD has gone the right way with x86-64, rather than a whole new instruction set. At this point in the game, I don't think they have enough market pull to convince people of once standard vs. another. It's a bit of a shame Intel and AMD couldn't have cooperated on a comment 64-bit spec, but I know exactly what sort of chance that would have (it involves a snowball and a very warm place...).

Re:AMD SMP

[snort]

This fall we'll have SMP Athlons. We're waiting for AMD's 760MP chipset... Supposed to do SMP and DDR SDRAM.

I just wish they'd kick me down a few engineering test samples.

This is Big

[Moridineas]

AFAIK MS hasn't even announced if they would port Windows to Sledgehammer. This could be a clear area where Linux truly (no questions asked) beats MS to the punch. If Linux can be ported in a timely manner, and the Sledgehammer also is released in a timely manner, this really could be one hell of a blow to both Microsoft and Intel.

Re:This is Big

[Oestergaard]

There is one problem though... We need the desktops using this processor if it has to be just remotely affordable, and if we want a decent number of motherboards to choose from

How cheap is the Xeon currently, even though it has very few benefits over the ``desktop'' processors such as Athlon or PII/III ? Not very. Why ? Because it's not sold in mind-boggling quantities. Well, also because Intel prices it in the high end, but that's a chicken-and-egg scenario wrt. the desktop market.

Currently, in this era of the lemming mentailty, we depend on MS windows processor support, if a processor is to be used very widely. Unfortunately this means, the Sledgehammer won't be affordable until MS releases an OS for it. Yes that sucks, but blame society :)

But yes, GNU/Linux support for the Sledgehammer some year or two ahead of Microsoft is going to give us great press. At least for a month or so. But counting in the long-term memory and interest in any kind of history (even just last year's history) of reporters, I doubt that we will benefit much from this once MS finally ships their OS for the Sledgehammer.

Don't get me wrong though. I think this is great, and the Sledgehammer may well prove as an alternative to the high-end and expensive Xeon CPUs from Intel, and they may well be used by those who need it enough to be able to afford it, for things like Oracle, SAP, weather forecasts, nukes, and what gives...
Way to go SuSE ! (and AMD!) :)

It's a "for profit" company?!?!

[karmma]

Obviously, you haven't seen VA Linux stock prices. Wow.

---------------------
This space available. Reasonable rates.

NONONONONONONO

[snort]

6x45GB 15000RPM drives

sheesh, get it right :)

Re:NONONONONONONO

[ackthpt]

Yeah, you're right, and maybe a RAID-5 while I'm at it...

Vote Naked 2000

screw ia64

[kennedy]

Hmmm.... wouldn't it be really weird if the sledgehammer became the native linux platform? think about it... sun and solaris have the sparc chip as the base and they ported to x86 after... the sledgehammer could become the base for linux and everything is ported from there. then again i could have just forgotten to take my pills today hehe

the real stuff

[Spider-X]

Ripped from their website:

This site, supported by AMD, is dedicated to porting GNU/Linux to AMD's new x86-64 architecture. Eventually, you'll be able to download complete GNU/Linux distributions for x86-64 from this site. For now, there's technical documentation about the architecture and mailing lists for discussing x86-64 GNU/Linux. In the near future, there will be an architecture simulator as well as experimental versions of GCC and binutils that can generate 64-bit x86-64 code.

This is indeed great news. The simulator will be free! Not only that, but they have those fine German engineers from SuSE helping with the port. I've always loved the way SuSE provides that extra something with their Linux distros. Heck, my first X-Server was from SuSE (I had a Tseng 6000 chipset that wasn't supported by XF86_SVGA). Not to mention ALSA, and YaST2.

-----------

Could this also mean 3DNow! support in gcc?

[ncc74656]

The index page for x86-64.org indicated that one of the earlier goals for the project will be to add x86-64 support to gcc (gotta have gcc before you can do anything else). Since x86-64 is a superset of IA-32 (what we're all using already) and 3DNow!, what do you suppose are the possibilities of 3DNow! optimizers finding their way into gcc? For those of us running K6-*s, Athlons, and Durons, this would be a Good Thing (TM), and I suspect it's something would benefit Sledgehammer once it's out.

_/_
/ v \
(IIGS( Scott Alfter (remove Voyager's hull # to send mail)
\_^_/

Linux should have an easier time...

[JCCyC]

...being ported to this beast than NT/2K. I read somewhere that NT can't use all the Alpha address space, not because of processor dependence, but word size dependence. If you ever programmed to the WIndows API, you'll see everything is WORD this, DWORD that. Too many places there assume word/dword length.

I read in the same place (someone please enlighten me on this) that NT has a kludgy, EMS-like API for running on the Alpha, in order to not waste all that memory completely.

I'm pretty sure it was either a Dr. Dobbs or a MS Developers Journal. It'd be good if someone could point us to the exact article... did I ring any bells?

Re:AMD and Microsoft

[Oestergaard]

Most likely, I suppose AMD has secretaries like most other companies ;)

But do you think that AMD would be spending time and effort on a Linux port right now, if NT for Sledgehammer was just around the corner, with server applications support etc. etc. ?

My bet is, that AMD tried, and Microsoft were either honest (heh, no let's be serious) or AMD figured out that Oracle/MsSQL/DB2/SAP/whatever on 64-bit NT is much further away than anyone planning to ship a new CPU this decade would like to even think about.

The GNU/Linux system has the easily-adabtable tools, the easily-portable user-space, and an easily portable kernel. While Microsoft has the marketing people, the company with an employment politic that says education doesn't matter, somehow (I wonder why, nah, I don't) doesn't have any of the other.

Also Amiga

[meadowsp]

Also this mythical "new amiga" seems to be the same thing, platform independant binaries. I wonder which one will come out top?

Incentive...

[Mustang Matt]

The incentive will be more powerful applications and doing what we do now faster. It might not happen overnight but it will happen...

Think of it kind of like the way AMD came out with 3DNow. They were extra instructions that could be used to speed things up. It took a while but now most games support those extensions.

matt

Re:Linux should have an easier time... C/C++ boo^2

[JCCyC]

I blame part of this porting difficulty on the C/C++ language(s).

They made a tradeoff. Porting is more difficult, but when it does get done, it's using the new platform to the max. IMHO a wise decision.

IMHO, you should be able to declare variables in a platform-independent way that specifies whether you need, e.g., exactly 16 bits, or at least 16 bits (or 32 or 64 or 12, or whatever).

You can do that, only there's no standard. In the Windows world it's BYTE/WORD/DWORD, in other places it's int32, int16 etc (better I think).

The only way you can do this now is very kludgy tricks with doing conditional compiling based on limits.h info, or cleaner kludges using templates, but still kludges. It's kludgy (IMHO) because the compiler is saying, "there's a limits.h file that defines the properties of this platform, but I don't know how to use that to permit platform-independent declarations, so you program around me."

Correct. In other words, no standard, as I said.

WORD and DWORD etc. should not be an obstacle to a port that works, (assuming they've been very consistent and have no unsafe conversions) but it may be an obstacle to optimization.

Pretty non-trivial assumption. Boy, I wish I still had that article. It was in a magazine at my previous employer. It detailed a vast number of hurdles in porting Win32 to Win64.

Mental note...

[NRLax27]

"Hopefully by the end of next year I'll be running dual-core 1.5Ghz(at least) Sledgehammer with Linux on it"

Mental note: Remember to start very successful geek-news website, and sell to Andover.net in order to have enough money to afford dual-core 1.5Ghz(at least) Sledgehammer machine

Re:Mental note...

[-|Oblom|-]

In fact it's not supposed to be that expencive. The 64bit part of the chip supposed to add around 5% to the core size. So the price will be (according to the common belive that hammer it's dual mustang + 64bit unit) 2x 1.5GhzMustang + 64bit unit + LDT...
I think that when it will be introduced (H2 2001)the price for the cheapest one wil be ~1500$(and then will go down slowly) and it will be hell more cheaper then Itanic system.

PS. I did started now new site, over here (Israel) with intention to sell it later to one of the ISPs :-)

AMD and Microsoft

[staili]

Has AMD made any deals with Microsoft?
-
The distance between insanity and genius is measured only by success.

Re:AMD and Microsoft

[nd]

of course

Porting from 16 bit to 32 bit

[funk_phenomenon]

How was the effort made to go from 16 bit to 32 bit? Was it a hard effort, as the Sledgehammer project looks? I guess the internet is making it a lot easier for people to port.

Even the samurai
have teddy bears,
and even the teddy bears

Re:Thanks for the info...

[Chris Pimlott]

If you're going to go wish for all that stuff why settle for DSL? OC12 at a minimum, I'd say.

Will the 16 bit instructions remain?

[Decimal]

Well, 32 bit x86 machines will run 16 bit x86 apps also, however people don't write 16 bit apps anymore. When 64 bit becomes the standard, the compilers will default to 64 bit code, then people will not write 32 bit anymore (at least not unless they need to use it in special situations)

Or would it be too detrimental to cut them out? Clearly, somewhere along the line it will be more of a benefit to cut out the oldest gears than to keep them.

Thanks for the info...

[ackthpt]

Dear Santa,

I've been a very very good boy this year. Please consider the following from my wish list:

AMD Sledgehammer

SuSE Linux

VIA PC 266 chipset (64bit equiv.)

DDR SDRAM

Mobo for all of that

Overclocking tips from Tom's

SCSI controller and 4x45GB 10000RPM drives

A 3D supported LCD letterbox montor

THX surround sound

DVD burner

A DSL provider who actually delivers

100 lbs Kona Espresso beans, 500 lbs mixed Jelly Bellies (no apple, please) & a Thai delivery which stays open past 10 PM

Thanks!

Vote Naked 2000