Re: Why the compiler applies sign extension to unsigned data?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Alberto wrote:
Even from the very purist point of view of the C language standard, it
takes a VERY peculiar processor architecture to allow negative memory
addresses. And even then, sometimes sheer pragatism must win the day.
Besides, we're talking about drivers on a proprietary programming
environment - that is, the Microsoft DDK - and not about an Ansi
standard user-side C program.


The purist C point of view is that the operation of casting a pointer to
an integral type larger than the size of a pointer is an undefined
operation with an undefined result (except that casting back to a
pointer recovers the original value), not that it should sign extend or not.

Another view is to see the expression (__int64)(p1) as equivalent to the
expression (__int64)(p1 - (T*)NULL), and (p1 - (T*)NULL) is a variant
of (p1 - p2) which is signed ptrdiff_t to handle the ordinary case of
(p1 < p2).


In the case of the i386, segments have unsigned base, offset and
limit. I just fail to see the need for signed pointers.

The need originates in the original 2G/2G split between user mode and
kernel mode addresses, and the equivalent half/half split on all the
other architectures (including 64 bit ones). This makes signed pointers
convenient for operations that deal with this address space split in
various ways. As a matter of fact the x64 architecture explicitly deals
with signed 64 pointers at the hardware level, implementing only some of
the less significant bits (48 bit on one CPU model, other counts on
other models) and requiring (at the hardware level) that valid addresses
must be the valid 64 bit sign extension of the actually implemented 48
bit addresses.

It is also worth noting that when NT 4.0 SP3 introduced the option to
run with a 3G/1G address split on the i386, access to the extra 1G of
user space was enabled only for .exe files that were marked by their
authors with a special PE file header bit to indicate that none of its
code would get confused by negative addresses. There were also articles
on MSDN about how to make sure your code would not have a problem.

There's a fair
amount of functionality in the Microsoft compiler that isn't Ansi
compatible; pointers that are seen as having a sign bit could easily
be implemented to be so only if the Ansi switch is on.

I don't think ANSI C *requires* the signed pointer behavior, it just
permits it.


And, just to refresh our memories, Zhongsheng's original point was
that this sequence

ULONG ulData = 0x80000000;
unsigned __int64 ullData = (unsigned __int64)ulData;

produced a sign extension. I don't see why a compiler would sign
extend a data movement between two unsigned values, but hey, others
may disagree.

The compiler does not do that, as seen in Maxim's reply to the first
post. Zhongsheng corrected his example in his second post and Maxim
commented on that in his reply to that second post.

--
Jakob Bøhm, M.Sc.Eng. * jb@xxxxxxxxxx * direct tel:+45-45-90-25-33
Netop Solutions A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Netop
Solutions A/S, only the personal opinions of the author.
.

Relevant Pages

  • Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocatio
    ... AFAIK, the only requirement we have for, e.g. tracepoints, is to align on the ... pointer size ), so RCU pointer updates are performed atomically. ... Aligning on the pointer size also allows the architecture to efficiently read ... Ideally, I'd like to avoid letting gcc up-align a structure, because it is then ...
    (Linux-Kernel)
  • Re: How much did the AS/400 influence the C standard?
    ... AS/400 is not the only architecture ever envisioned with tagged ... So the '400 isn't even the only IBM platform to ... It also seems to me that the proponents of relaxed rules for pointer ... where illegal pointer subtraction give inconsistent results, ...
    (comp.std.c)
  • Re: De-referencing NULL
    ... there are indeed memory-mapped I/O registers in the ... some way incompatible with the architecture, which is a really weird thing. ... is not guaranteed to produce a null pointer. ... I doubt that this would be a good idea on balance, though such a compiler ...
    (comp.lang.c)
  • Re: Printf("%d")
    ... If the same pointer happened to be on the stack ... in memory -- -13361016 is just a bit too random for that. ... memory addresses happens to be reserved in this architecture. ...
    (comp.lang.c)