Kang Su Gatlin - On the 64-bit Whiteboard | TheChannel9Team

gdesroches

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.

Charles
Welcome Change

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.

Who in their right mind forgets to check buffers? Who in their right mind forgets to validate input? Who's in their right mind, anyway?

This is a pattern that does exist for better or for worse: mistakes are made.

As was mentioned in the video, there once was a time when programmers were required to do apparently stupid things to wring as much perf as possible out of the platform upon which they made their daily bread.

C

Buzza

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???

Rossj

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"

:)

earnshaw
Jack Sleeps

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?

SlackmasterK
I write my OWN blogging engines

Probably the most educational video I've seen here yet; I guessed 15 too Sad

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.

KSG

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

KSG

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

rasx
Programmer/Analyst III, Emperor of String.Empty

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