Decreasing order of address within main

[Phil Carmody]

On Sat, 26 Sep 2009 10:47:58 +0300, Phil Carmody wrote:

[UNSNIP - "At the CPU level ... "]

With two's complement, addition, subtraction and multiplication (but not
division) behave identically for signed or unsigned values.

Full- (or double-, depending on your PoV) width multiplies are different
too. ff*ff = 0001 or fe01.

My PoV is "double-".

In C

Nah, doesn't wash. We were at the CPU level, if you remember.

, int * int -> int, long * long -> long, and so on.

Once the types have been promoted, it makes no difference as to their
signedness. OTOH, the promotion is affected by the signedness.

Apart from division, the only common instruction which has signed and
unsigned variants is a right shift.

And multiply.

True for x86's double-width multiply, but how many architectures have that
feature?

Well, the first processor I used that had a multiply instruction had both
signed and unsigned. The architecture I've used the most since then also
had this pair. The two other architectures I've used extensively in that
time also have them. Of the two other architectures I've used but not
extensively programmed for, one didn't have a muliply at all, the other
had both types. Only one architecture I've used that has a multiply
instruction at all fails to have the pair. [snip summary]

The point is that to supply C semantics the architecture
needs to provide only one multiply instruction (if 2's
complement representation is used). Presumably the
architectures you mentioned either weren't using
2's complement, or had separate instructions to
set overflow/carry flags differently (or for some
other multiple-precision arithmetic capability).

Close. Your presumptions are true for 4 of the 5 archs.

I thought it was implied that I wasn't including the
case where the processor had no multiply instructions
at all.

Jeebus. I never thought that _you_ would be >this< close to being
stuffed in my killfile. Please learn to count before posting to
usenet again.

Phil

 

[Tim Rentsch]

On Sat, 26 Sep 2009 10:47:58 +0300, Phil Carmody wrote:

[UNSNIP - "At the CPU level ... "]

With two's complement, addition, subtraction and multiplication (but not
division) behave identically for signed or unsigned values.

Full- (or double-, depending on your PoV) width multiplies are different
too. ff*ff = 0001 or fe01.

My PoV is "double-".

In C

Nah, doesn't wash. We were at the CPU level, if you remember.

, int * int -> int, long * long -> long, and so on.

Once the types have been promoted, it makes no difference as to their
signedness. OTOH, the promotion is affected by the signedness.

Apart from division, the only common instruction which has signed and
unsigned variants is a right shift.

And multiply.

True for x86's double-width multiply, but how many architectures have that
feature?

Well, the first processor I used that had a multiply instruction had both
signed and unsigned. The architecture I've used the most since then also
had this pair. The two other architectures I've used extensively in that
time also have them. Of the two other architectures I've used but not
extensively programmed for, one didn't have a muliply at all, the other
had both types. Only one architecture I've used that has a multiply
instruction at all fails to have the pair. [snip summary]

The point is that to supply C semantics the architecture
needs to provide only one multiply instruction (if 2's
complement representation is used). Presumably the
architectures you mentioned either weren't using
2's complement, or had separate instructions to
set overflow/carry flags differently (or for some
other multiple-precision arithmetic capability).

Close. Your presumptions are true for 4 of the 5 archs.

I thought it was implied that I wasn't including the
case where the processor had no multiply instructions
at all.

Jeebus. I never thought that _you_ would be >this< close to being
stuffed in my killfile. Please learn to count before posting to
usenet again.

By all means, please add me to your killfile if that's what
you think is appropriate. To save you some trouble, let me
add that if you're hoping I'll get better at understanding
your rather elliptical commentary, it's probably better not
to wait for that.

 

[Dik T. Winter]

> Dik T. Winter wrote:
>
>
> I think that's the Transputer, not the ARM.

I think you are right.

 

[Dik T. Winter]

....
> Jeebus. I never thought that _you_ would be >this< close to being
> stuffed in my killfile. Please learn to count before posting to
> usenet again.

Let's count:
#1 had both variants
#2 also had this pair
#3 and #4 also have them
#5 had no multiply at all
#6 had both types
#7 has multiply but only one type

So I come at 5 out of 6.

 

[Tim Rentsch]

[ My apologies for the flood of delayed responses; my old news server
was silently eating all my posts for the last week or so.]

Any sufficiently aggressive optimizer can choose to make such
optimizations /if/ they're consistent with other decisions made
by the implementation, but not every implementation will make
decisions that allow such optimizations. Just because the
Standard declares a certain behavior as undefined doesn't mean an
implementation will choose not to define it. The optimizer is
subject to the whims of the implementation, not the other way
around.

At least in the case of Linux, the decisions made by (or "the whims of")
the GCC team are a fundamental part of defining that implementation.
The ABI is an output from that process, i.e. it's just documentation of
what GCC et al do, not an input to that process...

Linux is not a C implementation. GCC plus an appropriate library
is a C implmentation. It happens that one of these pairings (of
gcc plus a library) runs on top of linux, but linux is not any
part of the C implmentation, it's just the substrate on which the
C implementation does its work.

As for gcc -- I understand that some implementations make
behavioral decisions based on what's convenient for the optimizer,
and gcc may be one of those. Even so, the decisions belong to the
implementation, not the optimizer; if some fancy optimizer were
transplanted into a different implementation, any changes in
implementation-chosen behavior would require adjustments to the
optimizer -- otherwise it's not the same implementation.