On Thursday 01 September 2005 19:10, Grant Goodyear wrote: > The recent discussion about having a "real" x86 arch team and combining > the x86 and amd64 keywords was both interesting and provocative.
aha? Not in the list, is it?
> Of course, this is the sort of thing that the GLEP system was meant for.
> Now that we have a new council that (I hope) will be active in approving
> or rejecting GLEPs, perhaps someone should be writing a GLEP about
> combining x86 and amd64?
This just leads me to assume you're not really a coder (wrt native programming
languages like C/C++), are you?
I mean, x86 (32bit) and amd64 (64bit) ARE NOT THE SAME ARCH.
This is simply demonstrated by all those ugly pointer-to-integer conversions
that often happen when you write on your legacy x86 architecture.
However, when you try to compile it on an amd64 e.g., you just can't as gcc
WILL bail out.
Having now a x86amd64-alike keyword instead of x86 and amd64 will just make
lots of user's emerge experiences pain ass.
Of course, OTOH, while our bugs db gets flooded with reports, this *could* be
a startup for us to know *what* packages needs fixing. But that way, we would
be jast far off enterprise.
Here's an example that works on x86 but *not* an amd64:
// g++ -o test32vs64bit test32vs64bit.cpp
#include <cstdlib>
int main() {
void *p = NULL;
unsigned u = (unsigned)p; // ok on x86; error on amd64
p = (void *)u; // ok on x86; error on amd64
return 0;
}
Of course, you might think WTF do some guy need this, but hey, programmers are
really creative, and use what the compiler accepts - I myself ran into this
while porting my apps/libs to amd64. And think of it, not everybody has the
money to grab one.
Congrats,
Christian Parpart.
pgpKwfrGKm0Ue.pgp
Description: PGP signature
