Prescott with 64-bit extensions coming in June

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

http://www.infoworld.com/article/04/05/13/HNprescott_1.html

So what's all expected for Q3 now?
- 64-bit extensions
- 1066 MHz Bus
- 3.73 MHz Prescott/Dothan?
- Grantsdale/Alderwood chipset with PCI Express

How about on-board Firewire 800 and SATA-II?

Still no XP2...
53 answers Last reply
More about prescott extensions coming june
  1. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd wrote:
    > http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    >
    > So what's all expected for Q3 now?
    > - 64-bit extensions
    > - 1066 MHz Bus
    > - 3.73 MHz Prescott/Dothan?
    > - Grantsdale/Alderwood chipset with PCI Express
    >
    > How about on-board Firewire 800 and SATA-II?
    >
    > Still no XP2...

    That's funny, according to the article:

    <quote>
    Prescott supports the NX (no execute) feature that will prevent worms and
    viruses from executing dangerous code through the exploitation of buffer
    overflows, Otellini said during a Webcast of the event. Advanced Micro
    Devices Inc.'s Athlon 64 and Opteron processors also come with this feature,
    which requires software support from Microsoft Corp.'s Windows XP Service
    Pack 2 expected later this year.
    </quote>

    As of the original release of the EM64T documentation, Intel didn't yet
    support the NX bit. That was one of the most glaring ommisions from an
    otherwise perfect copy job of the AMD64 specs. Has this oversight now been
    corrected, or is the article writer just assuming things here?

    Yousuf Khan
  2. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <news.20.bbbl67@spamgourmet.com> wrote in message
    news:ykVoc.22695$mP11.1408@news04.bloor.is.net.cable.rogers.com...
    > Judd wrote:
    > > http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    > >
    > > So what's all expected for Q3 now?
    > > - 64-bit extensions
    > > - 1066 MHz Bus
    > > - 3.73 MHz Prescott/Dothan?
    > > - Grantsdale/Alderwood chipset with PCI Express
    > >
    > > How about on-board Firewire 800 and SATA-II?
    > >
    > > Still no XP2...
    >
    > That's funny, according to the article:
    >
    > <quote>
    > Prescott supports the NX (no execute) feature that will prevent worms and
    > viruses from executing dangerous code through the exploitation of buffer
    > overflows, Otellini said during a Webcast of the event. Advanced Micro
    > Devices Inc.'s Athlon 64 and Opteron processors also come with this
    feature,
    > which requires software support from Microsoft Corp.'s Windows XP Service
    > Pack 2 expected later this year.
    > </quote>
    >
    > As of the original release of the EM64T documentation, Intel didn't yet
    > support the NX bit. That was one of the most glaring ommisions from an
    > otherwise perfect copy job of the AMD64 specs. Has this oversight now been
    > corrected, or is the article writer just assuming things here?
    >

    I was hoping you saw that. I assumed Otellini told them it supported NX and
    that, yes, the new Prescott steppings would support the addition (couldn't
    have been that difficult to implement). I assume Intel doesn't want to get
    bullet pointed out on a feature that analyst and ragazines would promote as
    the next best thing since sliced bread. They've already given in this far.
    Still, there seems to be a rather large number of near future offerings from
    Intel that really weren't expected at this point. This might be a much more
    interesting year for PCs than previously anticipated.
  3. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd wrote:
    > "Yousuf Khan" <news.20.bbbl67@spamgourmet.com> wrote in message
    >> As of the original release of the EM64T documentation, Intel didn't
    >> yet support the NX bit. That was one of the most glaring ommisions
    >> from an otherwise perfect copy job of the AMD64 specs. Has this
    >> oversight now been corrected, or is the article writer just assuming
    >> things here?
    >>
    >
    > I was hoping you saw that. I assumed Otellini told them it supported
    > NX and that, yes, the new Prescott steppings would support the
    > addition (couldn't have been that difficult to implement). I assume
    > Intel doesn't want to get bullet pointed out on a feature that
    > analyst and ragazines would promote as the next best thing since
    > sliced bread. They've already given in this far. Still, there seems
    > to be a rather large number of near future offerings from Intel that
    > really weren't expected at this point. This might be a much more
    > interesting year for PCs than previously anticipated.

    Yeah, it can't be that difficult to implement. Just wonder if Intel's
    documentation writers have updated their PDF's yet. I'm going to have to
    maintain a CVS repository of Intel PDFs at this rate. :-)

    Yousuf Khan
  4. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <news.20.bbbl67@spamgourmet.com> wrote in message
    news:JiWoc.22854$mP11.18537@news04.bloor.is.net.cable.rogers.com...
    > Judd wrote:
    > Yeah, it can't be that difficult to implement. Just wonder if Intel's
    > documentation writers have updated their PDF's yet. I'm going to have to
    > maintain a CVS repository of Intel PDFs at this rate. :-)
    >
    > Yousuf Khan

    Are you sure that will help? Having delt with CVS quite a bit at work I know
    how easy it is to make things a mess in CVS, especially when you need to
    start branching as much as you would with Intels road maps as of late.

    Carlo
  5. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Yousuf Khan wrote:
    > As of the original release of the EM64T documentation, Intel didn't yet
    > support the NX bit. That was one of the most glaring ommisions from an
    > otherwise perfect copy job of the AMD64 specs. Has this oversight now been
    > corrected, or is the article writer just assuming things here?

    My understanding (I am not near to this at all) is that the feature was
    always there but not adequately validated. Harken back to the
    Willamette and Northwood and Hyperthreading. Intel does put in optional
    features it wants and if they can't be tested by the deadline, "ship it
    anyway, we want a product on the market." In the next stepping they'll
    have had time to test thoroughly and will enable it. Remember the other
    thread: "Intel follows the margin"

    Alex
    --
    My words are my own. They represent no other; they belong to no other.
    Don't read anything into them or you may be required to compensate me
    for violation of copyright. (I do not speak for my employer.)
  6. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd wrote:

    > So what's all expected for Q3 now?
    > - 64-bit extensions
    > - 1066 MHz Bus
    > - 3.73 MHz Prescott/Dothan?

    How can you even think that Dothan would scale to > 3 GHz in 2004?
  7. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd wrote:

    > Yousuf Khan wrote:
    >
    >> As of the original release of the EM64T documentation, Intel
    >> didn't yet support the NX bit. That was one of the most glaring
    >> ommisions from an otherwise perfect copy job of the AMD64 specs.
    >> Has this oversight now been corrected, or is the article writer
    >> just assuming things here?
    >
    > I was hoping you saw that. I assumed Otellini told them it
    > supported NX and that, yes, the new Prescott steppings would
    > support the addition (couldn't have been that difficult to
    > implement). I assume Intel doesn't want to get bullet pointed out
    > on a feature that analyst and ragazines would promote as the next
    > best thing since sliced bread. They've already given in this far.

    Apparently, the OpenBSD crew was given IA32e processors to play with,
    which did not include the NX bit.

    http://www.openbsd.org/35.html

    Note: The upcoming Intel "ia32e" AMD64-compatible cpus have
    also been tested, and work, even though they lack the NX bit.

    As you say, maybe it's been corrected with a new core stepping.
  8. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Alex Johnson <compuwiz@acm.org> wrote:
    > Yousuf Khan wrote:
    >> As of the original release of the EM64T documentation, Intel didn't
    >> yet support the NX bit. That was one of the most glaring ommisions
    >> from an otherwise perfect copy job of the AMD64 specs. Has this
    >> oversight now been corrected, or is the article writer just assuming
    >> things here?
    >
    > My understanding (I am not near to this at all) is that the feature
    > was always there but not adequately validated. Harken back to the
    > Willamette and Northwood and Hyperthreading. Intel does put in
    > optional features it wants and if they can't be tested by the
    > deadline, "ship it anyway, we want a product on the market." In the
    > next stepping they'll have had time to test thoroughly and will
    > enable it. Remember the other thread: "Intel follows the margin"

    Yeah, but the whole EM64T stuff is not validated yet. It's an announcement
    about a future product that hasn't come out yet, and until recently they
    hadn't even put out an official date of arrival yet.

    What's the point in shipping something that is half-finished, when the
    fully-finished thing (AMD's product) already exists? It's like saying buy
    our car, even though it doesn't have windshield wipers. Sure it will work
    fine most of the time, except on the odd days when it rains.

    Yousuf Khan
  9. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd <IhateSpam@stopspam.com> wrote:
    > http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    >
    > So what's all expected for Q3 now?
    > - 3.73 MHz Prescott/Dothan?

    Oh, and no, Dothan obviously wouldn't run at 3.73 Ghz, but it might touch
    2.2 Ghz by Q3.

    Yousuf Khan
  10. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    news:mxepc.9715$0qd.6428@twister01.bloor.is.net.cable.rogers.com...
    > Judd <IhateSpam@stopspam.com> wrote:
    > > http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    > >
    > > So what's all expected for Q3 now?
    > > - 3.73 MHz Prescott/Dothan?
    >
    > Oh, and no, Dothan obviously wouldn't run at 3.73 Ghz, but it might touch
    > 2.2 Ghz by Q3.
    >

    So one would think, but recall the article I posted earlier about a 3.73
    Prescott CPU with a Dothan core? My guess is that the article is wrong and
    it's not Dothan, but it did raise an eyebrow :-)
  11. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Yousuf Khan wrote:

    > Judd wrote:
    >> http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    >>
    >> So what's all expected for Q3 now?
    >> - 64-bit extensions
    >> - 1066 MHz Bus
    >> - 3.73 MHz Prescott/Dothan?
    >> - Grantsdale/Alderwood chipset with PCI Express
    >>
    >> How about on-board Firewire 800 and SATA-II?
    >>
    >> Still no XP2...
    >
    > That's funny, according to the article:
    >
    > <quote>
    > Prescott supports the NX (no execute) feature that will prevent worms and
    > viruses from executing dangerous code through the exploitation of buffer
    > overflows, Otellini said during a Webcast of the event. Advanced Micro
    > Devices Inc.'s Athlon 64 and Opteron processors also come with this
    > feature, which requires software support from Microsoft Corp.'s Windows XP
    > Service Pack 2 expected later this year.
    > </quote>
    >
    > As of the original release of the EM64T documentation, Intel didn't yet
    > support the NX bit. That was one of the most glaring ommisions from an
    > otherwise perfect copy job of the AMD64 specs. Has this oversight now been
    > corrected, or is the article writer just assuming things here?
    >
    > Yousuf Khan

    So, do you mean to say that Intel & AMD are fixing Windows' Virus problems
    in the CPU hardware? I thought AMD and Intel were smarter than that. This
    reminds me of Compaq's attempt to fix an application bug by modifying their
    BIOS.
    Eric
  12. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Yousuf Khan wrote:

    > Judd wrote:
    >> http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    >>
    >> So what's all expected for Q3 now?
    >> - 64-bit extensions
    >> - 1066 MHz Bus
    >> - 3.73 MHz Prescott/Dothan?
    >> - Grantsdale/Alderwood chipset with PCI Express
    >>
    >> How about on-board Firewire 800 and SATA-II?
    >>
    >> Still no XP2...
    >
    > That's funny, according to the article:
    >
    > <quote>
    > Prescott supports the NX (no execute) feature that will prevent worms and
    > viruses from executing dangerous code through the exploitation of buffer
    > overflows, Otellini said during a Webcast of the event. Advanced Micro
    > Devices Inc.'s Athlon 64 and Opteron processors also come with this
    > feature, which requires software support from Microsoft Corp.'s Windows XP
    > Service Pack 2 expected later this year.
    > </quote>
    >
    > As of the original release of the EM64T documentation, Intel didn't yet
    > support the NX bit. That was one of the most glaring ommisions from an
    > otherwise perfect copy job of the AMD64 specs. Has this oversight now been
    > corrected, or is the article writer just assuming things here?
    >
    > Yousuf Khan
    After reading up on the NX bit I have this thought: Isnt that what
    segmentation is for? Cripe, start using Data segments and the buffer
    overflows will just fault.
    Eric
  13. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd <IhateSpam@stopspam.com> wrote:
    > "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    > news:mxepc.9715$0qd.6428@twister01.bloor.is.net.cable.rogers.com...
    >> Judd <IhateSpam@stopspam.com> wrote:
    >>> http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    >>>
    >>> So what's all expected for Q3 now?
    >>> - 3.73 MHz Prescott/Dothan?
    >>
    >> Oh, and no, Dothan obviously wouldn't run at 3.73 Ghz, but it might
    >> touch
    >> 2.2 Ghz by Q3.
    >>
    >
    > So one would think, but recall the article I posted earlier about a
    > 3.73 Prescott CPU with a Dothan core? My guess is that the article
    > is wrong and it's not Dothan, but it did raise an eyebrow :-)

    Which article? The one in the link above doesn't mention anything about the
    Dothan.

    Yousuf Khan
  14. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    Eric <nospam@email.com> wrote:
    >> That's funny, according to the article:
    >>
    >> <quote>
    >> Prescott supports the NX (no execute) feature that will prevent
    >> worms and viruses from executing dangerous code through the
    >> exploitation of buffer overflows, Otellini said during a Webcast of
    >> the event. Advanced Micro Devices Inc.'s Athlon 64 and Opteron
    >> processors also come with this feature, which requires software
    >> support from Microsoft Corp.'s Windows XP Service Pack 2 expected
    >> later this year. </quote>
    >>
    >> As of the original release of the EM64T documentation, Intel didn't
    >> yet support the NX bit. That was one of the most glaring ommisions
    >> from an otherwise perfect copy job of the AMD64 specs. Has this
    >> oversight now been corrected, or is the article writer just assuming
    >> things here?
    >>
    >> Yousuf Khan
    >
    > So, do you mean to say that Intel & AMD are fixing Windows' Virus
    > problems in the CPU hardware? I thought AMD and Intel were smarter
    > than that. This reminds me of Compaq's attempt to fix an application
    > bug by modifying their BIOS.
    > Eric

    Well, we're not exactly sure about Intel yet, but AMD is attempting to
    nullify one of the more common methods worms use against Windows. It's a
    relatively easy solution too, mostly transparent to the applications
    software; they just mark certain memory pages as data-only, code cannot be
    executed from those pages. That way if a buffer overflow exploit is employed
    against that program, the malicious code inserted sits in non-executable
    memory and goes nowhere.

    When Intel copied AMD's 64-bit specifications, it is assumed that they
    copied an older version of that spec, and that some of the more recent
    features that AMD put in, didn't get put in by Intel. The NX (no execute)
    bit in the page table was one of the ones not mentioned in Intel's
    documentation.

    Yousuf Khan
  15. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    Eric <nospam@email.com> wrote:
    > After reading up on the NX bit I have this thought: Isnt that what
    > segmentation is for? Cripe, start using Data segments and the buffer
    > overflows will just fault.
    > Eric

    Yeah, that was my original thought too, but for some reason segmentation has
    gotten a nasty reputation from its Real mode days, and OS companies from the
    beginning of the 32-bit era couldn't wait to stop using it, despite the fact
    that it had all of those advantages. Hell it could've even delayed the
    introduction of 64-bit computing another couple of years, if applications
    started to use multiple 4GB data segments. But that's only for historical
    interest now, segmentation has been removed from 64-bit mode.

    Yousuf Khan
  16. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Carlo Razzeto <crazzeto@hotmail.com> wrote:
    > "Yousuf Khan" <news.20.bbbl67@spamgourmet.com> wrote in message
    >> Yeah, it can't be that difficult to implement. Just wonder if Intel's
    >> documentation writers have updated their PDF's yet. I'm going to
    >> have to maintain a CVS repository of Intel PDFs at this rate. :-)
    >
    > Are you sure that will help? Having delt with CVS quite a bit at work
    > I know how easy it is to make things a mess in CVS, especially when
    > you need to start branching as much as you would with Intels road
    > maps as of late.

    I just downloaded those EM64T PDFs again -- they are exactly the same PDFs
    as the ones they released in February. They even still call them IA32E
    inside. So the PDFs haven't be updated. (Of course, that's not entirely
    surprising, documentation lags behind implementation in most places I've
    worked too.) :-)

    Yousuf Khan
  17. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    news:6vspc.28302$0qd.5215@twister01.bloor.is.net.cable.rogers.com...
    >
    > I just downloaded those EM64T PDFs again -- they are exactly the same PDFs
    > as the ones they released in February. They even still call them IA32E
    > inside. So the PDFs haven't be updated. (Of course, that's not entirely
    > surprising, documentation lags behind implementation in most places I've
    > worked too.) :-)
    >
    > Yousuf Khan
    >
    >

    You mean you actually had documentation at the places you worked? Must be
    nice, where I am it's do this project and figure out where you need to pull
    the data from on your own. Very annoying, getting easier since I've been
    with this company for a few months now, I'm actually getting familiar with
    some of their DBs, but it's still just a huge mess. Very fustrating
    experience.

    Carlo
  18. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sat, 15 May 2004 14:33:32 GMT, Eric <nospam@email.com> wrote:
    >Yousuf Khan wrote:
    >> <quote>
    >> Prescott supports the NX (no execute) feature that will prevent worms and
    >> viruses from executing dangerous code through the exploitation of buffer
    >> overflows, Otellini said during a Webcast of the event. Advanced Micro
    >> Devices Inc.'s Athlon 64 and Opteron processors also come with this
    >> feature, which requires software support from Microsoft Corp.'s Windows XP
    >> Service Pack 2 expected later this year.
    >> </quote>
    >>
    >> As of the original release of the EM64T documentation, Intel didn't yet
    >> support the NX bit. That was one of the most glaring ommisions from an
    >> otherwise perfect copy job of the AMD64 specs. Has this oversight now been
    >> corrected, or is the article writer just assuming things here?
    >
    >So, do you mean to say that Intel & AMD are fixing Windows' Virus problems
    >in the CPU hardware? I thought AMD and Intel were smarter than that. This
    >reminds me of Compaq's attempt to fix an application bug by modifying their
    >BIOS.

    It's not exactly that, it's more adding in a feature to the processor
    that SHOULD have been there ages ago. Such functionality is common in
    many non-x86 chips, but was implemented in a rather bass-ackwards way
    in current x86 chips.

    It's not going to fix the Windows virus problem. In fact, it won't
    affect actual *virus* programs at all, though it should really help
    with *worm* programs, the difference between the two is often lost in
    the mainstream media these days. It offers Microsoft (and others)
    another tool to try and mitigate (though not eliminate) security
    risks.

    FWIW while it is popular to attack Microsoft for their rather, umm..
    questionable decisions regarding security, they do seem to have seen
    the light of day. Take a look at WinXP SP2 sometime, and you'll see
    that they are making a LOT of changes that should significantly
    improve security. I'm not just talking about patching bugs here or
    anything, this is a fundamental change in philosophy.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  19. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sat, 15 May 2004 21:59:40 -0400, Tony Hill
    <hilla_nospam_20@yahoo.ca> wrote:

    >It's not going to fix the Windows virus problem. In fact, it won't
    >affect actual *virus* programs at all, though it should really help
    >with *worm* programs, the difference between the two is often lost in
    >the mainstream media these days.

    When was the last virus anyway? All that they seem to be making these
    days are worms and trojans.

    --
    L.Angel: I'm looking for web design work.
    If you need basic to med complexity webpages at affordable rates, email me :)
    Standard HTML, SHTML, MySQL + PHP or ASP, Javascript.
    If you really want, FrontPage & DreamWeaver too.
    But keep in mind you pay extra bandwidth for their bloated code
  20. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    In article <40a80d95.113417125@news.pacific.net.sg>, a?n?g?e?
    l@lovergirl.lrigrevol.moc.com says...
    > On Sat, 15 May 2004 21:59:40 -0400, Tony Hill
    > <hilla_nospam_20@yahoo.ca> wrote:
    >
    > >It's not going to fix the Windows virus problem. In fact, it won't
    > >affect actual *virus* programs at all, though it should really help
    > >with *worm* programs, the difference between the two is often lost in
    > >the mainstream media these days.
    >
    > When was the last virus anyway?

    A week ago. It played hell with the network at work.

    > All that they seem to be making these
    > days are worms and trojans.

    Education (and eliminating M$ software) can help much here.
    NOthing helps if the OS allows free access to everything.

    --
    KEith
  21. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd wrote:

    > Try reading what I wrote again please. I CLEARLY said "almost nothing "...
    > as in not nothing but hardly the large installed base of the 32-bit
    > applications. Meaning, few consumers are going to jump on it for the sole
    > reason of it being 64-bit.

    Oh come on, you know how consumers behave a lot better than
    that paragraph indicates. Consumers will buy 64 bit simply
    because that it the latest buzzword. Their understanding,
    or lack thereof, of what "64 bit" is all about is irrelevant.

    Its just like when consumers started switching to Windows from
    DOS even though there were no decent Windows apps yet. All
    they understood was that "GUI" was the coming thing and they
    wanted to jump on the bandwagon before it was fully assembled.
    (And they drove me nuts because the all felt they had to
    demonstrate to me that they knew it was supposed to be pronounced
    "gwee" for some stupid reason or another. I resolutely stuck
    with saying G.U.I.)

    The most important equation in marketing is
    consumer = lemming
  22. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    Tony Hill <hilla_nospam_20@yahoo.ca> wrote:

    > Take a look at WinXP SP2 sometime, and you'll see
    >that they are making a LOT of changes that should significantly
    >improve security. I'm not just talking about patching bugs here or
    >anything, this is a fundamental change in philosophy.

    Are they stopping the stupid practice of hiding file extensions by
    default?
  23. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Rob Stow" <rob.stow@sasktel.net> wrote in message
    news:10ahdv89cjmhi06@corp.supernews.com...
    > Judd wrote:
    >
    > > Try reading what I wrote again please. I CLEARLY said "almost nothing
    "...
    > > as in not nothing but hardly the large installed base of the 32-bit
    > > applications. Meaning, few consumers are going to jump on it for the
    sole
    > > reason of it being 64-bit.
    >
    > Oh come on, you know how consumers behave a lot better than
    > that paragraph indicates. Consumers will buy 64 bit simply
    > because that it the latest buzzword. Their understanding,
    > or lack thereof, of what "64 bit" is all about is irrelevant.
    >
    > Its just like when consumers started switching to Windows from
    > DOS even though there were no decent Windows apps yet. All
    > they understood was that "GUI" was the coming thing and they
    > wanted to jump on the bandwagon before it was fully assembled.
    > (And they drove me nuts because the all felt they had to
    > demonstrate to me that they knew it was supposed to be pronounced
    > "gwee" for some stupid reason or another. I resolutely stuck
    > with saying G.U.I.)
    >
    > The most important equation in marketing is
    > consumer = lemming

    You are no different than George. Reread what I said. The WHOLE thing.
    You'll notice that I agree with you. They'll buy it because it's the
    latest, but not JUST FOR 64-bit because little exists for 64-bit. It's more
    marketing than useful is my point.
  24. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sun, 16 May 2004 22:34:12 -0400, KR Williams <krw@att.biz> wrote:

    >> When was the last virus anyway?
    >
    >A week ago. It played hell with the network at work.

    What was it? Sasser? Sorry, I've not been paying much attention to
    viruses for years... :PpPpP

    --
    L.Angel: I'm looking for web design work.
    If you need basic to med complexity webpages at affordable rates, email me :)
    Standard HTML, SHTML, MySQL + PHP or ASP, Javascript.
    If you really want, FrontPage & DreamWeaver too.
    But keep in mind you pay extra bandwidth for their bloated code
  25. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Rob Stow" <rob.stow@sasktel.net> wrote in message
    news:10ahdv89cjmhi06@corp.supernews.com...
    > Judd wrote:
    >
    > > Try reading what I wrote again please. I CLEARLY said "almost nothing
    "...
    > > as in not nothing but hardly the large installed base of the 32-bit
    > > applications. Meaning, few consumers are going to jump on it for the
    sole
    > > reason of it being 64-bit.
    >
    > Oh come on, you know how consumers behave a lot better than
    > that paragraph indicates. Consumers will buy 64 bit simply
    > because that it the latest buzzword. Their understanding,
    > or lack thereof, of what "64 bit" is all about is irrelevant.
    >
    > Its just like when consumers started switching to Windows from
    > DOS even though there were no decent Windows apps yet. All
    > they understood was that "GUI" was the coming thing and they
    > wanted to jump on the bandwagon before it was fully assembled.
    > (And they drove me nuts because the all felt they had to
    > demonstrate to me that they knew it was supposed to be pronounced
    > "gwee" for some stupid reason or another. I resolutely stuck
    > with saying G.U.I.)
    >
    > The most important equation in marketing is
    > consumer = lemming

    no marketing = people start dancing circles around the globe, white doves
    fly away with little olive branches....
  26. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Sun, 16 May 2004 22:34:12 -0400, KR Williams <krw@att.biz> wrote:
    >In article <40a80d95.113417125@news.pacific.net.sg>, a?n?g?e?
    >l@lovergirl.lrigrevol.moc.com says...
    >> On Sat, 15 May 2004 21:59:40 -0400, Tony Hill
    >> <hilla_nospam_20@yahoo.ca> wrote:
    >>
    >> >It's not going to fix the Windows virus problem. In fact, it won't
    >> >affect actual *virus* programs at all, though it should really help
    >> >with *worm* programs, the difference between the two is often lost in
    >> >the mainstream media these days.
    >>
    >> When was the last virus anyway?
    >
    >A week ago. It played hell with the network at work.

    If you're talking about Sasser, that actually kind of proves L.Angel's
    point. Sasser was a worm, not a virus (not that it makes it any
    better or anything!).

    >> All that they seem to be making these
    >> days are worms and trojans.
    >
    >Education (and eliminating M$ software) can help much here.
    >NOthing helps if the OS allows free access to everything.

    As I've mentioned before, WinXP SP2 should make a bit difference on
    this.. at least for those who end up using it. This should be a
    fairly major step forward in terms of Windows security, MUCH more so
    than any of the previous baby steps.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  27. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Mon, 17 May 2004 11:42:49 -0600, "Judd" <IhateSpam@stopspam.com> wrote:

    >
    >"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
    >news:cm0ha0dmjtfi883rsl4o4g9asr8b615qiq@4ax.com...

    >> >> "Nothing has been built" is hardly accurate. Windows XP-64 for x86-64
    >has
    >> >> been built for a while now - M$ is either having trouble with
    >validation
    >> >or
    >> >> waiting for Intel (Godo ?). It is available as part of the MSDN prog.
    >> >> which every Win-software house subcribes to. Linux is already
    >available
    >> >> and the Oracle port was completed in 2-3 days according to them.
    >> >>
    >> >
    >> >Try reading what I wrote again please. I CLEARLY said "almost nothing
    >"...
    >> >as in not nothing but hardly the large installed base of the 32-bit
    >> >applications. Meaning, few consumers are going to jump on it for the
    >sole
    >> >reason of it being 64-bit. They'll be more compelled when there are more
    >> >programs out to exploit the architecture. Beta software is hardly the
    >> >answer. That's why there's no rush to put it out other than for
    >marketing
    >> >purposes.
    >>
    >> Even your "almost" does not cover it and is still presumptious to say the
    >> least: game makers are certainly showing great interest in AMD64 and it's
    >> hard to tell how many other software vendors are taking the plunge... the
    >> tools are available - call them beta if it pleases you but clearly they
    >are
    >> not and even "beta" does not mean not built. You said: "Until MS builds
    >it
    >> OS for 64-bit"... uhh, this part was done a while back.
    >>
    >
    >Your idea of software is vapor. Few would agree with such an asanine
    >statement.

    Ah someone who speaks for the uhh, many?? The only thing asinine here is
    your slavish nodding to the i-Dogma. Windows XP-64 is a damned sight more
    than vapor - delude yourself if you wish.

    >> As for "consumer" interest, I believe you could be in for a *big*
    >surprise
    >> - given expectations of the lifetime of a system (my current one is 5.5
    >> year old and I'm looking to upgrade now) I personally would not consider a
    >> 32-bit limited system right now... especially since any additional cost is
    >> piddling.
    >>
    >
    >Average system turnaround is ~2.5 years (3 years for home 2 for corporate).
    >We're not talking about you in particular. I personally try to make my
    >systems last and will be waiting for 64-bit for future consideration. Most
    >would do very fine at 32-bit right now since by the time they get around to
    >buying systems again in 2006, there would be enough support for 64-bit to
    >make it a feasible investment. 32-bit will be cheaper, just as fast for the
    >most part, and work just fine for the tasks that they perform.

    No - it's not cheaper at all, if you look at the current offerings even two
    slots down from the top of the line. You appear not to have been paying
    attention to the recent 4.5year slump following the 2K panic: 2 years for
    corporate is absurd as a general rule - unless maybe for a small portion of
    the top workstations... which is in fact a major sector clamoring for
    64-bit. From my POV I don't see them taking less. Even the home sector is
    largely an upgrade market now and I believe they'll be very careful what
    they lay out their money on. I'll certainly advise anyone who asks to buy
    the 64-bit now - no waiting is required.;-)

    >> >> As for Intel specifically, they'd better be very careful how they
    >position
    >> >> their EM64T. If they try to segment it too agressively into
    >"high-end",
    >> >> they could stub their toes.
    >> >
    >> >True, but it's Intel... they'll be fine on that end.
    >>
    >> <GULP> Segmentation is Intel's favorite game - always has been and they
    >> still practice it. They've announced their EM64T as for servers and
    >> workstations only - seems quite clear to me where they want to take the
    >> market.
    >>
    >
    >Huh? They've said that in 2005 nearly all would be EM64T as well as dual
    >core. Next month they are releasing products for workstation and server
    >only because why do they need to sell it to the consumer (see reasons
    >above).

    The upgrade consumer is wiser now - tasks are tangibly increasing in
    complexity and expectations are high. Once they grasp the fact of the
    64-bit address canard and appreciate the real improvement of the new ISA
    and register files, the penny will drop!

    We'll see what Intel does with their segmentation model but dual core will
    not be here until rather late in 2005. Fortunately for them, when they
    wake up, the software willl be in place... or further along than if
    everyone had waited for an edict from "i".

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  28. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    >
    > Not so, there are existing applications which are already running out of
    > address space when they mmap() large files. This is a technique which is
    > a big win if you have a bunch of processes sharing a file, although it
    > makes little difference over file i/o if you have a single process and
    > don't have all the flushing and locking issues.
    >

    Other than server DB and some large image processing programs, what other
    programs are doing this? I have found this to be rarity thus the exception
    and not the norm.
  29. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    > Ah someone who speaks for the uhh, many?? The only thing asinine here is
    > your slavish nodding to the i-Dogma. Windows XP-64 is a damned sight more
    > than vapor - delude yourself if you wish.

    No, it's vapor. Until it's on the shelves of CompUSA and prepackaged from
    vendors, it's vapor. Your statements would be considered wholly dishonest
    from the consumer POV.

    > >Average system turnaround is ~2.5 years (3 years for home 2 for
    corporate).
    > >We're not talking about you in particular. I personally try to make my
    > >systems last and will be waiting for 64-bit for future consideration.
    Most
    > >would do very fine at 32-bit right now since by the time they get around
    to
    > >buying systems again in 2006, there would be enough support for 64-bit to
    > >make it a feasible investment. 32-bit will be cheaper, just as fast for
    the
    > >most part, and work just fine for the tasks that they perform.
    >
    > No - it's not cheaper at all, if you look at the current offerings even
    two
    > slots down from the top of the line. You appear not to have been paying
    > attention to the recent 4.5year slump following the 2K panic: 2 years for
    > corporate is absurd as a general rule - unless maybe for a small portion
    of
    > the top workstations... which is in fact a major sector clamoring for
    > 64-bit. From my POV I don't see them taking less. Even the home sector
    is
    > largely an upgrade market now and I believe they'll be very careful what
    > they lay out their money on. I'll certainly advise anyone who asks to buy
    > the 64-bit now - no waiting is required.;-)

    You bet it's cheaper! Intel in comparison to AMD is not cheaper, but when
    Intel releases 64-bit products, the 32-bit products will be cheaper (prices
    slashed, etc.). You are comparing apples to apples.

    > >Huh? They've said that in 2005 nearly all would be EM64T as well as dual
    > >core. Next month they are releasing products for workstation and server
    > >only because why do they need to sell it to the consumer (see reasons
    > >above).
    >
    > The upgrade consumer is wiser now - tasks are tangibly increasing in
    > complexity and expectations are high. Once they grasp the fact of the
    > 64-bit address canard and appreciate the real improvement of the new ISA
    > and register files, the penny will drop!
    >

    Uh, the average consumer doesn't know jack. This is why marketing is so
    important. They don't care so long as it sounds good ("That thang got a
    hemi!") and runs their software better. You are using your considerable
    intelligence of computers as a benchmark for what others know. I'm just
    letting you know that it's unrealistic.

    > We'll see what Intel does with their segmentation model but dual core will
    > not be here until rather late in 2005. Fortunately for them, when they
    > wake up, the software willl be in place... or further along than if
    > everyone had waited for an edict from "i".
    >

    I don't know when dual core will get here. They surprised the heck out of
    me with the release announcement of the EM64T. I figured that was 2005 at
    the earliest. Funny how things change. If AMD is pushing dual core, then
    Intel will release it earlier than you expect.
  30. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    Eric wrote:

    > After reading up on the NX bit I have this thought: Isnt that what
    > segmentation is for? Cripe, start using Data segments and the buffer
    > overflows will just fault.

    Think about the overhead of resetting the segment register before using
    each memory access. Does that sound like a practical thing? Segments
    protect processes from one another, not a process from itself.

    Google for info on how the original MULTICS hardware worked.

    --
    bill davidsen (davidsen@darkstar.prodigy.com)
    SBC/Prodigy Yorktown Heights NY data center
    Project Leader, USENET news
    http://newsgroups.news.prodigy.com
  31. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd <IhateSpam@stopspam.com> wrote:
    > I don't know when dual core will get here. They surprised the heck
    > out of me with the release announcement of the EM64T. I figured that
    > was 2005 at the earliest. Funny how things change. If AMD is
    > pushing dual core, then Intel will release it earlier than you expect.

    Basically what Intel has announced is that they will bring out 64-bit P4
    desktop chips at the same time that they introduce their Nocona
    dual-processor Xeon server chips. So Nocona and Prescott 64-bit will come
    out at the same time, instead of at different times.

    Yousuf Khan
  32. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd <IhateSpam@stopspam.com> wrote:
    >> Not so, there are existing applications which are already running
    >> out of address space when they mmap() large files. This is a
    >> technique which is a big win if you have a bunch of processes
    >> sharing a file, although it makes little difference over file i/o if
    >> you have a single process and don't have all the flushing and
    >> locking issues.
    >>
    >
    > Other than server DB and some large image processing programs, what
    > other programs are doing this? I have found this to be rarity thus
    > the exception and not the norm.

    I would assume this would become more of the norm rather than the exception
    once 64-bit is entrenched. There are big advantages to accessing files with
    a mmap function rather than the traditional file i/o functions. Not the
    least of which is that accessing mmapped files is just like accessing
    memory, and secondly you bypass having to do a context switch to the kernel
    at several levels.

    Yousuf Khan
  33. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    Bill Davidsen <davidsen@darkstar.prodigy.com> wrote:
    >> After reading up on the NX bit I have this thought: Isnt that what
    >> segmentation is for? Cripe, start using Data segments and the buffer
    >> overflows will just fault.
    >
    > Think about the overhead of resetting the segment register before
    > using each memory access. Does that sound like a practical thing?
    > Segments protect processes from one another, not a process from
    > itself.

    No, segments could save processes from themselves too. There are separate
    code and data segments.

    Why would you need to reset the segment register for every memory access?
    The data segment would be cached in the DS register, the code in CS
    register, and the stack in the SS, plus two extra DS-like segment registers
    in the form of ES and FS.

    Yousuf Khan
  34. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Carlo Razzeto wrote:
    >
    >
    > You mean you actually had documentation at the places you worked? Must be
    > nice, where I am it's do this project and figure out where you need to pull
    > the data from on your own. Very annoying, getting easier since I've been
    > with this company for a few months now, I'm actually getting familiar with
    > some of their DBs, but it's still just a huge mess. Very fustrating
    > experience.
    >
    > Carlo
    >
    >

    Format the whole thing and tell the management a Win32 worm ate the
    thing up.
  35. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    On Mon, 17 May 2004 23:53:38 -0400, KR Williams <krw@att.biz> wrote:
    >In article <raqia0lmpp67sf805s7gvfcifkobq4pjjt@4ax.com>,
    >hilla_nospam_20@yahoo.ca says...
    >> As I've mentioned before, WinXP SP2 should make a bit difference on
    >> this.. at least for those who end up using it. This should be a
    >> fairly major step forward in terms of Windows security, MUCH more so
    >> than any of the previous baby steps.
    >
    >There is no way I'm moving to WinXP, much less SP2. At home I've
    >stopped with Win2K SP2 and will go no further. At work I'm
    >required to have SP4. It's their machine, they can do what they
    >wish with it. I'm not agreeing to be a M$uck slave though.

    The important thing though is that most Joe-users WILL run WinXP (if
    they aren't already), and they probably will get the latest service
    pack. Maybe not right away, but slowly but surely the older systems
    will be phased out. With SP2 users will be protected by firewalls by
    default, they will have hardware and/or software protection to reduce
    the effects of buffer overruns, and their machines will automatically
    get the latest updates unless they are specifically disabling this
    feature.

    Not a sure-fire fix by a long shot, but it should be a BIG improvement
    from the current situation.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  36. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    news:1Mrqc.21289$Zxc.14980@news04.bloor.is.net.cable.rogers.com...
    > Judd <IhateSpam@stopspam.com> wrote:
    > >> Not so, there are existing applications which are already running
    > >> out of address space when they mmap() large files. This is a
    > >> technique which is a big win if you have a bunch of processes
    > >> sharing a file, although it makes little difference over file i/o if
    > >> you have a single process and don't have all the flushing and
    > >> locking issues.
    > >>
    > >
    > > Other than server DB and some large image processing programs, what
    > > other programs are doing this? I have found this to be rarity thus
    > > the exception and not the norm.
    >
    > I would assume this would become more of the norm rather than the
    exception
    > once 64-bit is entrenched. There are big advantages to accessing files
    with
    > a mmap function rather than the traditional file i/o functions. Not the
    > least of which is that accessing mmapped files is just like accessing
    > memory, and secondly you bypass having to do a context switch to the
    kernel
    > at several levels.
    >

    I don't disagree with you at all. 2 GB is generally plenty big for most
    small to medium level applications which is the majority of what people use
    today.
  37. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    The difficult part is to get Joe-users to install SP2.

    "Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
    news:uhfla0lh5gb9va4f5vk3navj46vjqh733n@4ax.com...
    > On Mon, 17 May 2004 23:53:38 -0400, KR Williams <krw@att.biz> wrote:
    > >In article <raqia0lmpp67sf805s7gvfcifkobq4pjjt@4ax.com>,
    > >hilla_nospam_20@yahoo.ca says...
    > >> As I've mentioned before, WinXP SP2 should make a bit difference on
    > >> this.. at least for those who end up using it. This should be a
    > >> fairly major step forward in terms of Windows security, MUCH more so
    > >> than any of the previous baby steps.
    > >
    > >There is no way I'm moving to WinXP, much less SP2. At home I've
    > >stopped with Win2K SP2 and will go no further. At work I'm
    > >required to have SP4. It's their machine, they can do what they
    > >wish with it. I'm not agreeing to be a M$uck slave though.
    >
    > The important thing though is that most Joe-users WILL run WinXP (if
    > they aren't already), and they probably will get the latest service
    > pack. Maybe not right away, but slowly but surely the older systems
    > will be phased out. With SP2 users will be protected by firewalls by
    > default, they will have hardware and/or software protection to reduce
    > the effects of buffer overruns, and their machines will automatically
    > get the latest updates unless they are specifically disabling this
    > feature.
    >
    > Not a sure-fire fix by a long shot, but it should be a BIG improvement
    > from the current situation.
    >
    > -------------
    > Tony Hill
    > hilla <underscore> 20 <at> yahoo <dot> ca
  38. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Judd wrote:
    > "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    > news:1Mrqc.21289$Zxc.14980@news04.bloor.is.net.cable.rogers.com...
    >> Judd <IhateSpam@stopspam.com> wrote:
    >>> Other than server DB and some large image processing programs, what
    >>> other programs are doing this? I have found this to be rarity thus
    >>> the exception and not the norm.
    >>
    >> I would assume this would become more of the norm rather than the
    >> exception once 64-bit is entrenched. There are big advantages to
    >> accessing files with a mmap function rather than the traditional
    >> file i/o functions. Not the least of which is that accessing mmapped
    >> files is just like accessing memory, and secondly you bypass having
    >> to do a context switch to the kernel at several levels.
    >>
    >
    > I don't disagree with you at all. 2 GB is generally plenty big for
    > most small to medium level applications which is the majority of what
    > people use today.

    What I meant was that even if processor's memory doesn't go past 4GB on
    early 64-bit desktops, applications which create greater than 4GB datafiles
    will still benefit from the 64-bits. Not the least of which is the ability
    open super-4GB files using a mmap rather than standard file i/o.

    Yousuf Khan
  39. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Sat, 15 May 2004 16:10:50 GMT, "Yousuf Khan"
    <news.tally.bbbl67@spamgourmet.com> wrote:

    > Judd <IhateSpam@stopspam.com> wrote:
    > > "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    > > news:mxepc.9715$0qd.6428@twister01.bloor.is.net.cable.rogers.com...
    > >> Judd <IhateSpam@stopspam.com> wrote:
    > >>> http://www.infoworld.com/article/04/05/13/HNprescott_1.html
    > >>>
    > >>> So what's all expected for Q3 now?
    > >>> - 3.73 MHz Prescott/Dothan?
    > >>
    > >> Oh, and no, Dothan obviously wouldn't run at 3.73 Ghz, but it might
    > >> touch
    > >> 2.2 Ghz by Q3.
    > >>
    > >
    > > So one would think, but recall the article I posted earlier about a
    > > 3.73 Prescott CPU with a Dothan core? My guess is that the article
    > > is wrong and it's not Dothan, but it did raise an eyebrow :-)
    >
    > Which article? The one in the link above doesn't mention anything about the
    > Dothan.

    http://www.anandtech.com/guides/showdoc.html?i=2048
  40. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <UMEqc.65794$0qd.50549
    @twister01.bloor.is.net.cable.rogers.com>, news.20.bbbl67
    @spamgourmet.com says...
    > Judd wrote:
    > > "Yousuf Khan" <news.tally.bbbl67@spamgourmet.com> wrote in message
    > > news:1Mrqc.21289$Zxc.14980@news04.bloor.is.net.cable.rogers.com...
    > >> Judd <IhateSpam@stopspam.com> wrote:
    > >>> Other than server DB and some large image processing programs, what
    > >>> other programs are doing this? I have found this to be rarity thus
    > >>> the exception and not the norm.
    > >>
    > >> I would assume this would become more of the norm rather than the
    > >> exception once 64-bit is entrenched. There are big advantages to
    > >> accessing files with a mmap function rather than the traditional
    > >> file i/o functions. Not the least of which is that accessing mmapped
    > >> files is just like accessing memory, and secondly you bypass having
    > >> to do a context switch to the kernel at several levels.
    > >>
    > >
    > > I don't disagree with you at all. 2 GB is generally plenty big for
    > > most small to medium level applications which is the majority of what
    > > people use today.
    >
    > What I meant was that even if processor's memory doesn't go past 4GB on
    > early 64-bit desktops, applications which create greater than 4GB datafiles
    > will still benefit from the 64-bits. Not the least of which is the ability
    > open super-4GB files using a mmap rather than standard file i/o.

    DOn't forget the memory that's been committed (to even suspended
    tasks and the ever-present M$ memory leaks). A 2GB virtual space
    isn't a lot with even a 1GB real system! Of course Intel and
    apologists won't admit that a larger address space is needed
    until Intel offers it to the masses (and that will be *LONG*
    before the claimed 2010).

    --
    Keith
  41. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Tue, 18 May 2004 10:56:53 -0600, "Judd" <IhateSpam@stopspam.com> wrote:

    >> Ah someone who speaks for the uhh, many?? The only thing asinine here is
    >> your slavish nodding to the i-Dogma. Windows XP-64 is a damned sight more
    >> than vapor - delude yourself if you wish.
    >
    >No, it's vapor. Until it's on the shelves of CompUSA and prepackaged from
    >vendors, it's vapor. Your statements would be considered wholly dishonest
    >from the consumer POV.

    It is *not* vapor to developers right now and its non-appearnce at CompUSA
    is not *known* to be for technical reasons. To say it's not "built" is
    rubbish by any acknowledged software standards.

    >> No - it's not cheaper at all, if you look at the current offerings even
    >two
    >> slots down from the top of the line. You appear not to have been paying
    >> attention to the recent 4.5year slump following the 2K panic: 2 years for
    >> corporate is absurd as a general rule - unless maybe for a small portion
    >of
    >> the top workstations... which is in fact a major sector clamoring for
    >> 64-bit. From my POV I don't see them taking less. Even the home sector
    >is
    >> largely an upgrade market now and I believe they'll be very careful what
    >> they lay out their money on. I'll certainly advise anyone who asks to buy
    >> the 64-bit now - no waiting is required.;-)
    >
    >You bet it's cheaper! Intel in comparison to AMD is not cheaper, but when
    >Intel releases 64-bit products, the 32-bit products will be cheaper (prices
    >slashed, etc.). You are comparing apples to apples.

    We'll see when it happens and if so, how that stands up. Previous attempts
    at selling crippled, intentionally and otherwise, hardware, e.g. 386SX,
    486SX, Celeron, etc. have had mixed results.

    >> >Huh? They've said that in 2005 nearly all would be EM64T as well as dual
    >> >core. Next month they are releasing products for workstation and server
    >> >only because why do they need to sell it to the consumer (see reasons
    >> >above).
    >>
    >> The upgrade consumer is wiser now - tasks are tangibly increasing in
    >> complexity and expectations are high. Once they grasp the fact of the
    >> 64-bit address canard and appreciate the real improvement of the new ISA
    >> and register files, the penny will drop!
    >>
    >
    >Uh, the average consumer doesn't know jack. This is why marketing is so
    >important. They don't care so long as it sounds good ("That thang got a
    >hemi!") and runs their software better. You are using your considerable
    >intelligence of computers as a benchmark for what others know. I'm just
    >letting you know that it's unrealistic.

    As I've tried to get across, a large part of the consumer market is now
    "upgrade"... == wiser. The consumer market is becoming increasingly
    sophisticated in its appreciation... and demands. Digital cameras,
    digi-videocams, home media centers/networks, etc will do that.

    >> We'll see what Intel does with their segmentation model but dual core will
    >> not be here until rather late in 2005. Fortunately for them, when they
    >> wake up, the software willl be in place... or further along than if
    >> everyone had waited for an edict from "i".
    >>
    >
    >I don't know when dual core will get here. They surprised the heck out of
    >me with the release announcement of the EM64T. I figured that was 2005 at
    >the earliest. Funny how things change. If AMD is pushing dual core, then
    >Intel will release it earlier than you expect.

    You have definitely not been paying attention then. The 64-bit nature of
    Prescott has been exposed for over a year now:
    http://www.chip-architect.com/. It is also interesting that AFAIK we have
    not even been given a clue on its performance in 64-bit mode.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  42. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Thu, 20 May 2004 05:47:15 -0400, George Macdonald
    <fammacd=!SPAM^nothanks@tellurian.com> wrote:

    >As I've tried to get across, a large part of the consumer market is now
    >"upgrade"... == wiser. The consumer market is becoming increasingly
    >sophisticated in its appreciation... and demands. Digital cameras,
    >digi-videocams, home media centers/networks, etc will do that.

    I work with a lot of families through high/middle school connections,
    here in Silicon Valley, and it's my experience that the bulk of
    computer users really don't have a clue what's in their box. They
    know the brand name (HP, Dell, whatever) and (generally) the OS, but
    don't have any idea the CPU speed, AMD or Intel, even how much RAM or
    how big a HD they have. They get advice from a salesman at Best Buy
    or a friend who reads PC Mag, buy it, and that's it until it quits
    working right and they call someone to help.

    Sure, the techies know that stuff, but there are so many more people
    who still have all the vendor-installed icons on their desktop (Free
    AOL Trial!) a year after they bought it because they don't know what
    they can delete or not, or even that they *can* delete it. IME, the
    bulk of PC consumers today have no more idea what's inside their PC
    than they do what's inside their TV.


    Neil Maxwell - I don't speak for my employer
  43. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In comp.sys.ibm.pc.hardware.chips Yousuf Khan <news.20.bbbl67@spamgourmet.com> wrote:
    > Judd wrote:
    > > I don't disagree with you at all. 2 GB is generally plenty big for
    > > most small to medium level applications which is the majority of what
    > > people use today.
    >
    > What I meant was that even if processor's memory doesn't go past 4GB on
    > early 64-bit desktops, applications which create greater than 4GB datafiles
    > will still benefit from the 64-bits. Not the least of which is the ability
    > open super-4GB files using a mmap rather than standard file i/o.

    You don't even need to be able to go as far as individual super-4GB files...
    just over 3GB of files and physical memory in total (2GB on Windows). Not
    to mention that given how most OSes today handle physical memory, things
    start getting klugy after a gig or two, rather than at 4GB.

    --
    Nate Edel http://www.nkedel.com/

    "Elder Party 2004: Cthulhu for President -- this time WE'RE the lesser
    evil."
  44. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In comp.sys.ibm.pc.hardware.chips KR Williams <krw@att.biz> wrote:
    > Also note that as real memory approaches the 2GB line that
    > virtual memory is still "interesting". the normal machine with
    > 2GB will be here long before the 2010 Intel fobs off as fact.

    My own suspicion is that a lot of power users will be going to 2GB as soon
    as prices fall back to where they were, oh, 6 months ago. I know enough
    people building 1GB machines as a matter of course even with the much higher
    memory prices that as soon as they drop back, I suspect they'll start
    doubling the RAM rather than saving the money.

    Ditto for regular users going to 1GB. Next big price drop after that, we'll
    be at 2GB.

    --
    Nate Edel http://www.nkedel.com/

    "Elder Party 2004: Cthulhu for President -- this time WE'RE the lesser
    evil."
  45. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    KR Williams <krw@att.biz> wrote:
    > DOn't forget the memory that's been committed (to even suspended
    > tasks and the ever-present M$ memory leaks). A 2GB virtual space
    > isn't a lot with even a 1GB real system! Of course Intel and
    > apologists won't admit that a larger address space is needed
    > until Intel offers it to the masses (and that will be *LONG*
    > before the claimed 2010).

    Well, obviously Intel has already admitted to it, witness EM64T.

    Yousuf Khan
  46. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Thu, 20 May 2004 08:23:20 -0700, Neil Maxwell <neil.maxwell@intel.com>
    wrote:

    >On Thu, 20 May 2004 05:47:15 -0400, George Macdonald
    ><fammacd=!SPAM^nothanks@tellurian.com> wrote:
    >
    >>As I've tried to get across, a large part of the consumer market is now
    >>"upgrade"... == wiser. The consumer market is becoming increasingly
    >>sophisticated in its appreciation... and demands. Digital cameras,
    >>digi-videocams, home media centers/networks, etc will do that.
    >
    >I work with a lot of families through high/middle school connections,
    >here in Silicon Valley, and it's my experience that the bulk of
    >computer users really don't have a clue what's in their box. They
    >know the brand name (HP, Dell, whatever) and (generally) the OS, but
    >don't have any idea the CPU speed, AMD or Intel, even how much RAM or
    >how big a HD they have. They get advice from a salesman at Best Buy
    >or a friend who reads PC Mag, buy it, and that's it until it quits
    >working right and they call someone to help.
    >
    >Sure, the techies know that stuff, but there are so many more people
    >who still have all the vendor-installed icons on their desktop (Free
    >AOL Trial!) a year after they bought it because they don't know what
    >they can delete or not, or even that they *can* delete it. IME, the
    >bulk of PC consumers today have no more idea what's inside their PC
    >than they do what's inside their TV.

    Like I said, there's difference between first-timers, which you seem to be
    talking about (high/middle school) and the 2nd-time-arounders. Go look at
    some of the forums on digital cameras, video processing etc. Then there's
    the kids who are into network parties and the likes - I see them getting up
    to speed pretty quickly. The difference here is that where the motivation
    for owning a computer is to do something useful with it, rather than just
    because the want to have a computer, people learn quite quickly and know
    what they want.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
  47. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    >
    > It is *not* vapor to developers right now and its non-appearnce at CompUSA
    > is not *known* to be for technical reasons. To say it's not "built" is
    > rubbish by any acknowledged software standards.

    Here's your first caveat... "to developers" which is a tiny community in the
    software world. "To developers" isn't even accurate. It's only
    "developers" that have cared to get involved in early development. That's
    an even smaller group. Name the software standard that wouldn't call this
    vapor? Since you've acknowledged that this is a standard, please list it!

    > >
    > >Uh, the average consumer doesn't know jack. This is why marketing is so
    > >important. They don't care so long as it sounds good ("That thang got a
    > >hemi!") and runs their software better. You are using your considerable
    > >intelligence of computers as a benchmark for what others know. I'm just
    > >letting you know that it's unrealistic.
    >
    > As I've tried to get across, a large part of the consumer market is now
    > "upgrade"... == wiser. The consumer market is becoming increasingly
    > sophisticated in its appreciation... and demands. Digital cameras,
    > digi-videocams, home media centers/networks, etc will do that.

    Digital cameras doesn't make them wiser... LOL. None the wiser for
    anything. If you can work a VCR, are you an expert on electronic
    engineering? That's quite a leap of faith. It is wholly untrue also. Most
    consumers don't know what 64-bit gets them. It's just another catchy
    buzzword to them. If the consumers were intelligent, they would probably
    shun the 64-bit for a marked down 32-bit since there is little to be gained
    from having 64-bit at this moment for most consumers.

    > >
    > >I don't know when dual core will get here. They surprised the heck out
    of
    > >me with the release announcement of the EM64T. I figured that was 2005
    at
    > >the earliest. Funny how things change. If AMD is pushing dual core,
    then
    > >Intel will release it earlier than you expect.
    >
    > You have definitely not been paying attention then. The 64-bit nature of
    > Prescott has been exposed for over a year now:
    > http://www.chip-architect.com/. It is also interesting that AFAIK we have
    > not even been given a clue on its performance in 64-bit mode.

    Yes, I saw that long ago. It was a reach by most estimations but we all
    kept it in the back of our minds anyway. It was known more than 2 years ago
    that Intel was working on Yamhill but would only release a product if they
    had to (market pressure driven by media frenzy for a new buzzword). I'm
    still shocked about it being a 3rd quarter 2004 product though. It seems a
    bit hasty but perhaps their partners were pushing it hard (such as Dell)
    and the sales numbers looked right for it.
  48. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Neil Maxwell" <neil.maxwell@intel.com> wrote in message
    news:hkipa0tn07ukj9kkg0mgmnvlum4a0verh3@4ax.com...
    > On Thu, 20 May 2004 05:47:15 -0400, George Macdonald
    > <fammacd=!SPAM^nothanks@tellurian.com> wrote:
    >
    > >As I've tried to get across, a large part of the consumer market is now
    > >"upgrade"... == wiser. The consumer market is becoming increasingly
    > >sophisticated in its appreciation... and demands. Digital cameras,
    > >digi-videocams, home media centers/networks, etc will do that.
    >
    > I work with a lot of families through high/middle school connections,
    > here in Silicon Valley, and it's my experience that the bulk of
    > computer users really don't have a clue what's in their box. They
    > know the brand name (HP, Dell, whatever) and (generally) the OS, but
    > don't have any idea the CPU speed, AMD or Intel, even how much RAM or
    > how big a HD they have. They get advice from a salesman at Best Buy
    > or a friend who reads PC Mag, buy it, and that's it until it quits
    > working right and they call someone to help.
    >
    > Sure, the techies know that stuff, but there are so many more people
    > who still have all the vendor-installed icons on their desktop (Free
    > AOL Trial!) a year after they bought it because they don't know what
    > they can delete or not, or even that they *can* delete it. IME, the
    > bulk of PC consumers today have no more idea what's inside their PC
    > than they do what's inside their TV.

    You are correct sir and you are in Silicon valley so I doubt these are first
    time users like George is implying. Most users really aren't that savvy.
    They think they are because they know the buzzwords et. al but they really
    have little idea.
  49. Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Fri, 21 May 2004 01:56:01 -0400, George Macdonald
    <fammacd=!SPAM^nothanks@tellurian.com> wrote:

    >On Thu, 20 May 2004 08:23:20 -0700, Neil Maxwell <neil.maxwell@intel.com>
    >wrote:
    >
    >>On Thu, 20 May 2004 05:47:15 -0400, George Macdonald
    >><fammacd=!SPAM^nothanks@tellurian.com> wrote:
    >>
    >>>As I've tried to get across, a large part of the consumer market is now
    >>>"upgrade"... == wiser. The consumer market is becoming increasingly
    >>>sophisticated in its appreciation... and demands. Digital cameras,
    >>>digi-videocams, home media centers/networks, etc will do that.
    >>
    >>I work with a lot of families through high/middle school connections,
    >>here in Silicon Valley, and it's my experience that the bulk of
    >>computer users really don't have a clue what's in their box. They
    >>know the brand name (HP, Dell, whatever) and (generally) the OS, but
    >>don't have any idea the CPU speed, AMD or Intel, even how much RAM or
    >>how big a HD they have. They get advice from a salesman at Best Buy
    >>or a friend who reads PC Mag, buy it, and that's it until it quits
    >>working right and they call someone to help.
    >>
    >>Sure, the techies know that stuff, but there are so many more people
    >>who still have all the vendor-installed icons on their desktop (Free
    >>AOL Trial!) a year after they bought it because they don't know what
    >>they can delete or not, or even that they *can* delete it. IME, the
    >>bulk of PC consumers today have no more idea what's inside their PC
    >>than they do what's inside their TV.
    >
    >Like I said, there's difference between first-timers, which you seem to be
    >talking about (high/middle school) and the 2nd-time-arounders. Go look at
    >some of the forums on digital cameras, video processing etc. Then there's
    >the kids who are into network parties and the likes - I see them getting up
    >to speed pretty quickly. The difference here is that where the motivation
    >for owning a computer is to do something useful with it, rather than just
    >because the want to have a computer, people learn quite quickly and know
    >what they want.

    Actually, I'm talking about the parents. Some of the kids know some
    of this stuff, but the parents actually buy the gear and have to fix
    the more serious problems. It's a pretty easy thing to check out,
    particularly if you've got kids in school and/or interact with
    parents.

    In any middle-class and above neighborhood, virtually everyone with
    kids has one or more computers. If you go up to them and ask them
    what kind and how fast their CPU is and how much RAM they've got, I'd
    bet you'd get 9 out of 10 blank stares or garbled answers. At least,
    that's how it is around here, despite being in one of the technology
    hotbeds in the USA. Maybe it's because I help people with their PCs
    and only get the clueless ones, giving me a skewed perspective.


    Neil Maxwell - I don't speak for my employer
Ask a new question

Read More

CPUs Extension Product