C
chrisv
Yousuf Khan said:
A stupid article. He seems to think that "buying computers" is
something that is done all at once, with an eye toward OS upgrades X
months later. In fact, computers, 10's of thousands of computers, are
sold every freaking day of the year. It's not an off/on switch where
suddenly buying an Opteron makes sense. It's a grey scale, where
every single day it makes sense to more and more buyers.
R
Rob Stow
chrisv said:
I was particularly amused by the paragraph:
In my book, the whole AMD investment protection
story is a bit over-rated. Chances are, you’re going
to buy a new system anyway. I asked Knox about my theory,
and surprisingly he agreed, but his disclaimer was a time
threshold. “If you aren’t migrating for another two or
three years, you’re right,” Knox said. “Anything after that,
you should buy the best 32-bit system [now] and not worry
about backwards compatibility [later]. But, for people that
are migrating in 18 months or less, this makes sense.”
Why the heck didn't either Knox or that idiotic writer point out
that for most purposes AMD64 *is* the best 32-bit system available ?
Y
Yousuf Khan
chrisv said:
He seems to think that running 32-bit x86 programs in Opteron vs. in
Itanium's IA32 execution layer are pretty much on par. Why are they on par?
Because he feels like calling them at par.
Porting from x86 to AMD64 shows greatest cost savings when translating
assembly language programs. His gets all huffy at that point and says who
uses assembly language anymore? Pretty much anybody who writes device
drivers.
Oh and BTW, yeah AMD has seemed to convince a lot of OEMs, software ISVs,
and customers about the value of their solution, yada-yada-yada, let's just
get that out of the way so we can continue attacking AMD.
Yousuf Khan
K
KCB
Rob Stow said:
Another good one is this:
"I’ll yield to Opteron on this point because, based on the anecdotal
data, it will run those 32-bit applications faster than Intel’s IA32
Execution Layer. However, for applications and utilities in which
performance isn’t critical, the IA32 Execution Layer will probably suffice,
once again putting the Itanium and Opteron on par with each other. Let’s not
forget that for Opteron to win this uphill battle, par isn’t good enough."
Let's see, Opteron is faster to... it's on par with IA32EL to... par isn't
good enough. Excuse me?
T
Tony Hill
It seems to me like the author of this article is grasping at straws
to try and prove that AMD64 support is somehow a bad idea. He starts
out by pointing out that it offers the best price/performance for many
applications right now, which in and of itself suggests that it should
be a good product, but then goes on to complain that it might not make
sense when upgrading software 2-3 years down the line?!
He also talks about how the AMD64 approach is very beneficial in that
it allows you to keep running most of your legacy utilities and
"extra" programs while still running the latest and greatest 64-bit
server app. Again, it sounds like AMD did it right.
In the end, I'm not really sure what his big complaint about the
Opteron is, except that some people might not benefit much from it's
64-bit capabilities. It seems to me sorta like if someone were to
complain about a great 4-door sedan because right now the owner is
single and might not start a family for quite a number of years so
he/she won't really benefit from having a sedan instead of a coupe.
While it might be true, it misses the point that the car is great to
begin with, regardless of how many doors it has.
Y
Yousuf Khan
Tony Hill said:
I sent the author, David Berlind, an email going through some of his points,
he sent back a form letter saying that he's gotten inundated with emails
about his article and he can't answer them all. I'd say, "no kidding?"
He did answer a few of the common points (looks like a lot of people asked
him the same points at the same time). Here's an example:
---
"Several readers wrote in to say that I unfairly downplayed the significance
of converting x86 code, citing the effort it will take operating system
vendors and device manufacturers (that have device drivers) to convert the
code they've written in x86. The Giga study that AMD cites and that I was
critical of has nothing to do with this aspect of the x86 ecosystem. The
study focused on the costs that "typical Fortune 1000" companies should
expect to take on should they move their x86 assembly language written
custom database applications to a foreign instruction set such as IA-64.
Whereas the former's costs to port operating systems and drivers are borne
by those vendors, the latter's costs are borne by enterprises which is who I
wrote this story. This so-called typical Fortune 1000 is in reality
extremely atypical and I had to figure that out from the fine print myself.
In its presentation, AMD fails to disclose Giga's footnote: a practice which
I find to be deceptive. !"
---
So basically, he never thought that the cost of porting device drivers (the
vast majority of which are written in assembly language) would come into
play, because the AMD/Giga study never specifically mentioned them. Strange
he doesn't seem to have much trouble extrapolating and inferring things
other than that.
I've yet to see a database program that was custom written in assembly
language, even in the old small-memory days of DOS. However, device drivers
have always been written in assembly, and how somebody who claims to have
been in the IT industry since 1991 couldn't figure that out is a little
beyond me.
Yousuf Khan
A
Alexander Grigoriev
Device drivers has been written without assembly language for quite a long
time. Only very small parts of kernel need assembly. I'm not sure if you'll
be able to find much assembly in Linux driver's sources. Windows NT/2K/XP
etc and Win9x WDM drivers are all written in C and some C++. Assembly has
been widely used for writing Windows 3.0/3.1 VMM and VxD, but then there was
no 32-bit C compiler at Microsoft. Now, for quite a few years even VxDs (God
forbid!) could be (and are) written entirely in C.
I write WDM-style drivers for network and USB devices under Win9x and 2K/XP.
Making them to compile and run on AMD64 took a day. I can also compile for
Itanium, but don't have a system to test. The compiler helps to catch the
errors like trying to cast 64 bits address into 32 bit int variable, and
vice/versa. Such things as int->pointer and ponter->int conversions (with
explicit cast) are checked for bitness.
Can't talk for Linux, but I think its drivers are as easily portable (if
written with all the rules in mind).
time. Only very small parts of kernel need assembly. I'm not sure if you'll
be able to find much assembly in Linux driver's sources. Windows NT/2K/XP
etc and Win9x WDM drivers are all written in C and some C++. Assembly has
been widely used for writing Windows 3.0/3.1 VMM and VxD, but then there was
no 32-bit C compiler at Microsoft. Now, for quite a few years even VxDs (God
forbid!) could be (and are) written entirely in C.
I write WDM-style drivers for network and USB devices under Win9x and 2K/XP.
Making them to compile and run on AMD64 took a day. I can also compile for
Itanium, but don't have a system to test. The compiler helps to catch the
errors like trying to cast 64 bits address into 32 bit int variable, and
vice/versa. Such things as int->pointer and ponter->int conversions (with
explicit cast) are checked for bitness.
Can't talk for Linux, but I think its drivers are as easily portable (if
written with all the rules in mind).
E
Ed
Oh and BTW, yeah AMD has seemed to convince a lot of OEMs, software ISVs,
and customers about the value of their solution, yada-yada-yada, let's just
get that out of the way so we can continue attacking AMD.
Yousuf Khan
YES! finally an Opteron bashing article, just what Intel ordered!
Who cares what this guy thinks anyway, he just some bozo!
Ed
Y
Yousuf Khan
Ed said:
Bozos who get published are dangerous.
Yousuf Khan
Y
Yousuf Khan
Alexander Grigoriev said:
I know, but you gotta admit, even the C/C++ code that is written for device
drivers is a lot more architecture specific than code written for
applications, right?
Yousuf Khan
G
geno_cyber
AFAIK without using inline assembly there's no way to do many low-level things on hardware.
I never programmed WDM drivers but I know some DSP programming and if want to do that right you must
learn assembler because C interfaces/libraries are always pretty limited.
A
Alexander Grigoriev
Like there is API (application program interface) functions for application
programming, there are some known DDI (device driver interface) functions
for driver programming in a given OS. When an OS is ported to a new CPU,
most API and DDI remain the same. Size of structures can change, but C
programmer should not care about that. The most important change for
WinNT-IA32 to Win-64 is virtual address size (physical address has always
been stored as 64 bits there). The compiler helps to detect cases when a
virtual address is incorrectly casted into 32 bit integer, and vice versa.
For example, for a long time there are typedef INT_PTR and UINT_PTR, that
can hold an int equal in size to the virtual address. If a programmer used a
fixed 32 bit integer type instead (ULONG, UINT, etc), the compiler will
complain. Even in current MS 32-bit C compiler, there is a feature to detect
possible 64-bit porting problems.
In a few words, it's much easier than porting to a completely different OS
(and even in that case there are approaches that help in it).
programming, there are some known DDI (device driver interface) functions
for driver programming in a given OS. When an OS is ported to a new CPU,
most API and DDI remain the same. Size of structures can change, but C
programmer should not care about that. The most important change for
WinNT-IA32 to Win-64 is virtual address size (physical address has always
been stored as 64 bits there). The compiler helps to detect cases when a
virtual address is incorrectly casted into 32 bit integer, and vice versa.
For example, for a long time there are typedef INT_PTR and UINT_PTR, that
can hold an int equal in size to the virtual address. If a programmer used a
fixed 32 bit integer type instead (ULONG, UINT, etc), the compiler will
complain. Even in current MS 32-bit C compiler, there is a feature to detect
possible 64-bit porting problems.
In a few words, it's much easier than porting to a completely different OS
(and even in that case there are approaches that help in it).
A
Alexander Grigoriev
Only if you want to hand-optimize MMX/SSE code. In Windows kernel, the
hardware is accessible through WRITE_PORT_xxx and WRITE_REGISTER_xxx
function families and you don't need to (and should NOT) code IN and OUT
assembler instructions.
hardware is accessible through WRITE_PORT_xxx and WRITE_REGISTER_xxx
function families and you don't need to (and should NOT) code IN and OUT
assembler instructions.
K
Keith R. Williams
You're wrong. One can bit-bang in C, or a myriad of other
languages, just like one can in ASM.
That's because you're being forced to interface with the C
libraries. Given infinite time/money one can always do better
than libraries.
K
Keith R. Williams
Assuming your universe is limited to writing application code on
proteted OSs, sure. However, if you're doing kernel, or other
low-level priv stuff (how do you suppose WRITE_PORT is
implemented?), or in an embedded environment, no.
A
Alexander Grigoriev
You may need some assembly code (or C with inline assembly), if you need to
write a custom HAL for Windows. Not many custom HALs for NT are out there. I
know SGI did it, maybe HP.
If you're doing kernel drivers on Windows, you don't need asm.
WRITE_PORT_xxx and WRITE_REGISTER_xxx functions (which are exported from
HAL) are enough to read/write I/O ports in any flavor of NT/2K/XP (32 and
64). You could, of course, write instead:
void MyOutpd(USHORT address, ULONG data)
{
__asm {
mov dx,address
mov eax,data
outpd dx,eax
}
}
or use an intrinsic function _outpd(),
But then the driver would not pass compilation for AMD64 or IA64.
write a custom HAL for Windows. Not many custom HALs for NT are out there. I
know SGI did it, maybe HP.
If you're doing kernel drivers on Windows, you don't need asm.
WRITE_PORT_xxx and WRITE_REGISTER_xxx functions (which are exported from
HAL) are enough to read/write I/O ports in any flavor of NT/2K/XP (32 and
64). You could, of course, write instead:
void MyOutpd(USHORT address, ULONG data)
{
__asm {
mov dx,address
mov eax,data
outpd dx,eax
}
}
or use an intrinsic function _outpd(),
But then the driver would not pass compilation for AMD64 or IA64.
Y
Yousuf Khan
Keith R. Williams said:
Although it may not be necessary to use full-fledged assembly, even the C
code is a bit more architecture-specific when doing low-level stuff like
device drivers. Like you don't really have to take into account stuff like
endian orders when writing application code, but you often do when writing
low-level. Or you may have to adjust the size of an element in a structure
when converting from 32-bit to 64-bit. So yes, you can bit-bang with C, but
the C that comes out is not really the most portable.
Yousuf Khan
R
RusH
Keith R. Williams said:
key word : multiplatform
Pozdrawiam.
K
Keith R. Williams
Well, hell. Isn't it rather moronic to be discussing ASM vs.
&HLL. for "multi-platform" code? ...and very little software
really is "multi-platform".