Interesting read about upcoming K9 processors

"Ken Hagan" wrote in message ...
Regarding Microsoft's decision to keep "long" at 32-bits for Win64...


Tim Shoppa wrote:

Many of us have been working with 64-bit desktop CPU's, OS's, and C
compilers for over a decade now. Yeah, there are decisions to be
made.
This was hardly the first time this particular decision was made that
way.

Ah, then I've just benefitted from the venerable maxim that the fastest
way to learn anything is to post wrong information to Usenet. I was
under the impression that everyone else had jumped the other way on this
one.

Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
(and 64-bit long longs).

Some will interpret Microsoft's decision to use 32-bit longs as evidence
that DEC/Cutler's influence in Alpha NT still lingers. But there are other
valid reasons to choose it (many of them related to portability under
an established set of coding rules).

I am also under the impression that sticking to 32 bits hasn't actually
helped MS achieve their aims of source portability, since the rules on
MSDN suggest *very* strongly to me that all client code has to be
re-written to use their silly typedefs (like INT_PTR and LONG_PTR) in
any case.

C has always been a basket case with respect to integer sizes. Until
recently you had to choose someone's silly typedefs or choose to
chart your own course. The new standards do help... but only if you use
them.

Tim.

Tim Shoppa wrote:

(snip)

Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
(and 64-bit long longs).

I thought it was 32 bit int and 64 bit long. It broke a lot of
programs expecting 32 bit longs. I presume you mean OSF1.
There was (and is) also Alpha/VMS which may have had 32 bit long,
but I don't remember that long long even existed at the time.

Some will interpret Microsoft's decision to use 32-bit longs as evidence
that DEC/Cutler's influence in Alpha NT still lingers. But there are other
valid reasons to choose it (many of them related to portability under
an established set of coding rules).

-- glen

In article ,
Tim Shoppa wrote:

Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
(and 64-bit long longs).

Are you SURE? I am pretty sure that I investigated that, and found
it to be an urban myth. Yes, there is such a mode, but the normal
one is I32LP64, just like any sane system.

Some will interpret Microsoft's decision to use 32-bit longs as evidence
that DEC/Cutler's influence in Alpha NT still lingers. But there are other
valid reasons to choose it (many of them related to portability under
an established set of coding rules).

The first statement is doubtful. When it was claimed, a lot of people
provided evidence that it was an aberrant decision, and that Microsoft
compilers more often used I32LP64 than IL32LLP64.

The second statement is wrong. I am the person who investigated that,
and all of the actual evidence is that the portability problems caused
by IL32LLP64 are FAR greater than those caused by I32LP64. While I did
not investigate Microsoft's code, I did inspect the relevant coding
standards, and the problems my investigation detected would have arisen
as much in that as in the programs I did look at.

I am also under the impression that sticking to 32 bits hasn't actually
helped MS achieve their aims of source portability, since the rules on
MSDN suggest *very* strongly to me that all client code has to be
re-written to use their silly typedefs (like INT_PTR and LONG_PTR) in
any case.

C has always been a basket case with respect to integer sizes. Until
recently you had to choose someone's silly typedefs or choose to
chart your own course. The new standards do help... but only if you use
them.

They do help - but only if you are not interested in serious (i.e.
long-term and widespread) portability! If you are, C99 is a disaster,
where C90 was merely a basket case.

The point is that, for such portability, you need to choose sizes by
PROPERTY not bit count. I.e. "The smallest signed integer type that
can address the largest allocatable object" or "the smallest integer
type that can hold A_INT_T_MAX*A_INT_T_MAX".

Now, making float.h usable by the preprocessor and the new symbols
for the limits DOES help, but the ghastly bit-count sizes are quite
useless. Despite repeated claims, nobody has ever produced evidence
that they help competent programmers - though I do agree that they
do help bozos.

The claim that they help with networking and other interfaces is
completely bogus, as they don't specify endianness (or some other
critical properties in some cases). Nor do structures specify
padding and alignment. So portable programs STILL have to do their
own packing.


Regards,
Nick Maclaren.

(Nick Maclaren) wrote in message ...
In article ,
Tim Shoppa wrote:

Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
(and 64-bit long longs).

Are you SURE? I am pretty sure that I investigated that, and found
it to be an urban myth. Yes, there is such a mode, but the normal
one is I32LP64, just like any sane system.

DEC C V6.0-001 (which was rather current as of late 1998) under Alpha VMS 7.2:

$ type junk.c
#include stdio.h
main () {
int x;
long y;
long long z;
printf("int is %d bytes,long is %d bytes, long long is %d bytes\n",
sizeof(x),sizeof(y),sizeof(z));
}
$ cc junk.c
$ link junk
$ run junk
int is 4 bytes,long is 4 bytes, long long is 8 bytes

The compiler has a whole array of switches for changing default sizes,
not just of various int and float types, but also of the pointers.

Some will interpret Microsoft's decision to use 32-bit longs as evidence
that DEC/Cutler's influence in Alpha NT still lingers. But there are other
valid reasons to choose it (many of them related to portability under
an established set of coding rules).

The first statement is doubtful. When it was claimed, a lot of people
provided evidence that it was an aberrant decision, and that Microsoft
compilers more often used I32LP64 than IL32LLP64.

The second statement is wrong. I am the person who investigated that,
and all of the actual evidence is that the portability problems caused
by IL32LLP64 are FAR greater than those caused by I32LP64. While I did
not investigate Microsoft's code, I did inspect the relevant coding
standards, and the problems my investigation detected would have arisen
as much in that as in the programs I did look at.

I'm not really trying to defend those choices. Just pointing out that
similar choices were made over a decade ago. And that I kinda understand
why those choices were made (I was porting hundreds of thousands of lines
of C code written in the "all the world's a VAX" mode, and the defaults
made sense to *me*!) But I agree that they are not the most natural
choices if you know the whole world's moving (or in my case, has moved)
to 64 bit CPU's and OS's.

Keep in mind that in Alpha assembler-talk, a "word" is 16 bits and a "longword"
is 32 bits. The "quadword" is 64 bits. Yes, the first two are
anachronisms from PDP-11 days. Again, I'm not defending those choices,
I'm just pointing out that they were made before and will be made again
despite how strongly we feel they are anachronisms.

Tim.

Yousuf Khan wrote:
Ed wrote:
Hey, is Windows "Longhorn" gonna be for x86-64 CPU?
Ed

Current rumours are that, that's all it's going to be for. You won't
be able to run it on anything less than a 64-bit machine.

Yousuf Khan

Links?

--
Derek

"George Macdonald" wrote in message
...
On Tue, 27 Jul 2004 18:15:24 -0400, "Carlo Razzeto"
wrote:


SNIP
That readjustment, which also included raised prices for a cpuple of
models, was on Monday and I'm going by prices paid for recent "shopping".
The price *has* been holding quite well for AMD64 CPUs compared with their
historical curves and even Intel's - even at the old higher prices, they
were definitely in quite tight supply.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who,
me??

Yeah, but I think this still show that they are starting to ramp up. What
this price adjustment shows me is that they are ready to take A64 into the
main stream market (by this I mean the mid-range pc market of course). Prior
to this price adjustment even the "low end" A64's were considered to be
parts reserved for highend/enthusiest boxes... Now the prices are low enough
that just last friday I got around to buying an A64 3000+ and a fairly nice
Chaintech board to go with it.

Carlo

On Fri, 30 Jul 2004 05:23:57 +0000, Dean Kent wrote:

"Keith" wrote in message
news

Ah, so we have another conspiracy theory. So you're on the "incompetence"
side?

Some things are designed to be easily portable (such as DB2, perhaps?),
while others are not. The incompetence does not have to be with today's
coders, but could be due to yesterday's designers...

I surely *hope* M$'s architects learned something from OS/2 days. NT was
a complete re-write and one would suspect that they learned a few lessons
along the way.

--
Keith

In article ,
Tim Shoppa wrote:

DEC C V6.0-001 (which was rather current as of late 1998) under Alpha VMS 7.2:

I remember now (and have just got a colleague to check). Yes, VMS
uses that model, but Tru64 uses the normal I32LP64 one. As far as I
know, the sum total of C compilers on systems that anyone normal has
ever heard of that use IL32LLP64 is two, and both of those are relics
(i.e. I believe that Microsoft's future direction is I32LP64).

I'm not really trying to defend those choices. Just pointing out that
similar choices were made over a decade ago. And that I kinda understand
why those choices were made (I was porting hundreds of thousands of lines
of C code written in the "all the world's a VAX" mode, and the defaults
made sense to *me*!) But I agree that they are not the most natural
choices if you know the whole world's moving (or in my case, has moved)
to 64 bit CPU's and OS's.

Oh, I am not arguing with DEC's VMS choice - not at all - what I am
referring to is the decision to break all of the working C90 code
to support an essentially unused option. And the fact that the
claim that it was necessary to do so to avoid breaking existing
code was the CONVERSE of the truth.


Regards,
Nick Maclaren.

"Keith" wrote in message
news
On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:

"Russell Wallace" wrote in message
...

I agree with the others here. Force the issue by eliminating those who
won't convert. It seems Linux has done a reasonable job of supporting
AMD64 *without* all the resources M$ can bring to bare.

SNIP
--
Keith

Define "support"? Linux has the advantage that it is still not for the
average home user so they lose compaibility with old apps and old hardware
and not care because the people running 64big Linux on AMD64 won't care.
Windows on the other hand doesn't that advantage. If they don't have at
least 95% support for everything XP supports at launch it's a real issue for
Microsoft.

Carlo

Carlo Razzeto wrote:

[SNIP]

Define "support"? Linux has the advantage that it is still not for the
average home user so they lose compaibility with old apps and old hardware
and not care because the people running 64big Linux on AMD64 won't care.

That is not true. Besides if it *were* true, Microsoft have done all
this and got the T-Shirt with IA-64 already, surely... Linux has too.

Windows on the other hand doesn't that advantage. If they don't have at
least 95% support for everything XP supports at launch it's a real issue for
Microsoft.

MS has no excuse, they've had well over a decade to get this right
during which they have had considerable clout over the hardware vendors
and they have a *lot* more resource to throw at the problem that the
Linux bods ($$$ for specialist dev. platforms etc).


Cheers,
Rupert