Conference ricks::dechips

    Note however the comments that 64-bit NT would not be available until
    Merced ships ... this is the part we need to correct.  If only we could
    get the trade rags to do a little more research than just reading the
    press releases from Intel and HP.

    re: .2
    
    The key points about the early 64-bit support in Alpha NT:
    
    	1. It is being done on Alpha first
    
    	2. Although it is just half a dozen services (alloc, free,
    	   read_disk, write_disk, copy_to, copy_from), these services
    	   are exactly what is needed to support VLM for database servers
    	   (SQL Server, Oracle, etc).
    
    	   Since our primary proof points for VLM on Unix are database
    	   applications, this NT support is just what is needed to open
    	   large new markets for Alpha NT.
    
    	3. There will be demo's of the VLM support "this Spring"
    	   [northern hemisphere: between 21 March and 21 June]
    
    /Rich Grove, GEM compiler group

    If they have any brains, they will never fully 64-bit'ize NT, but just
    add support for 64-bit data regions.  It's the biggest bang for the
    buck.
    

Ahem. OpenVMS Alpha does not have just a "couple of system services for
allocating and manipulating 64-bit regions". It has a rather full
complement of 64 bit services. About all user I/O, and most of the rest
can have buffers anywhere in 64 bit space. The one big thing missing is
loading code into P2 space, but since ASTs can have 64 bit addresses,
it has been stated that if you get code loaded there, it will run.

The 64 bit NT stuff on the other hand has been reported as very limited.
It would be interesting to know whether the NT I/O stack will be overhauled
to allow I/O directly (where DMA is used!) in/out of addresses in 64 bit
space that don't have 32 bit simple aliases. The VMS I/O system has had
this work done, so that I/O can be done anywhere. Ditto ASTs, ditto many
system services. A few things, like the direct ACP calls, don't do 64 bits
but that's because these are small arguments that generally are produced
by RMS, which gets mapped where this isn't an issue. For most calls, the
services recognize themselves whether the addresses are 32 or 64 bits
and get them right. Buffers and paging and so on have all been made to
work right. 

There were some new things added for 7.1 to give the option of memory
sections not backed by files. Maybe this has confused you.

There are certain low end platforms in which VMS does I/O into buffers
into low memory; the Pelican was like that, due to absence of some mapping
hardware. These are very much the exception however. 

Of course, if an NT driver does programmed I/O and not DMA (lose lose!)
making I/O happen "directly" to 64 bit buffers might be simpler to
do, but will suffer speed-wise. The test of utility is IMO whether
DMA will work. There are additional tests of robustness. VMS will, for example,
not fall over on its side when real memory isn't quite enough; it will start
paging or swapping but NOT crash. So an app that needs a little more mem
than is available once in a blue moon also doesn't crash. I've seen unix
dialects where this is emphatically not true (e.g. from Sun). What will
happen with NT in like case?
[posted by Notes-News gateway]

    For the last 6 months, when competing against HP, I used to challenge
    the customer to get their HP rep and an Intel rep in the same room at
    the same time, and ask each to 'explain' the HP/Intel roadmap (cloud as
    I called it). And then ask the HP rep to explain how easily their
    customers could 'migrate' into and through this cloud to the nirvana
    beyond. And to compare current target dates from HP and Intel to the
    estimates they each/both gave a year ago.
    
    Worked every time.
    
    We need to watch for the use of the word 'true' in the context of 'true
    64 bit NT' from Intel and HP from here on, and respond accordingly.
    
    Look for Microsoft's Enterprise Computing event (New York, April / May
    I am told - by Microsoft) for more to be revealed.
    
    Now, if Jesse and crew can deliver us 8x00 with NT soonest, we can have
    2 years or so of fun till Merced comes. Maybe.
    
    AW

If MS provides enough 64-bit functionality this year to implement VLM
databases efficiently, then we have a compelling NT high-end server story.
This may even drive Compaq to adopt Alpha (perhaps by buying Digital)
to stay in the Enterprise Computing ball game.

If NT Alpha delivers a viable VLM solution 2 years before NT-Intel,
Compaq has some figuring to do.

    re: <<< Note 654.7 by INDYX::ram "Ram Rao, PBPGINFWMY" >>>
    
>This may even drive Compaq to adopt Alpha (perhaps by buying Digital)
>to stay in the Enterprise Computing ball game.
    
    Ram, what're they feeding you out there?  Time to check the water
    supply for contaminants!!!
    

	"You've got to have a dream; if you don't have a dream,
how you gonna have a dream come true?"

    from: microprocessor report march 10 1997 abstract
    ...
    MDR analisys: design concepts for merced
    We boldly predict the 0.25 micron Merced chip will use an eight-way
    VLIW core to deliver in excess of 40 SPECINT95 and 80 SPECFP95 while
    running at 600 Mhz. We estimate the 300mm2 die will contain roughly 35
    million transistors , including 512K of on-chip cache. The chip is
    likely to offer industry leading performance in both native  and x86
    modes when it debuts in 1h99
    ....
    who's got the entire article?
    

    so, what will *we* be making in just over 2 years time ? refer to my
    rant in the PA-8500 entry later...

From the latest Rapidly Changing Face of Computing 
(http://www.digital.com/info/rcfoc):

     According to the March 10 MicroProcessor Report
     ( http://www.chipanalyst.com/report/mpr.html ) MPR has developed a
     forecast, independent from Intel sources (in fact they assure us
     that the few Intel engineers they have captured expired on the rack
     before telling their secrets), that expects a 600 MHz 64-bit Intel
     Merced (P7) CPU to be in production in the first half of 1999. And
     they expect a further refinement to that chip to cross the 1 GHz
     boundary within a year thereafter! (Another view into this
     information is available at
     http://www.news.com/News/Item/0,4,8651,00.html ).

     The chip is expected to process eight instructions in parallel (up
     from the Pentium Pro's three), and to implement a time-saving
     technique called "Very Long Instruction Word"
     ( see http://www.techweb.com/se/directlink.cgi?EET19960415S0011 for
     a somewhat detailed explanation of VLIW). And, since the RISC-based
     Merced does not directly execute the x86 instruction set which most
     of today's Windows applications (and their 130 million users,
     according to Windows Magazine's Mike Elgin
     - http://www.winmag.com/people/melgan/ ) demand, today's x86
     software might be accommodated through one of two approaches: A
     hardware implementation of the core x86 instruction set for BIOS
     and related "low level" code plus a software emulator for
     applications; Or perhaps through an on-chip x86-to-IA64 (Merced's
     instruction set) hardware translation engine (a mere two to three
     million extra transistors).

     What could this mean from a real-world computing standpoint?
     Today's Pentium Pro delivers 6.75 SPECfp95 performance
     (
http://support.intel.com/oem_developer/microprocessors/q_and_r/8457.HTM
);
     the 1 GHz Merced could top 120 SPECfp95 -- 18 times greater
     performance -- about three years from now! And, MPR expects that
     further miniaturization of the chip will reduce manufacturing costs
     to below $100 (although of course selling price will be
     significantly higher), eventually driving this CPU into the
     mainstream commodity computing market.

     Of course I wouldn't sit back waiting for one of these to hit the
     local computer mart . It's important to remember that this is only
     speculation, albeit enlightened speculation from a well respected
     firm that tracks the microprocessor industry; Intel may take a
     rather different view (which they're not currently sharing.) But
     should MPR's forecast prove correct, this represents a rather
     dramatic demonstration of how the rapidly changing face of
     computing shows no plans for slowing down. Indeed, as we can see,
     the rate of change is constantly increasing.

PJDM

    
    +    TWO MORE PA-RISCS CAST SHADOW OVER HP MERCED DELIVERIES
    
    Hewlett-Packard Co has identified a further two members of its
    Precision Architecture RISC family that will extend the life of
    native PA-8000 boxes well into the next decade for those users
    who dont wish to make the transition to systems HP is building
    around the Intel Corp Merced part. One will be formally
    announced in 1999, the other in the year 2000; they will show
    up in systems 12 to 18 months later. The most recent addition
    to the line is the PA-8500, expected to debut in systems around
    mid-1998 (CI No 2,960). The news raises yet more speculation
    about the likely availability of systems built upon Merced,
    which uses an IA-64 RISC instruction set Intel co-designed with
    HP. Recent reports suggested that Intel had pushed Merced
    deliveries back to 1999 from 1998 though HP claims it has only
    ever talked about the availability of Merced systems by the
    year 2000. Ironically, news of the two further PA-8000 family
    members emerged from a meeting addressed by systems technology
    chief Rich Sevcik which HP called to try and counteract what it
    claims is the Fear Uncertainty and Doubt (FUD) being spread by
    rivals such as DEC, IBM and Sun suggesting HP is abandoning
    Unix for NT, and about the supposed difficulty users will face
    moving applications from PA-RISC to Merced. HP says it will
    announce six-way SMP Unix systems using the PA-8200 within four
    weeks time (CI No 3,109), along with eight-way Windows NT-based
    Intel servers. It will also have NT up on Intels Pentium II
    processor - the Pentium Pro with MMX multimedia extensions
    formerly known as Klamath.

    
    +            MERCED EXPECTED LATE 1998 OR EARLY 1999
    
    Intel Corp's been extra secretive about its forthcoming Merced
    chip implementation of the 64-bit IA-64 architecture it co-
    designed with Hewlett-Packard Co, largely to keep the
    compatible houses such as Advanced Micro Devices Inc from
    getting a jump on it. However some of its partners, including
    HP itself, are becoming increasingly frustrated at their
    inability to be able to pass on product information to key
    commercial and enterprise customers which have IT plans
    stretching three or in some cases five years into the future.
    HP says these types of customers need information of future
    products 18 months, or better two years ahead of product
    introduction, and have been trying, with little apparent
    success to get Intel to open up. It has even resorted to asking
    the press corps to try and get the message through. Maybe the
    first chink in the armor was seen during Intel CEO Andy Grove's
    keynote at the Innovate 97 conference hosted in Houston, Texas,
    by Compaq Computer Corp. Grove's presentation showed Merced
    hitting the streets late 1998 or early 1999. By that time,
    processor implementations of both its 32-bit IA-32 and 64-bit
    IA- 64 instruction sets will reportedly be done in 0.18 micron
    technology. That's around the same design point the PowerPC
    camp expects to be with its G4 architecture in 1999.

    Interesting discussion of patents filed by Intel on Merced...
    particularly "Method and Apparatus for Transitioning Between
    Instruction Sets in a Processor".
    
    http://www.chipanalyst.com/mpr/merced/