A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » Processors » AMD x86-64 Processors
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Interesting read about upcoming K9 processors



 
 
Thread Tools Display Modes
  #241  
Old August 20th 04, 07:13 AM
Roger Binns
external usenet poster
 
Posts: n/a
Default

Dean Kent wrote:
Windows implementation? Also, out of curiosity (as I don't work on
Windows), are there updated APIs for 64-bit applications that are
backwards compatibile with the 32-bit ones - or has MS somehow
designed their interfaces/control blocks/etc. so that this isn't a
concern?


Short answer is yes. Long answer follows:

Microsoft of all companies is very proficient at word size changes,
backwards compatibility, and API design borne of necessity rather
than purist design.

These are the transitions they went through:

- 8 bit to 16 bit (early machines, Basics, cloning CP/M)
- 16 bits with slightly wider memory (DOS, extended memory, 286
and 386 flavours of early Windows 1/2)
- 16 to 32 bits (but mostly 16) in Windows 3
- 32 bits with lots of 16 (Windows 95)
- "Clean" design 32 (Windows NT)
- 32 bits with longer addresses (PAE, Alpha, MIPS)
- 64 bits (Itanic, AMD64)

In general a binary is marked for a particular subsystem/version
which implies sizes. When the underlying OS uses a different
size various thunking or stub mechanisms are used to translate
to the right sizes, as well as lots of backwards compatibility
shims.

Note that backwards compatibility doesn't just mean theoretically
pure. It also means bugs or other behaviour. For example Windows
95 specifically recognised the Windows 3 version of SimCity which
had a bug that used memory just after it had been freed. They
run the memory manager in a different mode that ensures no crash
happens.

I recommend reading the historical articles in Raymond Chen's blog.

http://weblogs.asp.net/oldnewthing/c....aspx?Show=All

A selection:

Why 16-bit DOS and Windows are still with us
http://weblogs.asp.net/oldnewthing/a.../01/82103.aspx

History of calling conventions:
http://weblogs.asp.net/oldnewthing/a.../02/47184.aspx
http://weblogs.asp.net/oldnewthing/a.../07/48303.aspx
http://weblogs.asp.net/oldnewthing/a.../08/48616.aspx
http://weblogs.asp.net/oldnewthing/a.../13/58199.aspx
http://weblogs.asp.net/oldnewthing/a.../14/58579.aspx

Sometimes an app just wants to crash:
http://weblogs.asp.net/oldnewthing/a.../19/44644.aspx

When programs grovel into undocumented structures:
http://weblogs.asp.net/oldnewthing/a.../23/45481.aspx

Why not just block the apps that rely on undocumented behaviour:
http://weblogs.asp.net/oldnewthing/a.../24/45779.aspx

Why are structure sizes checked strictly:
http://weblogs.asp.net/oldnewthing/a.../12/56061.aspx

What do the letters W and L stand for in WPARAM and LPARAM?
http://weblogs.asp.net/oldnewthing/a.../25/55850.aspx

What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?
http://weblogs.asp.net/oldnewthing/a.../15/55296.aspx

Why is address space allocation granularity 64K?
http://weblogs.asp.net/oldnewthing/a.../08/55239.aspx

My all time favourite about why Win95 didn't use the HLT instruction:
http://weblogs.asp.net/oldnewthing/a.../28/54719.aspx

Roger


  #242  
Old August 20th 04, 08:13 AM
David Brown
external usenet poster
 
Posts: n/a
Default


"Dean Kent" wrote in message
...
"David Brown" wrote in message
...


Porting applications, on the other hand, is far easier. You have to
consider the effect of having 64-bit integers, and you might have to
consider endian issues, but mostly (if the original code is

well-written)
its a matter of re-compiling and testing the new binary.


Well, I am not an OS developer - but I do work on system level

applications
(requiring hooks into the OS, use of low-level OS services, etc.). It
seems to me that the biggest problem for the OS is the compatibility with
existing applications. There will be control blocks (structures,

whatever)
and APIs that include addresses to data areas, calls to communicate with
other programs, etc. You can't just change the size of the address areas
for two reasons - the offsets for following data areas would change
(requiring all applications using that structure/control block to be
recompiled), and you have no idea if the applications using it can

actually
use the 'bigger' addresses. It also seems to me that you would have to
include a mechanism whereby the OS knows whether the application is

running
32-bit or 64-bit to make sure it doesn't allocate memory where the
application can't access it - and it can't load the program in an address
range it can't handle. The calls to other modules would have to include

a
mechanism whereby programs running in different addressing modes can still
pass parameters and data to each other without causing major problems and
crashes.

IOW, moving an OS to 64-bit would not only require changing integer sizes
and recompiling, but actually redefining the interfaces to work with both
32-bit and 64-bit programs (perhaps even mixed addressing modes). Making
sure all of this works would be a huge undertaking, and could create
situations where 95% of the code works fine, but a few critical apps have
major problems that delay the OS release.


That's all very true - that's more reasons to back up my "porting an
applicaiton is relatively easy, porting an OS is hard" post. The OS has to
sit between the hardware and the apps - I only mentioned that the low-level
stuff was hard to port, but you are correct that there are issues on the app
side to consider. Hence Win-on-win for 16-bit app support on 32-bit WinNT,
and 32-bit loaders and libraries as well as 64-bit versions on 64-bit linux
and Win64.

Backwards compatibility matters, particularly in an environment where the

OS
vendor has support issues to deal with and wants to control what is

running
in the field. It may not be as big an issue with Linux (or may be),

since
there are no support issues to deal with and there is no attempt to

control
what is running in the field. "Want a 32-bit OS? Fine, run an older
kernel - or someone else's 64-bit kernel that has support for it."


Most people get their linux from OS vendors - what else would you call
Mandrake, Suse (Novell), Red Hat, etc. ? Support and backwards
compatibility is a big issue - in the linux world, if something works then
people use it, they don't re-write it and expect people to pay for upgrades
just that it will run on the latest version of your OS. There are programs
in continuous use in linux systems (and any other *nix system) that haven't
been changed in years - decades, maybe - simply because they already do the
job they were meant to do. Most of these can, of course, be simply
re-compiled at 64-bit for a 64-bit linux, but there are certainly plenty of
occasions when you would want to run 32-bit binaries on 64-bit linux.

At least, it works that way in the environment I am familiar with (not
Windows or Unix... :-).

Regards,
Dean




  #243  
Old August 20th 04, 08:24 AM
Roger Binns
external usenet poster
 
Posts: n/a
Default

Thor Lancelot Simon wrote:
In article ,
Ken Hagan wrote:
Nick Roberts wrote:

I don't think that's strictly correct. My memory is that Windows 95
was itself the first Windows which supported 32-bit code, when it
was launched (in 1995 ;-) The immediately prior version of Windows
was
3.11, which was 16-bit only (and ran on top of MS-DOS).


The first version of NT (1991?) called itself Windows 3.1. It had its


No.


The first version of NT was released in 1993 and was called Windows NT 3.1.

http://www.microsoft.com/presspass/f...98/winntfs.asp

Details and screenshots of all Windows releases are at
http://www.microsoft.com/windows/Win...roGraphic.mspx
http://www.microsoft.com/windows/WinHistoryDesktop.mspx

Roger


  #244  
Old August 23rd 04, 02:07 AM
Stephen Sprunk
external usenet poster
 
Posts: n/a
Default

"Douglas Siebert" wrote in message
...
(Patrick Schaaf) writes:

Casper H.S. Dik writes:


"Stephen Sprunk" writes:
AMD64 is just another platform, and the third (or higher) platform
supported
is of marginal cost compared to the second. The free software world has
had
to contend with dozens of platforms for over two decades, and so the
fact
Linux (and all the common apps) ported over cleanly is hardly
surprising.


It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries.


There are a few, yes, but most of the folks developing Linux couldn't care
less if they cause closed-source developers a little pain. I haven't heard
any complaints about problems running i386 binaries on amd64 kernels, so it
appears to be a non-issue -- unlike with WinXP64.

I don't see many of them on the ~1000 Linux systems I've got at work.
There are bound to be some commercial apps where that's the case,
but I'm sure Stephen was thinking about the ease for
_open_source_software_
to be ported over.


Actually, it applies to commercial software too. I worked at a company
where the main product (an embedded OS) was shipped on a dozen different CPU
types and once the cost of porting was paid (over a decade ago) for the
second arch, the cost of adding a new arch was nearly zero.

The key is making sure all new code is written portably, which so far has
not been necessary in the Windows world. Some ISVs may decide it's cheaper
to develop non-portable code over time; they'll pay dearly for porting once
a decade and usually drop support for the older arch (as happened in the
Win16-to-Win32 conversion).

Do the AMD64 versions of Redhat and SuSE recompile everything? It seems
kind to silly to have a 64 bit /bin/ls, for instance. They always left
most stuff for which performance didn't matter compiled as i386, and for
stuff where performance mattered (the kernel, openssl libraries, etc.)
there were i686 versions. I would assume it is the same way for AMD64
stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have
to do a lot more versions if they bugfix /bin/ls and have to compile a
64 bit version to go along with the i386 version!


If /bin/ls were patched, somebody has to recompile it for dozens of other
platforms, so what's the marginal cost in recompiling for amd64? It seems
to be less than the cost of deciding which binaries on an amd64 installation
should be kept as i386 and compiling your distribution appropriately.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

  #245  
Old August 23rd 04, 11:25 PM
Nate Edel
external usenet poster
 
Posts: n/a
Default

In comp.sys.intel David Brown wrote:
Win32S was available before Win95, as was NT 3.51 (I believe NT 3.5 was the
first easily-availble version of NT - marketing's idea of persuading people
that it was a mature product).


NT 3.1 was the first version available, with the 3.1 selected to be in
parallel with the version of (non-NT) Windows available at the time.

not support multi-tasking. It was mainly used for "big" programs, like CAD,
or development tools, which could take advantage of the better memory
management.


And for a lot of the Windows 3.x web browsers. I remember deploying a ton
of copies of Win32s so the lawyers I was supporting could use some
now-archaic version of netscape while the higher-ups in IT planned how to
transition to Win 95 (and then to WinNT 4, which was what we ended up moving
to, right around when I left.)

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

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Harddisks: Seek, Read, Write, Read, Write, Slow ? Marc de Vries General 7 July 26th 04 02:57 AM
AMD Processors - HELP! Sseaott Overclocking AMD Processors 1 June 15th 04 09:13 AM
AMD Processors - HELP! Sseaott AMD x86-64 Processors 0 June 15th 04 03:33 AM
Please Read...A Must Read Trini4life2k2 General 1 March 8th 04 01:30 AM
Seagate SATA 120GB raw read errors Kierkecaat General 0 December 16th 03 03:52 PM


All times are GMT +1. The time now is 10:35 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.