From Newsgroup: comp.arch

According to Thomas Koenig <tkoenig@netcologne.de>:

If you go back to the early to mid 1960s, in the mainframe era, at least
the IBM S/360 series and the Univac 1100 series only had signed
numbers.

I don't know about Univac, but the S/360 certainly supported unsigned >arithmetic. They even had two versions of add instructions, which seems >strange for a two's complement machine, but they set flags differently,
of which the /360 had too few.

More important, signed add and subtract can trap on overflow, unsigned
can't. The unsigned condition codes tell you whether there was a carry
which makes multiple precision artithmetic a lot simpler.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

John Levine <johnl@taugh.com> writes:

According to Thomas Koenig <tkoenig@netcologne.de>:

the S/360 certainly supported unsigned
arithmetic. They even had two versions of add instructions, which seems >>strange for a two's complement machine, but they set flags differently,
of which the /360 had too few.

More important, signed add and subtract can trap on overflow, unsigned
can't.

I dimly remember (coreectly?) that there is a way to disable the
trapping.

The unsigned condition codes tell you whether there was a carry
which makes multiple precision artithmetic a lot simpler.

S/360 has no add with carry-in. That was only added in ESA390. So multi-precision integer arithmetic on S/360 is similarly complicated
as on MIPS or RISC-V.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

John Levine <johnl@taugh.com> writes:

According to Thomas Koenig <tkoenig@netcologne.de>:

the S/360 certainly supported unsigned
arithmetic. They even had two versions of add instructions, which seems >>>strange for a two's complement machine, but they set flags differently, >>>of which the /360 had too few.

More important, signed add and subtract can trap on overflow, unsigned >>can't.

I dimly remember (coreectly?) that there is a way to disable the
trapping.

Right. Four of the PSW bits were the program mask, which controlled
trapping for fixed overflow, decimal overflow, exponent underflow,
and floating point significance. The unprivledged SPM instruction
set the mask bits.

The unsigned condition codes tell you whether there was a carry
which makes multiple precision artithmetic a lot simpler.

S/360 has no add with carry-in. That was only added in ESA390. So >multi-precision integer arithmetic on S/360 is similarly complicated
as on MIPS or RISC-V.

Also right, you had to test the condition code and propagate the carry yourself. It took 30 years before they added add-with-carry so it
evidently wasn't urgent. It was added to zArchitecture and then
backported to the ESA/390 mode on z.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

John Levine <johnl@taugh.com> writes:

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

S/360 has no add with carry-in. That was only added in ESA390. So >>multi-precision integer arithmetic on S/360 is similarly complicated
as on MIPS or RISC-V.

Also right, you had to test the condition code and propagate the carry >yourself. It took 30 years before they added add-with-carry so it
evidently wasn't urgent. It was added to zArchitecture and then
backported to the ESA/390 mode on z.

So, even later than ESA/390. Interestingly, the IBM 704 has add with
carry-in. My guess is that they already had the hardware thanks to sign-magnitude representation (which is implemented as ones-complement
with additional inversion steps AFAIK), so why not provide an
instruction. Or maybe the S/360 architects just thought so, and
considered carry-in just a piece of baggage from
sign-magnitude/1s-complement architectures that they wanted to get rid
of.

And I guess that it has not been important for IBM mainframes when
ESA/390 (1990) was designed. Public-key cryptrography only became a
thing with ssh (1995) and SSL 2.0 (1995; SSL 1.0 was never released),
and I expect that in those years the IBM mainframes tended not to be
connected to the Internet, so ssh and SSL were not important for them.
PGP was released in 1991, but adoption has not been strong, and
performance not a big issue; I think that only ssh and especially SSL
made demands for public-key cryptography and therefore multi-precision arithmetics show up on the radar of computer companies.

Similarly, for MIPS (1986) and Alpha (1992), public-key crypto was not
a thing when they were designed. What is more surprising is that
RISC-V designers have acted and are still acting as if it was still
the 1980s.

Overall, the whole flags topic looks like the unloved stepchild of
computer architecture that often is designed in as an afterthought.
This shows in the S/360 dedicating only two bits to flags, so they had
to multiplex their meanings, depending on the setting instructions.
It shows in the fact that RISC-V has no flags, and needs 5
instructions for a carry-in carry-out addition. It shows in PowerPC
and 88000 have a single carry-flag tacked on outside their usual
flag-handling infrastructure, which is ironic, because the carry flag
is the one that has the highest need for several instances, at least
for programming languages like C with short-circuit evaluation.

And it shows in the fact that ARM A64 has only a single condition-code register, with the instructions designed such that it needs separate
renaming from the GPRs; if every instruction that writes a register
sets all the flags and vice versa, the flags can be renamed with the
GPRs (i.e., it would have the same implementation as my extended GPRs,
but the architecture would make flag-reading implicit, and it would
use only the instance from the most recent result). Having flags like
ARM A32/T32 rather than, e.g., what 88000 or IA-64 have was probably
natural for ARM A64, but if they designed it like I suggest above, the
recent implementations without ARM A32/T32 support would be cheaper to implement.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

<snip>

And I guess that it has not been important for IBM mainframes when
ESA/390 (1990) was designed. Public-key cryptrography only became a
thing with ssh (1995) and SSL 2.0 (1995; SSL 1.0 was never released),

DH and RSA developed public key cryptography in the 1970s.

<snip>

Overall, the whole flags topic looks like the unloved stepchild of
computer architecture that often is designed in as an afterthought.
This shows in the S/360 dedicating only two bits to flags, so they had
to multiplex their meanings, depending on the setting instructions.

Note that in 1963, hardware was _expensive_. No LSI or even SSI;
it was all discrete logic.

Note also that in 1963, Burroughs B3500 made the same choice, although
they had three flags (overflow, comparison-high and comparison-low),
which IIRC, were there in the B300 as well.

<snip>

And it shows in the fact that ARM A64 has only a single condition-code >register,

I would argue that it has four, one for each exception level.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

John Levine <johnl@taugh.com> writes:

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

S/360 has no add with carry-in. That was only added in ESA390. So >>multi-precision integer arithmetic on S/360 is similarly complicated
as on MIPS or RISC-V.

Also right, you had to test the condition code and propagate the carry >yourself. It took 30 years before they added add-with-carry so it >evidently wasn't urgent. It was added to zArchitecture and then
backported to the ESA/390 mode on z.

So, even later than ESA/390. Interestingly, the IBM 704 has add with carry-in. My guess is that they already had the hardware thanks to sign-magnitude representation (which is implemented as ones-complement
with additional inversion steps AFAIK), so why not provide an
instruction. Or maybe the S/360 architects just thought so, and
considered carry-in just a piece of baggage from
sign-magnitude/1s-complement architectures that they wanted to get rid
of.

In my opinion, S/360 did not have carry (anywhere) because they (IBM)
thought the decimal arithmetic would handle "long integer" calculations.

And I guess that it has not been important for IBM mainframes when
ESA/390 (1990) was designed. Public-key cryptrography only became a
thing with ssh (1995) and SSL 2.0 (1995; SSL 1.0 was never released),
and I expect that in those years the IBM mainframes tended not to be connected to the Internet, so ssh and SSL were not important for them.
PGP was released in 1991, but adoption has not been strong, and
performance not a big issue; I think that only ssh and especially SSL
made demands for public-key cryptography and therefore multi-precision arithmetics show up on the radar of computer companies.

Similarly, for MIPS (1986) and Alpha (1992), public-key crypto was not
a thing when they were designed. What is more surprising is that
RISC-V designers have acted and are still acting as if it was still
the 1980s.

Overall, the whole flags topic looks like the unloved stepchild of
computer architecture that often is designed in as an afterthought.
This shows in the S/360 dedicating only two bits to flags, so they had
to multiplex their meanings, depending on the setting instructions.
It shows in the fact that RISC-V has no flags, and needs 5
instructions for a carry-in carry-out addition. It shows in PowerPC
and 88000 have a single carry-flag tacked on outside their usual

At the time (88K) we could not figure out multi-word arithmetic without
carry somewhere. SO, we literally tacked it on the side.

flag-handling infrastructure, which is ironic, because the carry flag
is the one that has the highest need for several instances, at least
for programming languages like C with short-circuit evaluation.

And it shows in the fact that ARM A64 has only a single condition-code register, with the instructions designed such that it needs separate
renaming from the GPRs; if every instruction that writes a register
sets all the flags and vice versa, the flags can be renamed with the
GPRs (i.e., it would have the same implementation as my extended GPRs,
but the architecture would make flag-reading implicit, and it would
use only the instance from the most recent result). Having flags like
ARM A32/T32 rather than, e.g., what 88000 or IA-64 have was probably
natural for ARM A64, but if they designed it like I suggest above, the
recent implementations without ARM A32/T32 support would be cheaper to implement.

- anton

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

John Levine <johnl@taugh.com> writes:

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

S/360 has no add with carry-in. That was only added in ESA390. So
multi-precision integer arithmetic on S/360 is similarly complicated
as on MIPS or RISC-V.

Also right, you had to test the condition code and propagate the carry
yourself. It took 30 years before they added add-with-carry so it
evidently wasn't urgent. It was added to zArchitecture and then
backported to the ESA/390 mode on z.

So, even later than ESA/390. Interestingly, the IBM 704 has add with
carry-in. My guess is that they already had the hardware thanks to
sign-magnitude representation (which is implemented as ones-complement
with additional inversion steps AFAIK), so why not provide an
instruction. Or maybe the S/360 architects just thought so, and
considered carry-in just a piece of baggage from
sign-magnitude/1s-complement architectures that they wanted to get rid
of.

In my opinion, S/360 did not have carry (anywhere) because they (IBM)
thought the decimal arithmetic would handle "long integer" calculations.

Burroughs B3500 supported 100-digit decimal arithmetic, yet still
found a need for an overflow flag (most arithmetic was done
on much smaller fields, particularly when running applications
in 20kb of memory in the 1960s).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to MitchAlsup <user5857@newsgrouper.org.invalid>:

In my opinion, S/360 did not have carry (anywhere) because they (IBM)

S/360 absolutely did have carries in the add and subtract logical
instructions, where the condition code said whether there was a
carry. As we've seen it was still a pain to do multiprecision
binary arithmetic, but there was some support for it.

The 704 and its descendants had two carry bits in the accumulator called P and Q
and there was an add-with-carry that added in the P. So this was something they'd been aware of for a while. I agree with the comment that they probably included it because the logic was simple, not unlike the strange way they OR-ed the index registers if you specified more than one of them.

thought the decimal arithmetic would handle "long integer" calculations.

I doubt it. Decimal arithmetic was for commercial applications and the CVB and CVD instructions could only handle a single 32 bit binary operand.


Re a different question about why they only had two encoded condtion code bits, I agree that it's because storage was expensive. The CC took up two bits in the program status word and every bit was precious. I also suspect that they looked at all of the conditions they wanted to report and found that there was never more than four for any particular instruction, so 2 bits was plenty. Remember that the BC instruction had a four bit mask so it could separately select each combination of the two bits.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 29 Sep 2026 08:01:13 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

Or maybe the S/360 architects just thought so, and
considered carry-in just a piece of baggage from
sign-magnitude/1s-complement architectures that they wanted to get rid
of.

I think that Mitch Alsup's idea, that they felt multi-precision wasn't
needed because 16-digit integers were handled by decimal arithmetic
sounds reasonable.
The fact that Burroughs still felt a carry bit was needed even for
100-digit decimal arithmetic doesn't mean that IBM couldn't have
thought this way.
Since 36 bits is _longer_ than 32 bits, my guess can't possibly be
true... or can it? After all, there was the 701 before the 704, with a
mere 18-bit word. The way I was thinking was that there was a
mentality that said that add with carry-in was needed back when
computers had shorter word lengths than the numbers commonly used;
once word lengths grew longer, it was dropped as unnecessary. And the
704 to the 7094 just kept it due to inertia.
However, if that was the reason, then the 1130 should have add with
carry in, and I doubt that.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 01 Oct 2026 07:45:50 GMT, quadibloc@invalid.com (John Savard)
wrote:

However, if that was the reason, then the 1130 should have add with
carry in, and I doubt that.

I checked. It did not have add with carry in, but it did have add
double so as to add 32-bit quantities. That was, of course, simpler to
use, and it could have been felt to be sufficient to address the
issue.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2