NT speed?
Don Ahn
less efficient because 32-bit code is twice as large, and how all
the extra overhead will slow things down. This is contrary to what
I've learned about 32 bit programming and the 386/486/586 architecture
in general.
The same windows apps I run under seem quite a bit snappier and I would
expect that because:
1. 32 bit graphics should be faster because of all that bit
manipulation over 64k boundaries.
2. 486 and up should be faster in 32 bit mode than 16 bit mode.
3. 8 truly orthogonal 32 bit registers should make it easier
to optimize code. Lack of segment manipulations should
make code even more efficient.
4. pre-emptive multitasking (w/ 32bit VM) is more efficient.
(pretty wild having your app update windows while holding
down menu's. Might make you think you running
(*GASP*) a real OS!)
On the downside, I would expect some .exe bloat since some 16-bit ints
will be upgraded to 32-bit ints. However, I don't expect 2x since
CODE shouldn't be much larger (accessed default to 32-bit in protected
mode so prefix override bytes are not necessary), and 8-bit chars
are still 8-bit chars.
So NT should be "faster" than win 3.1 n'est pas?
(By the way, before all you OS/2 fanactics trounce on me, this should
all be true for OS/2 2.1 also)
-Don Ahn
don...@netcom.com
Lou Sanchez-Chopitea
But it does run slower!!! Compare the speed of FreeCell on identical
machines. I expect this is due to the greater system overhead and the cost
of thunking between the 32 bit code and 16 bit DLLs. OTOH you can have more
than one thing running in a reasonable manner.
Cheers
Lou
--
Lou Sanchez-Chopitea EMail: l...@xilinx.com
Senior Software Engineer SnailMail: 2100 Logic Drive
SpeakMail: (408) 879-5059 San Jose, CA 95124
FaxMail: (408) 559-7114
Jeff Kirvin
: I've read several articles and several posts about how NT will be
In theory. There are no native NT apps to test this theory, tho, and even
MS doesn't plan on delivering any for _months_.
The 16-bit Windows apps you run now run in a 16-bit subsystem on NT,
and the thunking and additional overhead causes 16-bit apps (remember,
Win16 is all we have right now! Mathmatica being the ONE exception)
to run 5% to _40%_ slower under NT than Windows 3.1. These are _Microsoft's_
numbers...
I wouldn't do my computer the disservice of running NT...
: (By the way, before all you OS/2 fanactics trounce on me, this should
: all be true for OS/2 2.1 also)
Yup. On _some_ _systems_ (<- Flame Guard (TM) ), WinOS/2 is actually
_faster_ than Win3.1, as it is actual Windows code tweaked by IBM to
run faster and more efficiently under OS/2. Do it every day.
: -Don Ahn
: don...@netcom.com
--
==============================================================================
Jeff Kirvin | These are my opinions. Any connection to the
jki...@pafosu1.hq.af.mil | opinions of the Air Force is purely coincidental.
==============================================================================
Ada and OS/2 - Eliminating crashes in our time!
==============================================================================
Dave Rogers
|>
|> In theory. There are no native NT apps to test this theory, tho, and even
|> MS doesn't plan on delivering any for _months_.
|>
|> The 16-bit Windows apps you run now run in a 16-bit subsystem on NT,
|> and the thunking and additional overhead causes 16-bit apps (remember,
|> Win16 is all we have right now! Mathmatica being the ONE exception)
|> to run 5% to _40%_ slower under NT than Windows 3.1. These are _Microsoft's_
|> numbers...
|>
NO. There are hundreds of native apps. Check out the Microsoft
Products and Services Win32 Catalog for Windows NT. There are 2-3 apps
per page listed on some 500 pages. Many of these have been available
for a year or so.
Additionally, it is easy (relatively speaking) to port a Win16 app to
Win32. I have moved many apps to Win32. Without exception, they all run
faster on Win32.
I would expect Win16 apps to run slower on Win32 and consider it the
price I pay for the convenience. If all you want to do is develop or
run Win16 apps just stay with Windows 3.1.
===============================================================================
Dave Rogers
M & R Software, Inc.
Internet: da...@rsd.dl.nec.com
On contract to: NEC America, Radio Software Dept
If you can't see the sky from where you work it's time to change jobs.
phil_polstra
In article <29...@hq.hq.af.mil> jkirvin@pafosu1 (Jeff Kirvin) writes:
>In theory. There are no native NT apps to test this theory, tho, and even
>MS doesn't plan on delivering any for _months_.
>
which were supposed to release with NT which is now out. Many of
these are shareware not overpriceware so they may not be as visible.
Peter Mayne
In article <donahnCB...@netcom.com>, don...@netcom.com (Don Ahn) writes:
>
>I've read several articles and several posts about how NT will be
>less efficient because 32-bit code is twice as large, and how all
>the extra overhead will slow things down. This is contrary to what
>I've learned about 32 bit programming and the 386/486/586 architecture
>in general.
>
>The same windows apps I run under seem quite a bit snappier and I would
>expect that because:
>
> 1. 32 bit graphics should be faster because of all that bit
> manipulation over 64k boundaries.
This depends on what kind of graphics controller you have. If it is clever
enough, the CPU doesn't get involved in the graphics at all.
> 2. 486 and up should be faster in 32 bit mode than 16 bit mode.
AXP is even faster, and it only has one mode: 64 bits. 8-)
> 3. 8 truly orthogonal 32 bit registers should make it easier
> to optimize code. Lack of segment manipulations should
> make code even more efficient.
32 64 bit registers make it even easier.
> 4. pre-emptive multitasking (w/ 32bit VM) is more efficient.
> (pretty wild having your app update windows while holding
> down menu's. Might make you think you running
> (*GASP*) a real OS!)
>
>On the downside, I would expect some .exe bloat since some 16-bit ints
>will be upgraded to 32-bit ints. However, I don't expect 2x since
>CODE shouldn't be much larger (accessed default to 32-bit in protected
>mode so prefix override bytes are not necessary), and 8-bit chars
>are still 8-bit chars.
RISC executables do tend to be larger than CISC.
>So NT should be "faster" than win 3.1 n'est pas?
Certainly. Intel Windows 3.1 applications run faster than some Intel
PCs on a DECpc AXP 150, and native applications (eg PV-WAVE, MPEG
player) are very fast. The 150MHz AXP in the Alpha PC has significantly
faster floating point than x86 or Pentium.
>(By the way, before all you OS/2 fanactics trounce on me, this should
>all be true for OS/2 2.1 also)
Except for running on an AXP machine.
>-Don Ahn
>don...@netcom.com
PJDM
--
Peter Mayne | My statements, not Digital's.
Digital Equipment Corporation |
Canberra, ACT, Australia | "AXP!": Bill the Cat
Nathan Boyd
>> 2. 486 and up should be faster in 32 bit mode than 16 bit mode.
>
>AXP is even faster, and it only has one mode: 64 bits. 8-)
[more of the gratuitous Alpha AXP sales pitch deleted]
So now direct me to a <$15000 Alpha AXP, Peter.
>PJDM
>--
>Peter Mayne | My statements, not Digital's.
>Digital Equipment Corporation |
>Canberra, ACT, Australia | "AXP!": Bill the Cat
Nathan
--
Nathan D. T. Boyd Sequent Computer Systems, Inc.
bo...@sequent.com Beaverton, OR 97009
(503) 578-4197
Lawrence Charles Hastings
+-In article <CBL97...@ryn.mro4.dec.com>,
| Peter...@cao.mts.dec.com wrote:
|
| In article <donahnCB...@netcom.com>, don...@netcom.com (Don Ahn) writes:
| > 2. 486 and up should be faster in 32 bit mode than 16 bit mode.
| AXP is even faster, and it only has one mode: 64 bits. 8-)
No, the Alpha has a 32-bit mode; and worse yet, the first release of NT
for the AXP will only run in 32-bit mode.
Future releases _may_ support 64-bit mode on the AXP, I'm told. But I
wouldn't hold my breath if I were you; I'm told that NT is inherently 32-bit
internally. They apparently didn't call it Win32 for nothing.
Peter Mayne
>So now direct me to a <$15000 Alpha AXP, Peter.
I'm sure my US counterparts will correct me if I'm wrong, but you can
purchase a DECpc AXP 150 for less than $US10 000. If you can
demonstrate that you are a developer (ie someone who will write code),
then there is a temporary offer for less than $US7000.
32MB memory
512KB cache
SCSI controller
CD drive
3.5" SCSI 426 MB hard disk
3.5" 2.8MB floppy
Ethernet
SVGA
17" colour monitor
3 button mouse
2 serial, 1 parallel port
>Nathan
Peter Mayne
In article <24bpp3...@darkstar.UCSC.EDU>, funk...@cats.ucsc.edu (Lawrence Charles Hastings) writes:
>+-In article <CBL97...@ryn.mro4.dec.com>,
>| Peter...@cao.mts.dec.com wrote:
>|
>| In article <donahnCB...@netcom.com>, don...@netcom.com (Don Ahn) writes:
>| > 2. 486 and up should be faster in 32 bit mode than 16 bit mode.
>| AXP is even faster, and it only has one mode: 64 bits. 8-)
>+----------
>
>No, the Alpha has a 32-bit mode; and worse yet, the first release of NT
>for the AXP will only run in 32-bit mode.
No. AXP does *NOT* have a 32 bit mode.
All of the (integer) registers are 64 bit. AXP virtual addresses are 64
bit. There are instructions to load/store 32 bit integers. (Pentium has
instructions to load bytes, but that doesn't make it an 8 bit
architecture.) If you write code on an AXP, you can use 64 bit
integers (with the __int64 type, I think).
(The above is probably true for the 64 bit R4000 as well, but I don't know
much about them. Someone who does care to comment?)
Windows NT uses 32 bit virtual addresses. The mapping to AXP 64 bit
virtual addresses is done by a combination of the paging code (page
tables, etc), HAL, and PALcode, *NOT* by switching to a non-existent 32
bit mode.
>Future releases _may_ support 64-bit mode on the AXP, I'm told. But I
>wouldn't hold my breath if I were you; I'm told that NT is inherently 32-bit
>internally. They apparently didn't call it Win32 for nothing.
Funny, I'm told that there is nothing inherently 32 bit about Windows
NT (apart from the obvious things at the HAL/kernel levels). It's
called Win32 because it's a 32 bit interface. If Digital and Microsoft
had decided to use a full 64 bit interface for AXP (or if Microsoft
decided to do 64 bit MIPS version), what would it be called then? The
basic message of benefits such as a useable address space would become
confused, Digital would be harangued for producing yet another
"incompatible" box, etc, etc.
In the future, when there are more 64 bit architectures and x86
compatibility is much less important, there may very well be a Win64.
But for now, 32 bits will probably suffice for most desktops.
RICHARD HOFFBECK
>
> In article <1993Aug11.1...@sequent.com>, bo...@sequent.com (Nathan Boyd) writes:
>
> >So now direct me to a <$15000 Alpha AXP, Peter.
>
> I'm sure my US counterparts will correct me if I'm wrong, but you can
> purchase a DECpc AXP 150 for less than $US10 000. If you can
> demonstrate that you are a developer (ie someone who will write code),
> then there is a temporary offer for less than $US7000.
>
> 32MB memory
> 512KB cache
> SCSI controller
> CD drive
> 3.5" SCSI 426 MB hard disk
> 3.5" 2.8MB floppy
> Ethernet
> SVGA
> 17" colour monitor
> 3 button mouse
> 2 serial, 1 parallel port
>
The material they sent me had the above priced out at $7,495 US.
--rick
Tom Hatton
>In article <1993Aug11.1...@sequent.com>, bo...@sequent.com (Nathan Boyd) writes:
>>So now direct me to a <$15000 Alpha AXP, Peter.
>I'm sure my US counterparts will correct me if I'm wrong, but you can
>purchase a DECpc AXP 150 for less than $US10 000. If you can
>demonstrate that you are a developer (ie someone who will write code),
>then there is a temporary offer for less than $US7000.
>32MB memory
>512KB cache
>SCSI controller
>CD drive
>3.5" SCSI 426 MB hard disk
>3.5" 2.8MB floppy
>Ethernet
>SVGA
>17" colour monitor
>3 button mouse
>2 serial, 1 parallel port
Sounds great, if only I weren't locked in to running only NT. Surely
such hardware deserves a better interface :-)
--
Tom Hatton
hat...@cgl.ucsf.edu
(415)-476-8693
Nathan Boyd
>
>In article <1993Aug11.1...@sequent.com>, bo...@sequent.com (Nathan Boyd) writes:
>
>>So now direct me to a <$15000 Alpha AXP, Peter.
>
>I'm sure my US counterparts will correct me if I'm wrong, but you can
>purchase a DECpc AXP 150 for less than $US10 000. If you can
>demonstrate that you are a developer (ie someone who will write code),
>then there is a temporary offer for less than $US7000.
I was referring to something more along the lines of an HP Apollo... Aren't
the PC versions of the Alpha AXP disabled (32bit or something?) and much
slower than UNIX counterparts like the Apollo (which I doubt can be had
for less than $15000)?
>>Nathan
>
>PJDM
dave_duling
>
>In article <24bpp3...@darkstar.UCSC.EDU>, funk...@cats.ucsc.edu (Lawrence Charles Hastings) writes:
>>+-In article <CBL97...@ryn.mro4.dec.com>,
>>| Peter...@cao.mts.dec.com wrote:
>>|
>>| In article <donahnCB...@netcom.com>, don...@netcom.com (Don Ahn) writes:
>>| > 2. 486 and up should be faster in 32 bit mode than 16 bit mode.
>>| AXP is even faster, and it only has one mode: 64 bits. 8-)
>>+----------
>>
>>No, the Alpha has a 32-bit mode; and worse yet, the first release of NT
>>for the AXP will only run in 32-bit mode.
>
>No. AXP does *NOT* have a 32 bit mode.
>
>Funny, I'm told that there is nothing inherently 32 bit about Windows
>NT (apart from the obvious things at the HAL/kernel levels). It's
actually, before this gets out of hand, the Windows application programming
interface is called Win32 because system/gdi functions expect and return
32bit integers and pointers rather than 16 bit. So far as I know, it says
nothing about the rest of your code. You certainly can implement quad
precision if you like...
Q: Can the Alpha NT (not OSF/1) SDK really use 64 bit ints ?
Q: Does the Alpha Intel emulation *emulate* the x87 fpu or does it
translate x87 fpu functions to alpha x87 functions ?
>In the future, when there are more 64 bit architectures and x86
>compatibility is much less important, there may very well be a Win64.
>But for now, 32 bits will probably suffice for most desktops.
>
>PJDM
>--
>Peter Mayne | My statements, not Digital's.
>Digital Equipment Corporation |
>Canberra, ACT, Australia | "AXP!": Bill the Cat
>
-- Dave Duling "dul...@niehs.nih.gov"
dave_duling
>
>I was referring to something more along the lines of an HP Apollo... Aren't
>the PC versions of the Alpha AXP disabled (32bit or something?) and much
>slower than UNIX counterparts like the Apollo (which I doubt can be had
>for less than $15000)?
>
>
>Nathan
>
>Nathan D. T. Boyd Sequent Computer Systems, Inc.
>bo...@sequent.com Beaverton, OR 97009
>(503) 578-4197
The Alpha NT machine uses the EISA architechure. The OSF/1 and OpenVMS Alpha
machines use the DEC Turbochannel (?) which is much higher throughput and
probably has a better memory model. So SCSI and Graphics will be much better
on the higher end Alphas then on the NT version. I dont think the CPU itself
is different, although the non-NT machines may see higher clock speeds sooner.
-- Dave Duling "dul...@niehs.nih.gov"
Richard Krehbiel
>Future releases _may_ support 64-bit mode on the AXP, I'm told.
>But I wouldn't hold my breath if I were you; I'm told that NT is
>inherently 32-bit internally. They apparently didn't call it
>Win32 for nothing.
Funny, I'm told that there is nothing inherently 32 bit about Windows
NT (apart from the obvious things at the HAL/kernel levels). It's
I recall some 286 operating system that couldn't support use of 32 bit
386 registers because the task switcher only context-switched the low
16 bits of the register set. Might have been OS/2 1.0 or 1.1.
Perhaps this is a problem for Alpha NT as well, such that applications
couldn't use 64 bit regisers because the top 32 bits could be
corrupted.
--
Richard Krehbiel ri...@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
Jim Stewart
>>
>>In article <1993Aug11.1...@sequent.com>, bo...@sequent.com (Nathan Boyd) writes:
>>
>>>So now direct me to a <$15000 Alpha AXP, Peter.
>>
>the PC versions of the Alpha AXP disabled (32bit or something?) and much
>slower than UNIX counterparts like the Apollo (which I doubt can be had
>for less than $15000)?
>
>>>Nathan
>>
>>PJDM
>
>Nathan
The ALPHA AXP 150 uses the same 20164 that other production AXP systems use.
If there is a performance bottleneck at all it is the EISA bus. This is in
contrast to the Turbochannel found on AXP Workstations. The benifit is that
you can use EISA devices on the 150. Your "32bit or something" may be a
misconception rooted in the fact that NT, like VMS is a 32 bit operating
system. The price / performance ratio for AXP remains the best you can get.
BTW, the only 64bit production operating system you can buy is DEC OSF/1,
running on ALPHA... DEC is commited to both OpenVMS and DEC OSF/1 on the
AXP 150. ... but it will not run OS/2 ... :)
js who_has_been_reading_dnc_code_for_fifteen_years_:)
P
George J. Carrette
> I was referring to something more along the lines of an HP Apollo... Aren't
> the PC versions of the Alpha AXP disabled (32bit or something?) and much
> slower than UNIX counterparts like the Apollo
No! The "PC versions" (i.e. those with EISA bus) are not slower,
they are *faster* than the low-end workstation versions.
Your confusion with the unfortunate situation at Apollo is not reasonable.
In fact the DEC 3000 model 300L has a 100Mhz clock and a 256kb off chip
cache, and a memory bus speed of 50MB/sec.
Whereas the "PC version" which is the DECpc AXP 150 has a 150Mhz clock and
a 512Kbyte cache, and a memory bus speed of 115 MB/sec.
Therefore the PC version would be considered faster!
The 300L is in a smaller box, and has no expansion
bus, just SCSI and ETHERNET on the motherboard).
The DECpc AXP 150 is probably a bit more expensive than the DEC 3000 300L.
Note that my "Alpha AXP Systems Handbook" says that 3 operating systems
are supported on the DECpc. (Windows NT, OpenVMS, and OSF/1).
Whereas the DEC 30000 xxxx series make no mention of Windows NT support.
fred j mccall 575-3539
>pj...@chmeee.enet.dec.com (Peter Mayne) writes:
>>In article <1993Aug11.1...@sequent.com>, bo...@sequent.com (Nathan Boyd) writes:
>>>So now direct me to a <$15000 Alpha AXP, Peter.
>>I'm sure my US counterparts will correct me if I'm wrong, but you can
>>purchase a DECpc AXP 150 for less than $US10 000. If you can
>>demonstrate that you are a developer (ie someone who will write code),
>>then there is a temporary offer for less than $US7000.
>>32MB memory
>>512KB cache
>>SCSI controller
>>CD drive
>>3.5" SCSI 426 MB hard disk
>>3.5" 2.8MB floppy
>>Ethernet
>>SVGA
>>17" colour monitor
>>3 button mouse
>>2 serial, 1 parallel port
I received an ad yesterday for a similarly configured R4400 machine
for around $7.5k. Seems like NT is driving high-end hardware prices
down, at least for developers. ;-)
[So just what proof is DEC asking for to prove someone is a developer?
This seems to vary widely from company to company.]
>Sounds great, if only I weren't locked in to running only NT. Surely
>such hardware deserves a better interface :-)
Yeah, I agree. But isn't the AXP also supposed to run OpenVMS and
OSF1? Has anyone tried getting PC Tools for Windows to install on NT?
[There's an interface I could wish that MS had used for NT.]
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
Kai Uwe Rommel
>>> 2. 486 and up should be faster in 32 bit mode than 16 bit mode.
>>
>>AXP is even faster, and it only has one mode: 64 bits. 8-)
>>--
>>Peter Mayne | My statements, not Digital's.
>>Digital Equipment Corporation |
>>Canberra, ACT, Australia | "AXP!": Bill the Cat
Of which only the lower 32 bits are used in NT. Please correct me if
I'm wrong.
Kai Uwe Rommel
--
/* Kai Uwe Rommel Muenchen, Germany *
* rom...@ars.muc.de Phone +49 89 723 4101 *
* rom...@informatik.tu-muenchen.de Fax +49 89 324 4524 */
DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be. -Russell Williams
Peter Mayne
I'll answer several notes at once.
--
[DECpc AXP 150 info elided]
>Sounds great, if only I weren't locked in to running only NT. Surely
>such hardware deserves a better interface :-)
>--
>Tom Hatton
>hat...@cgl.ucsf.edu
>(415)-476-8693
As far as I know, the Alpha PC will (or will soon) run four operating systems:
- Windows NT
- OpenVMS
- OSF/1
- Native Netware
(Those people who have one will have seen the "Reboot to OpenVMS or OSF"
option on the boot menu.)
--
>I was referring to something more along the lines of an HP Apollo... Aren't
>the PC versions of the Alpha AXP disabled (32bit or something?) and much
>slower than UNIX counterparts like the Apollo (which I doubt can be had
>for less than $15000)?
>
>Nathan D. T. Boyd Sequent Computer Systems, Inc.
>bo...@sequent.com Beaverton, OR 97009
>(503) 578-4197
The DECpc AXP 150 has not been disabled in any way compared to any of
the other AXP machines. (Opinions about EISA vs Turbochannel vs
Futurebus+ and other PCcentric options aside.)
BTW the DEC3000 300L and DEC3000 300 are <$US5k and <$US10k are they
not? (But they don't run Windows NT.)
--
>Q: Can the Alpha NT (not OSF/1) SDK really use 64 bit ints ?
>
>Q: Does the Alpha Intel emulation *emulate* the x87 fpu or does it
> translate x87 fpu functions to alpha x87 functions ?
>
>-- Dave Duling "dul...@niehs.nih.gov"
My memory tells me I've seen __int64 declarations in the compiler.
Maybe someone who uses the compiler a bit more often than I do at the
moment would like to be more reassuring.
The AXP architecture doesn't have any "x87 functions". If you mean sin,
cos, sqrt, etc, it doesn't have any of those, either. So I suppose the
answer is that it emulates the x87 fpu. As far as "normal" floating
point stuff goes (multiply, divide, etc), I'm not sure about the x87
floating point format. Any takers?
--
>I recall some 286 operating system that couldn't support use of 32 bit
>386 registers because the task switcher only context-switched the low
>16 bits of the register set. Might have been OS/2 1.0 or 1.1.
>Perhaps this is a problem for Alpha NT as well, such that applications
>couldn't use 64 bit regisers because the top 32 bits could be
>corrupted.
>--
>Richard Krehbiel ri...@grebyn.com
Context switching is a hardware specific function in any operating
system. Given that code is able to use all 64 bits of the AXP
registers, I find it hard to believe that the Digital porting team
would only bother to context switch half of the registers. Even if they
did do such a thing, a 64 bit port would correct this without
applications being aware of it.
--
>There won't be a Win64 for the same reason there won't be a big-endian
>version: data. Change sizeof(int) and your data files are no longer
>compatible with the other versions. That's not to say there's no way to get
>round this, just that it would be as much hassle as the 16->32 shift, for
>much less gain.
>
>Alpha NT could operate internally at 64-bits, and I would be surprised if it
>doesn't already.
>
>Mark Atkinson
The size of pointers/integers passed to an API doesn't necessarily have
anything to do with sizeof(int). There could be a Win64, or even a
Win128, and sizeof(int) could still be 32. Since there is no ANSI
standard (yet, as far as I know) for anything past long, various
compilers do longer longs differently. For instance:
__int64 wideint1;
long long wideint2;
The Windows API uses WORD, DWORD, POINT, etc to avoid the specifics of
exactly how long the damned integer is anyway, and a good thing too.
As for being 64 bit internally, the Intel, MIPS, AXP, and any other
code is exactly the same source code (low level hardware dependencies
excepted). Just to make sure, I'll say it again: no matter what the
hardware platform is, the source code for Windows NT is exactly the
same. The only differences are hardware dependencies that applications
can't see anyway: VM management, bus interfaces, etc.
--
Anoosh Hosseini
|>
|>
|> I'll answer several notes at once.
|>
|> >
|> >Q: Does the Alpha Intel emulation *emulate* the x87 fpu or does it
|> > translate x87 fpu functions to alpha x87 functions ?
|> >
|> >-- Dave Duling "dul...@niehs.nih.gov"
|>
|> My memory tells me I've seen __int64 declarations in the compiler.
|> Maybe someone who uses the compiler a bit more often than I do at the
|> moment would like to be more reassuring.
The Generic SGI/Mips complier also has support for 64 bits in the form of
long long, however the SDK may be a different story. At least for the Mips NT,
they use a Microsoft front end (so all the options etc. look just like
the Intel/PC Windows version). Until Microsoft supports 64 bit operations
in their standard compiler, you will probably not see it.
|>
|> >I recall some 286 operating system that couldn't support use of 32 bit
|> >386 registers because the task switcher only context-switched the low
|> >16 bits of the register set. Might have been OS/2 1.0 or 1.1.
|> >Perhaps this is a problem for Alpha NT as well, such that applications
|> >couldn't use 64 bit regisers because the top 32 bits could be
|> >corrupted.
|> >--
|> >Richard Krehbiel ri...@grebyn.com
|>
|> Context switching is a hardware specific function in any operating
|> system. Given that code is able to use all 64 bits of the AXP
|> registers, I find it hard to believe that the Digital porting team
|> would only bother to context switch half of the registers. Even if they
|> did do such a thing, a 64 bit port would correct this without
|> applications being aware of it.
OK, in R4x00 land, context switching is a software thing, but in kernel
mode. 64 bit processors, (at least in R4x00 and for sure Alpha) do
not have separate ALU units for 32 and 64bit operations, rather handle all
numbers with their 64 bit hardware. 32 bit overflow/exceptions are accounted
for when executing 32 bit operand instructions. So it depends if
context switch code and even function calls use sd/ld (store/load
double) or their 32 bit counterparts, sw/lw. (Alpha terms 32 bits
longword, 64 bits quadword)
|>
|> --
|>
|> >There won't be a Win64 for the same reason there won't be a big-endian
|> >version: data. Change sizeof(int) and your data files are no longer
|> >compatible with the other versions. That's not to say there's no way to get
|> >round this, just that it would be as much hassle as the 16->32 shift, for
|> >much less gain.
|> >
|> >Alpha NT could operate internally at 64-bits, and I would be surprised if it
|> >doesn't already.
|> >
|> >Mark Atkinson
|>
|> The size of pointers/integers passed to an API doesn't necessarily have
|> anything to do with sizeof(int). There could be a Win64, or even a
|> Win128, and sizeof(int) could still be 32. Since there is no ANSI
|> standard (yet, as far as I know) for anything past long, various
|> compilers do longer longs differently. For instance:
|>
|> __int64 wideint1;
|> long long wideint2;
|>
|> The Windows API uses WORD, DWORD, POINT, etc to avoid the specifics of
|> exactly how long the damned integer is anyway, and a good thing too.
|>
|> As for being 64 bit internally, the Intel, MIPS, AXP, and any other
|> code is exactly the same source code (low level hardware dependencies
|> excepted). Just to make sure, I'll say it again: no matter what the
|> hardware platform is, the source code for Windows NT is exactly the
|> same. The only differences are hardware dependencies that applications
|> can't see anyway: VM management, bus interfaces, etc.
agreed, one thing to add is the distinction between 64 bit addressing
and 64 operations. I believe that Alpha is always in 64 bit address/data
mode. The R4x00 allows any combination of 32/64 bit addressing and operations
for privilege code, however only either 32 bit addressing/data or
64 bit address/data for user code. 64 bit address support requires some
work in the area of object file format and linker/loader, however
it would be simple to have 32 bit address space and 64 bit operands.
-anoosh
P.S. standard disclaimer.....
Jim Stewart
>
>
>I'll answer several notes at once.
>
>
>>
>>Q: Does the Alpha Intel emulation *emulate* the x87 fpu or does it
>> translate x87 fpu functions to alpha x87 functions ?
>>
>>-- Dave Duling "dul...@niehs.nih.gov"
>
>My memory tells me I've seen __int64 declarations in the compiler.
>Maybe someone who uses the compiler a bit more often than I do at the
>moment would like to be more reassuring.
>
>The AXP architecture doesn't have any "x87 functions". If you mean sin,
>cos, sqrt, etc, it doesn't have any of those, either. So I suppose the
>answer is that it emulates the x87 fpu. As far as "normal" floating
>point stuff goes (multiply, divide, etc), I'm not sure about the x87
>floating point format. Any takers?
>
The Alpha Architecture specifies five *in memory* floating point formats:
IEEE Short Float (32 bits - Alpha S_FLOAT)
IEEE Long Float (64 bits - Alpha T_FLOAT)
VAX F_FLOAT (32 bits)
VAX D_FLOAT (64 bits)
VAX G_FLOAT (64 bits)
The 80387 supports two *in memory* floating point formats:
IEEE Short Float (32 bits)
IEEE Long Float (64 bits)
In addition, the 80387 has an onchip Temp Float format of 80bits. It also
has limited support for 32 bit and 64 bit integer operations.
WRT the question, there are two answers. For native WNT applications, the
compiler can generate Alpha Floating point instructions. For old intel
binaries, it must emulate BOTH the 80x86 and the 80x87... the performance
old applications see depends on how much time they spend in
(emulated) application code verses time spent in (native) system calls.
This makes it hard to predict, but I would suspect that an application
that made heavy use of the 80387 would be a prime candidate for a recompile.
> [more good stuff deleted...]
js who_thinks_floating_point_is_for_pipe_stress_weenies_anyway_:)
Harald Henkel
In article <24t1d3$c...@vanbc.wimsey.com>, ste...@vanbc.wimsey.com (Jim Stewart) writes:
[lots of stuff deleted...]
> WRT the question, there are two answers. For native WNT applications, the
> compiler can generate Alpha Floating point instructions. For old intel
> binaries, it must emulate BOTH the 80x86 and the 80x87... the performance
> old applications see depends on how much time they spend in
> (emulated) application code verses time spent in (native) system calls.
> This makes it hard to predict, but I would suspect that an application
> that made heavy use of the 80387 would be a prime candidate for a recompile.
^^^^^
Any program that uses 80387 instructions und thus presumably 80386 instructions
MUST be recompiled to run on NON-Intel architechtures, because the Intel emulation
included there emulates up to 80286/7 (which means 16 bit) only.
But, in fact, I think you know that and just mistyped it.
Harald Henkel,
student of computer science at Technische Universitaet Muenchen (Germany).
Jim Stewart
Harald is correct.
The emulator is an 80286 emulator. This is also the reason that
old Win16 binaries must run in Standard mode on ALPHA and on MIPS.
Sorry for the confusion... my fingers seem to think for themselvs
after around 4:00 AM ...:)
js who_has_a_cat_that_types_better_than_he_does_:)