According to Scott Lurndal <slp53@pacbell.net>:

mitchalsup@aol.com (MitchAlsup1) writes:

Maybe now with 4-or-5-bit condition codes yes,
But the early machines (360) with 2-bit codes were already constricted.

The B3500 (contemporaneous with 360) had COMS toggles (2 bits) and OVERFLOW toggle (1 bit).

As far as I can tell, the 360 was the only machine with short encoded
condition codes.

In their archtecture book Brooks and Blaauw say it was a mistake, but
it also would have been a problem to fit conditional branches into the instruction set if they needed more instruction bits to say which
codes to test. As it was, the branch instructions had 4 condition bits
which let them check for any combination of two-bit conditions along
with 1111 for unconditional branch and 0000 for no-op.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <johnl@taugh.com> writes:
[only 2 condition code bits]

In their archtecture book Brooks and Blaauw say it was a mistake, but
it also would have been a problem to fit conditional branches into the >instruction set if they needed more instruction bits to say which
codes to test. As it was, the branch instructions had 4 condition bits
which let them check for any combination of two-bit conditions along
with 1111 for unconditional branch and 0000 for no-op.

The architecture paid for the reduction in branches with an increase
in other instructions; S/360 needed signed and unsigned versions of a
number of instructions, e.g.,

signed unsigned
A AL
AR ALR
S SL
SR SLR
C CL
CR CLR

Other instruction sets with 16-bit instructions have no problem
supporting the usual NCZV flags.

IBM then continued in their tradition by having < = > and sticky
overflow flags in Power (and a separate carry, sticky overflow and
overflow flag); this also requires signed and unsigned compares (cmp
and cmpl along with variants).

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

John Levine <johnl@taugh.com> writes:
[only 2 condition code bits]
The architecture paid for the reduction in branches with an increase
in other instructions; S/360 needed signed and unsigned versions of a
number of instructions, e.g.,

signed unsigned
A AL
AR ALR
S SL
SR SLR
C CL
CR CLR

There's more differences than the condition codes. A, AR, S and SR
trap on overflow, AL, ALR, SL and SLR don't. It is my impression that
trapping on fixed point overflow is not very useful, and it's easier
to do a jump on overflow in the few cases where you care, or the x86
INTO which you put after the arithmetic operaion to trap if the
overflow flag is set.

IBM then continued in their tradition by having < = > and sticky
overflow flags in Power (and a separate carry, sticky overflow and
overflow flag); this also requires signed and unsigned compares (cmp
and cmpl along with variants).

There's a fairly direct line from S/360 to ROMP to POWER so it's not surprising. ROMP had < = > carry overflow.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton Ertl wrote:

John Levine <johnl@taugh.com> writes:
[only 2 condition code bits]

In their archtecture book Brooks and Blaauw say it was a mistake, but
it also would have been a problem to fit conditional branches into the >>instruction set if they needed more instruction bits to say which
codes to test. As it was, the branch instructions had 4 condition bits >>which let them check for any combination of two-bit conditions along
with 1111 for unconditional branch and 0000 for no-op.

The architecture paid for the reduction in branches with an increase
in other instructions; S/360 needed signed and unsigned versions of a
number of instructions, e.g.,

signed unsigned
A AL
AR ALR
S SL
SR SLR
C CL
CR CLR

Other instruction sets with 16-bit instructions have no problem
supporting the usual NCZV flags.

IBM then continued in their tradition by having < = > and sticky
overflow flags in Power (and a separate carry, sticky overflow and
overflow flag); this also requires signed and unsigned compares (cmp
and cmpl along with variants).

All of which are constraining to the compiler:: for example::

if( x >= y )
then-clause
else
else-clause // NANs go here

Cannot be clause reversed into::

if( x < y )
else-clause
else
then-clause // NaNs go here

But also consider an architecture without any condition codes makes these transformations easy::

if( !( x >= y ) )
else-clause // NaNs go here
else
then-clause

The transformation is easy because the result of a compare instruction
is a bit vector; one bit corresponds to >=, another corresponds to !>=;
fixing a problem that condition code machines find difficult.

And yet even here, there is no signed compare and no unsigned compare;
there is just a compare that performs signed and unsigned, then-else
and else-then, and a few more.

- anton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine <johnl@taugh.com> schrieb:

It is my impression that
trapping on fixed point overflow is not very useful, and it's easier
to do a jump on overflow in the few cases where you care, or the x86
INTO which you put after the arithmetic operaion to trap if the
overflow flag is set.

Sanitzers would benefit greatly from trapping math.

However, this could get into murky territory - to be really
general, you would also need a version for trapping math with
unsigned numbers. Just think of doing a unsigned loop with a
lower bound that, due to some error in the code or input, has an
upper bound of 0-1...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

John Levine <johnl@taugh.com> schrieb:

It is my impression that
trapping on fixed point overflow is not very useful, and it's easier
to do a jump on overflow in the few cases where you care, or the x86
INTO which you put after the arithmetic operaion to trap if the
overflow flag is set.

Sanitzers would benefit greatly from trapping math.

However, this could get into murky territory - to be really
general, you would also need a version for trapping math with
unsigned numbers. Just think of doing a unsigned loop with a
lower bound that, due to some error in the code or input, has an
upper bound of 0-1...

I suppose but my experience was always that the trap was the easy
part. Figuring out what to do after the trap happens is much harder.
I've seen designs with instructions like "trap if greater than N" so
if you want to go that route, you can check for the range the
programemr declared rather than whatever word size it was rounded up
to.



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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Levine wrote:

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

John Levine <johnl@taugh.com> schrieb:

It is my impression that
trapping on fixed point overflow is not very useful, and it's easier
to do a jump on overflow in the few cases where you care, or the x86
INTO which you put after the arithmetic operaion to trap if the
overflow flag is set.

Sanitzers would benefit greatly from trapping math.

However, this could get into murky territory - to be really
general, you would also need a version for trapping math with
unsigned numbers. Just think of doing a unsigned loop with a
lower bound that, due to some error in the code or input, has an
upper bound of 0-1...

I suppose but my experience was always that the trap was the easy
part.

If it is the easy part, why does it take ~1,000* cycles ??

(*) x86 takes craploads of cycles to cross the trap barrier and back
{including the saving and restoration of registers}
Something like My 66000 takes 10 each way including the saving and
restoring of registers, and the change of MMU state.

Figuring out what to do after the trap happens is much harder.

Depends on what the trap delivers to the "other side", and also dependent
on the range of options the handler has to consider; and sometimes on
how many instructions go through that trap !?!

I've seen designs with instructions like "trap if greater than N" so
if you want to go that route, you can check for the range the
programemr declared rather than whatever word size it was rounded up
to.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 <mitchalsup@aol.com> schrieb:

(*) x86 takes craploads of cycles to cross the trap barrier and back {including the saving and restoration of registers}
Something like My 66000 takes 10 each way including the saving and
restoring of registers, and the change of MMU state.

(Maybe) stupid question: What happens to in-flight instructions on
such a trap, or an interrupt? What is the cost of that?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Koenig wrote:

MitchAlsup1 <mitchalsup@aol.com> schrieb:

(*) x86 takes craploads of cycles to cross the trap barrier and back
{including the saving and restoration of registers}
Something like My 66000 takes 10 each way including the saving and
restoring of registers, and the change of MMU state.

(Maybe) stupid question: What happens to in-flight instructions on
such a trap, or an interrupt? What is the cost of that?

All instructions before the trap/exception/interrupt are allowed to complete
No instructions beyond the trap/exception/interrupt are allowed to complete

Those instructions still in flight are allowed to proceed while the state
and register file of the handler are fetched from memory. If they complete before state arrives, the overhead is zero. If they are still pending, then latency accrues from that point.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 4 May 2024 10:08:57 -0000 (UTC), Thomas Koenig wrote:

Just think of doing a unsigned loop with a lower bound that, due to some error in the code or input, has an upper bound of 0-1...

Using the entire range of an unsigned integer type takes some care, but
can be done:

unsigned int i;
bool found;
...
/* length of s might be anything up to largest unsigned integer */
for (i = len(s);;)
{
if (i == 0)
{
found = false;
break;
} /*if*/
--i;
if (matches(s[i]))
{
found = true;
break
} /*if*/
} /*for*/
/* at this point, i will point to the matching element if found */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)