implementation of unsigned addition on one's complement machines

[Luca Forlizzi]

In 2's complement, the same add/sub hardware instruction compute the
correct result for both signed and unsigned addition (although on
MIPS, for instance, there are separate instructions so that signed add
can generate overflow).
How unsigned addition is implemented in one's complement CPUs? the
instrucitons performing add in one's complement do not produce the
correct result for unsigned addition. Do such CPUs have distinct add
instructions for signed and unsigned operands?

LF

 

[Markus Wichmann]

In 2's complement, the same add/sub hardware instruction compute the
correct result for both signed and unsigned addition (although on
MIPS, for instance, there are separate instructions so that signed add
can generate overflow).
How unsigned addition is implemented in one's complement CPUs?

You want me to draw a full adder here?

the
instrucitons performing add in one's complement do not produce the
correct result for unsigned addition. Do such CPUs have distinct add
instructions for signed and unsigned operands?

They should have, as the logic behind it is a bit different. However,
your question does not have anything to do with C. I suggest you head to
the proper assembly group for your machine.

LF

Markus

 

[James Kuyper]

You want me to draw a full adder here?


They should have, as the logic behind it is a bit different. However,
your question does not have anything to do with C. I suggest you head to
the proper assembly group for your machine.

If he had such a machine, he could find out the answer more directly by
examining the code generated by the compiler. He's not asking about any
specific machine, but about all machines of a rather obscure type.

If you could recommend a specific machine as an example of this type, so
that he could go to a forum associated with that machine, that would go
a long way toward answering the question.

 

[Luca Forlizzi]

You want me to draw a full adder here?


They should have, as the logic behind it is a bit different. However,
your question does not have anything to do with C. I suggest you head to
the proper assembly group for your machine.

I apologise if my question is OT. As James Kuyper said my question is
not about a specific machine, and of course I am not asking for
internal details of an ALU.
As many, I am used to the fact that (in commonly used CPUs) an add
instruction compute a result which is correct either if the operands
are unsigned values or 2 complement values. While studying 1's
complement, I suddenly realized that the instruction which compute the
sum of two ones' complement operands cannot be used to compute the
result of two unsigned operands, and that this pose a problem to a C
implementation. How, in general is it solved?
My guess is that the problem is in general solved by the CPUs by
providing 2 distinct add instructions (or types of instructions), one
for unsigned numbers and one for signed ones.
Am I right? If not, it is the C implementation that has to deal with
the issue, but how (in such case I believe my question to be entirely
topical)?

 

[BartC]

As many, I am used to the fact that (in commonly used CPUs) an add
instruction compute a result which is correct either if the operands
are unsigned values or 2 complement values. While studying 1's
complement, I suddenly realized that the instruction which compute the
sum of two ones' complement operands cannot be used to compute the
result of two unsigned operands, and that this pose a problem to a C
implementation. How, in general is it solved?
My guess is that the problem is in general solved by the CPUs by
providing 2 distinct add instructions (or types of instructions), one
for unsigned numbers and one for signed ones.
Am I right? If not, it is the C implementation that has to deal with
the issue, but how (in such case I believe my question to be entirely
topical)?

The compiler will generate whatever instructions are necessary to perform
the task. Sometimes there is hardware support, sometimes there isn't, but
that's the sort of problem that compilers solve.

For example, even with two's complement, signed and unsigned numbers need
different multiply and divide instructions. A processor may not even have a
multiply instruction, or if it has, it might only be for unsigned, or it
might only be for 16 bits and you need 32 bits, and so on.

I don't know of any machine with one's complement, but signed magnitude is
fairly common (for floating point for example). In the latter case, the
instruction will know whether the number is positive or negative (the number
is always signed). For two's complement, the same number might be signed or
unsigned, so different instructions have to be used. Add/subtract are the
same, but any flags which are set need to be interpreted in a different way.

 

[Roberto Waltman]

Luca Forlizzi wrote:

(Interesting question on 1's complement arithmetic deleted)

The right group for this would be comp.arch.arithmetic
Unfortunately, it is dead.
comp.arch and alt.folklore.computers are plan B and plan C.

 

[Luca Forlizzi]

Luca Forlizzi  wrote:

(Interesting question on 1's complement arithmetic deleted)

The right group for this would be comp.arch.arithmetic
Unfortunately, it is dead.
comp.arch and alt.folklore.computers are plan B and plan C.

--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

Thanks Roberto, I have just tried plan B