Kang Su Gatlin - On the 64-bit Whiteboard

Unless I'm missing something, those last two problems mentioned in the video don't seem like problems at all (besides the code being messy). Since integers and longs remain 32-bit, there should be no problem comparing one to 0xFFFFFFFF or masking 0x80000000. There would be a problem when doing this with pointers, but who in there right mind would mask or hardcode a pointer like that?

Let me know if I missed the point.

What I really want to know is where to find out about these semantics, as it would be very handy.

I.E.

int x = -30;
unsigned int y = 20;

(x + y) gives an unsigned int???

Buzza wrote:

What I really want to know is where to find out about these semantics, as it would be very handy.

For a start you could try page 73 of The C++ Programming Language, although I expect it is in the spec somewhere.

In Section 4.10, advice item [18] is:

"Avoid unsigned arithmetic"

:)

As a matter of policy, I would avoid unmanaged code in a 64-bit environment.  Of course, there is the porting problem.  People can and do write code with pointers and employing pointer arithmetic; that was peachy in the time, long past, not far removed from assembly language, where any geeky method to save a few CPU cycles or bytes of memory was smiled upon.

Any time the underlying architecture changes, in some fundamental way, these insects fall out of the woodwork.  Mercy, with the high level of abstraction now possible, can't we stop revisiting this stuff?

Probably the most educational video I've seen here yet; I guessed 15 too   But I've never worked on 64-bit procs.  I'd like to see more videos involving logic problems and what happened to fix it.

Beer, this actually isn't a function of the chip architecture, but rather of the high-level language.  In a different language the result of (sign + usign) may have a different type, in which case the result would be different, even on the same machine.

Hope that helps.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

OK, I think I see what you're asking.

No, we actually didn't do this to get the extra bit.  It's because C/C++ standard says that sign + usign is unsign, and thus when we add an unsigned value to a pointer we don't sign-extend (as the value is not negative), but we would sign extend if the type was signed. 

Now maybe what you mean is that we should just always treat 64bit integral values as signed.  The problem with that is that there are 64-bit types besides pointers (such as __int64) and you want to make sure that properies that people may expect with unsigned values are preserved. 

Such as, for all bit representation x, (if x != 0) => x > 0. 

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

This was one of the coolest, most authentic, most informative technical discussions recorded for Channel9 I have ever seen.

Check out, I believe, section 4.6 of the C++ Standard on Integral Promotion. 

I have the K&R C book in front of me so it's easier to quote from the reference section of the text... "If an int can represent all the values of the original type, then the value is converted to an int; otherwise the value is converted to an unsigned int.  This process is called integral promotion".

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

So, when compilers went from 16 bit to 32 bit, 'int' was redefined to be 32 bit in stead of 16 bit.  Why is it now that in the migration from 32 bit to 64 bit, 'int' is still 32 bit?

gdesroches wrote:

Unless I'm missing something, those last two problems mentioned in the video don't seem like problems at all (besides the code being messy). Since integers and longs remain 32-bit, there should be no problem comparing one to 0xFFFFFFFF or masking 0x80000000. There would be a problem when doing this with pointers, but who in there right mind would mask or hardcode a pointer like that?

Let me know if I missed the point.

...how about the Windows CE kernel.  It checks the MSB (by comparing 0x80000000) to see if memory is kernel memory or user memory.  That's even Microsoft code.  Admittedly, though, it is platform specific code anyway and it will be a while longer before CE devices start switching to 64 bit.

Interesting thematic here is discussed. I am interested in similar issues. My new article about 64-bit development:
20 issues of porting C++ code on the 64-bit platform.

http://www.viva64.com/articles/20%20issues%20of%20porting%20C++%20code%20on%20the%2064-bit%20platform.pdf

I am expecting this may be interesting for you.

 

Matt Pietrek. Everything You Need To Know To Start Programming 64-Bit Windows Systems.
	It is described some main features of 64-bit version of Windows and some its reasons. There are 16 terabytes of adressed memory, new data types, the file format, DEP, table-based exception handling, new APIs, the WOW64 subsystem, using the GS register instead of the FS register, PatchGuard technology among them. Also the basic principles of the x64 CPU architecture are reviewed. Author tell how to write and debug x64 code using Microsoft Visual Studio 2005®, show main troubles on this way: using incorrect data types for pointers, printf and sprintf formatting and gives some advices to overcome them.
John Paul Mueller. 24 Considerations for Moving Your Application to a 64-bit Platform.
	It is briefly reviewed 24 important conditions for successfully porting application to a 64bit platform. The characteristic property of the article is that these conditions are independent on specific programming language or platform. The stated ideas are tested by author in practice. Some code examples are presented.
Microsoft Game Technology Group. 64-bit programming for Game Developers.
	It is considered main differences between 32-bit platforms and 64-bit ones and some potential 64-bit compatibility traps. Also it is told about porting application to 64-bit platform. Several main porting issues such as pointer truncation, data types and alignment, assembly code are briefly explained. Also some words about profiling and optimization on 64-bit platform are told. A number of MSDN links on the theme of conversation are listed.
Andrey Karpov. The forgotten problems of 64-bit programs development.   Though the history of 64-bit systems development makes more than a decade, the appearance of 64-bit version of OS Windows raised new problems in the sphere of development and testing applications. In the article there are considered some mistakes connected with 64-bit C/C++ code development to Windows. The reasons are explained according to which these mistakes didn’t find their reflection in the articles devoted to the migration tasks and are unsatisfactorily detected by the majority of static analyzers. Tim Mangan. Porting C++ Applications to x64.
	This white paper is devoted to process of porting applications to 64-bit platforms (Intel EM64T and AMD x64 processors are considered). It is shortly reviewed some reasons to porting your application. Several cases when a port is necessary are listed. Also it is described some features of 64-bit platforms in general, and 64-bit version of Windows especially. Process of porting application using MS Visual Studio 2005 is in detail described. Also it is told about some troubles on this way.
Bill O'Brien. Widen Your Opportunities with 64-Bit Compilers: Introduction - 64 Bits or Bust.
	In this paper it is considered brief history of 64-bit platforms. Some existing Microsoft 64-bit Oses and links to some useful documents are listed. It is shortly described several compilers and IDEs that allow to create 64-bit application or to port exisiting software to 64-bit platform. These are the Microsoft Visual Studio, PGI compilers, GCC and others.

Andrey Karpov. Problems of testing 64-bit applications.
	The article observes some questions related to testing the 64-bit software. Some difficulties which a developer of resource-intensive 64-bit applications may face and the ways to overcome them are described.

Evgeniy Ryzhkov. Viva64: what is it and for whom is it meant?
	This short paper is a quick overview of the Viva64 project.

20 issues of porting C++ code on the 64-bit platform.
New location:

Andrey Karpov, Evgeniy Ryzhkov. 20 issues of porting C++ code on the 64-bit platform.
	Program errors occurring while porting C++ code from 32-bit platforms on 64-bit ones are observed. Examples of the incorrect code and the ways to correct it are given. Methods and means of the code analysis which allow to diagnose the errors discussed, are listed.