From Newsgroup: comp.sys.unisys

I am struggling understand why anyone would have thought that these instructions were needed. The manuals go through a lot of mumbo jumbo
about implied binary points which I understand well enough. But what is
the point of instructions that only make allowances for a single binary
point? It seems to me that if one is going to have to scale numbers in
this fashion you are most likely going to need more than 1 binary point
and you will have to keep track of the scaling yourself in any case.
Either that or just use floating point.

I'm perplexed.

Steve B
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

Stephen Boyd wrote:

I am struggling understand why anyone would have thought that these instructions were needed. The manuals go through a lot of mumbo jumbo
about implied binary points which I understand well enough. But what is
the point of instructions that only make allowances for a single binary point? It seems to me that if one is going to have to scale numbers in
this fashion you are most likely going to need more than 1 binary point
and you will have to keep track of the scaling yourself in any case.
Either that or just use floating point.

I'm perplexed.

Steve B

Look at the code FTN generates when converting REAL to INTEGER (or vice versa), it makes use of something along those lines. You can then check
the equivalent for Double Precision.
I had to do this for a piece of MASM coding around 41 years ago so my
memory of the exact code generated is more than sketchy.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 2/23/26 12:22, R Daneel Olivaw wrote:

Look at the code FTN generates when converting REAL to INTEGER (or vice versa), it makes use of something along those lines.-a You can then check the equivalent for Double Precision.
I had to do this for a piece of MASM coding around 41 years ago so my
memory of the exact code generated is more than sketchy.

Ah! I can kind of see where that would be useful in that situation. Not
being a mathematician I would have to do some serious thinking to
completely wrap my head around it.

Whenever I have to convert between floating point and integer or vice
versa I usually end up doing a bunch of floating point arithmetic to
make it happen. I can see where being able to use integer instructions
would be a lot faster.

Thanks

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

Stephen Boyd wrote:

On 2/23/26 12:22, R Daneel Olivaw wrote:

Look at the code FTN generates when converting REAL to INTEGER (or
vice versa), it makes use of something along those lines.-a You can
then check the equivalent for Double Precision.
I had to do this for a piece of MASM coding around 41 years ago so my
memory of the exact code generated is more than sketchy.

Ah! I can kind of see where that would be useful in that situation. Not being a mathematician I would have to do some serious thinking to
completely wrap my head around it.

Whenever I have to convert between floating point and integer or vice
versa I usually end up doing a bunch of floating point arithmetic to
make it happen. I can see where being able to use integer instructions
would be a lot faster.

Thanks

Well I cheated back then - "FTN has to do it and whatever it does will
be bombproof, so @FTN,L (on a tiny subroutine) is the way to go".
My comment in the MASM routine became legendary, "I don't know why this
works but it does so leave it alone".
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 2/23/2026 11:27 AM, Stephen Boyd wrote:

On 2/23/26 12:22, R Daneel Olivaw wrote:

Look at the code FTN generates when converting REAL to INTEGER (or
vice versa), it makes use of something along those lines.-a You can
then check the equivalent for Double Precision.
I had to do this for a piece of MASM coding around 41 years ago so my
memory of the exact code generated is more than sketchy.

Ah! I can kind of see where that would be useful in that situation. Not being a mathematician I would have to do some serious thinking to
completely wrap my head around it.

Whenever I have to convert between floating point and integer or vice
versa I usually end up doing a bunch of floating point arithmetic to
make it happen. I can see where being able to use integer instructions
would be a lot faster.

For conversion from integer to FP, there are the load and convert to
floating and double load and convert to floating. Two instructions one
to preload the offset of the exponent, then one to do the conversion.

For FP to int, there is there is the floating expand and load
instruction that helps a lot.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 2/23/26 15:27, R Daneel Olivaw wrote:

Well I cheated back then - "FTN has to do it and whatever it does will
be bombproof, so @FTN,L (on a tiny subroutine) is the way to go".
My comment in the MASM routine became legendary, "I don't know why this works but it does so leave it alone".

LOL

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 2/23/26 15:54, Stephen Fuld wrote:

Whenever I have to convert between floating point and integer or vice
versa I usually end up doing a bunch of floating point arithmetic to
make it happen. I can see where being able to use integer instructions
would be a lot faster.

For conversion from integer to FP, there are the load and convert to floating and double load and convert to floating.-a Two instructions one
to preload the offset of the exponent, then one to do the conversion.

For FP to int, there is there is the floating expand and load
instruction that helps a lot.

Thanks

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 2/23/26 15:27, R Daneel Olivaw wrote:

Stephen Boyd wrote:

On 2/23/26 12:22, R Daneel Olivaw wrote:

Look at the code FTN generates when converting REAL to INTEGER (or
vice versa), it makes use of something along those lines.-a You can
then check the equivalent for Double Precision.
I had to do this for a piece of MASM coding around 41 years ago so my
memory of the exact code generated is more than sketchy.

Ah! I can kind of see where that would be useful in that situation.
Not being a mathematician I would have to do some serious thinking to
completely wrap my head around it.

Whenever I have to convert between floating point and integer or vice
versa I usually end up doing a bunch of floating point arithmetic to
make it happen. I can see where being able to use integer instructions
would be a lot faster.

Thanks

Well I cheated back then - "FTN has to do it and whatever it does will
be bombproof, so @FTN,L (on a tiny subroutine) is the way to go".
My comment in the MASM routine became legendary, "I don't know why this works but it does so leave it alone".

I found another use for MF. Converting Fieldata to binary. Like the
Fortran code mentioned above I don't really know why this works but I
tried it and it does.

Convert the 6 fieldata numerals in A0 to binary in A1.

AND A0,(0171717171717). STRIP OFF 'ZONE' BITS
AND A1,(-0,0,-0,0,-0,0). EXTRACT ALTERNATE DIGITS
MF A2,(54*/29).
AN A1,A2. 3 PAIRS OF DIGITS CONVERTED
AND A1,(0,-0,0).
MF A2,((1*/12-100)*/23).
AN A1,A2. RIGHT 4 DIGITS NOW DONE
AND A1,(-0,0,0).
MF A2,((1*/24-10000)*/11).
AN A1,A2. DONE. RESULT IN A1, ORIGINAL IN A0.

I found this at http://fourmilab.org/documents/univac/cute-tricks.html

Steve B
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

Stephen Boyd wrote:

On 2/23/26 15:27, R Daneel Olivaw wrote:

Stephen Boyd wrote:

On 2/23/26 12:22, R Daneel Olivaw wrote:

Look at the code FTN generates when converting REAL to INTEGER (or
vice versa), it makes use of something along those lines.-a You can
then check the equivalent for Double Precision.
I had to do this for a piece of MASM coding around 41 years ago so
my memory of the exact code generated is more than sketchy.

Ah! I can kind of see where that would be useful in that situation.
Not being a mathematician I would have to do some serious thinking to
completely wrap my head around it.

Whenever I have to convert between floating point and integer or vice
versa I usually end up doing a bunch of floating point arithmetic to
make it happen. I can see where being able to use integer
instructions would be a lot faster.

Thanks

Well I cheated back then - "FTN has to do it and whatever it does will
be bombproof, so @FTN,L (on a tiny subroutine) is the way to go".
My comment in the MASM routine became legendary, "I don't know why
this works but it does so leave it alone".

I found another use for MF. Converting Fieldata to binary. Like the
Fortran code mentioned above I don't really know why this works but I
tried it and it does.

Convert the 6 fieldata numerals in A0 to binary in A1.

-a-a-a-a-a-a-a AND-a-a-a-a A0,(0171717171717).-a-a STRIP OFF 'ZONE' BITS
-a-a-a-a-a-a-a AND-a-a-a-a A1,(-0,0,-0,0,-0,0).-a EXTRACT ALTERNATE DIGITS
-a-a-a-a-a-a-a MF-a-a-a-a-a A2,(54*/29).
-a-a-a-a-a-a-a AN-a-a-a-a-a A1,A2.-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 3 PAIRS OF DIGITS CONVERTED
-a-a-a-a-a-a-a AND-a-a-a-a A1,(0,-0,0).
-a-a-a-a-a-a-a MF-a-a-a-a-a A2,((1*/12-100)*/23).
-a-a-a-a-a-a-a AN-a-a-a-a-a A1,A2.-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a RIGHT 4 DIGITS NOW DONE
-a-a-a-a-a-a-a AND-a-a-a-a A1,(-0,0,0).
-a-a-a-a-a-a-a MF-a-a-a-a-a A2,((1*/24-10000)*/11).
-a-a-a-a-a-a-a AN-a-a-a-a-a A1,A2.-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a DONE. RESULT IN A1, ORIGINAL IN A0.

I found this at http://fourmilab.org/documents/univac/cute-tricks.html

Steve B

That link is bad, it's cute_tricks and not cute-tricks. Oh, and https.
Some of those tricks are really outdated - 13, 14 and 19 in particular
(19 assumes non-write-protected I-Banks). Ascii versions of some of the others would be useful.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

Stephen Boyd wrote:

On 3/9/26 14:47, R Daneel Olivaw wrote:

I found this at http://fourmilab.org/documents/univac/cute-tricks.html

Steve B

That link is bad, it's cute_tricks and not cute-tricks.-a Oh, and https.
Some of those tricks are really outdated - 13, 14 and 19 in particular
(19 assumes non-write-protected I-Banks).-a Ascii versions of some of
the others would be useful.

Sorry about the link. PEBKAC. (Problem exists between keyboard and chair).

Absolutely some of the tricks are outdated. The page was posted by a
fellow reminiscing about his time working on an 1108.

Steve B

The fun one was #14: "(Note: this will not work beyond Exec level 31!)".
My first Univac job was at the start of 1979, on an 1106 running (I
think) Exec 33.
I was wondering why the coding referenced R14 as address 0136, but 0136
is the Exec's R14 (which is protected) while the User R14 is at 0116.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 3/10/2026 2:00 PM, R Daneel Olivaw wrote:

Stephen Boyd wrote:

On 3/9/26 14:47, R Daneel Olivaw wrote:

I found this at http://fourmilab.org/documents/univac/cute-tricks.html >>>>
Steve B

That link is bad, it's cute_tricks and not cute-tricks.-a Oh, and https. >>> Some of those tricks are really outdated - 13, 14 and 19 in
particular (19 assumes non-write-protected I-Banks).-a Ascii versions
of some of the others would be useful.

To me, it is remarkable that even a few of those, all over 50 years old,
are still usable, and even useful! Read the history of "cute tricks" in
the "About this Edition" at the bottom of the page.

#13 will still work, though it has been superseded by the variants of
the SZ instruction that store values other than zero. These did not
exist on the 1108.

#14 worked in Exec levels 31 and prior because the Exec kept the TAL
(Type and Level) of whatever was currently executing in Exec R14, which
could be read, but not written, by a user program. The Type of a demand
run was 4 versus 6 for a batch run. But in Exec 33, when TIP was
integrated into the Exec, the definition was changed such that the type
of a TIP transaction was 4, and demand was changed to 6, the same as
batch, so the trick no longer worked. BTW, since TAL, and ER14 usage
was internal to Exec, the change was not documented, and this broke
programs that relied on it.

#19 relied on the SLJ instruction, which was an alternative to LMJ for
calling a subroutine, but used a memory location instead of a register
to hold the return address. This was, IMNSHO, a bad idea. Besides the
issue of not working if the I-bank was write protected, it also caused
havoc if the subroutine was called by a program had multiple activities.
Unisys recognized the problems and took the opportunity of introducing extended mode to eliminate it without introducing backward compatibility issues.

As for ASCII versions, for most of them, this would be hard to
impossible. For example, #23 works only because Fieldata has only 64 characters, so a bit map fits in a double word (72 bits). Since ASCII
has 128 or 256 depending on which definition you use, the bit map
wouldn't fit into two registers.

Sorry about the link. PEBKAC. (Problem exists between keyboard and
chair).

Absolutely some of the tricks are outdated. The page was posted by a
fellow reminiscing about his time working on an 1108.

Yes, but the site is much more than that. It is the site of the late
John Walker, who was indeed an early 1108 system programmer at the site
ISD, but later founded the CAD software company Autodesk, and had a lot
of interests. For a variety of fun stuff, check out the rest of the
site. Start at the home page

https://www.fourmilab.ch/

The fun one was #14: "(Note: this will not work beyond Exec level 31!)".
My first Univac job was at the start of 1979, on an 1106 running (I
think) Exec 33.
I was wondering why the coding referenced R14 as address 0136, but 0136
is the Exec's R14 (which is protected) while the User R14 is at 0116.

See above
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

Stephen Fuld wrote:

#14 worked in Exec levels 31 and prior because the Exec kept the TAL
(Type and Level) of whatever was currently executing in Exec R14, which could be read, but not written, by a user program.-a The Type of a demand run was 4 versus 6 for a batch run.-a But in Exec 33, when TIP was integrated into the Exec, the definition was changed such that the type
of a TIP transaction was 4, and demand was changed to 6, the same as
batch, so the trick no longer worked.-a BTW, since TAL, and ER14 usage
was internal to Exec, the change was not documented, and this broke
programs that relied on it.

The values are in A4 when a program starts.
04 is Demand
05 is Deadline Batch
06 is Batch
I can't remember what the TIP values are but would guess that they could
be 010-013 for (Self Destruct, Self Initialising, Reentrant, HVTIP).
That is documented in a few places such as ECL (under @XQT) and wherever UCSINITREG$ is documented.


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 3/12/2026 1:53 AM, R Daneel Olivaw wrote:

Stephen Fuld wrote:

#14 worked in Exec levels 31 and prior because the Exec kept the TAL
(Type and Level) of whatever was currently executing in Exec R14,
which could be read, but not written, by a user program.-a The Type of
a demand run was 4 versus 6 for a batch run.-a But in Exec 33, when TIP
was integrated into the Exec, the definition was changed such that the
type of a TIP transaction was 4, and demand was changed to 6, the same
as batch, so the trick no longer worked.-a BTW, since TAL, and ER14
usage was internal to Exec, the change was not documented, and this
broke programs that relied on it.

The values are in A4 when a program starts.
04 is Demand
05 is Deadline Batch
06 is Batch

Yes, that is explained in the "trick". But as also explained there, if
you are writing say a subroutine library that might be called by either
a batch or demand program, A4 was probably used by that program long
ago, so you can't depend on it any more.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

Stephen Fuld wrote:

On 3/12/2026 1:53 AM, R Daneel Olivaw wrote:

Stephen Fuld wrote:

#14 worked in Exec levels 31 and prior because the Exec kept the TAL
(Type and Level) of whatever was currently executing in Exec R14,
which could be read, but not written, by a user program.-a The Type of
a demand run was 4 versus 6 for a batch run.-a But in Exec 33, when
TIP was integrated into the Exec, the definition was changed such
that the type of a TIP transaction was 4, and demand was changed to
6, the same as batch, so the trick no longer worked.-a BTW, since TAL,
and ER14 usage was internal to Exec, the change was not documented,
and this broke programs that relied on it.

The values are in A4 when a program starts.
04 is Demand
05 is Deadline Batch
06 is Batch

Yes, that is explained in the "trick".-a-a But as also explained there, if you are writing say a subroutine library that might be called by either
a batch or demand program, A4 was probably used by that program long
ago, so you can't depend on it any more.

A volatile register can be overwritten? Amazing.
UCSINITREG$ is the UCS call, I think ER DMGC$ also returns that value
for BM programs although that is from my memory and it may well be
incorrect. I'm also not sure if both calls return those TIP values, one
may not.
Btw, I think @ACOB saves those A4/A5 values in some fixed place before
it does anything else - its Supplimentary Reference should say something
about register usage.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 3/12/2026 7:50 AM, R Daneel Olivaw wrote:

Stephen Fuld wrote:

On 3/12/2026 1:53 AM, R Daneel Olivaw wrote:

Stephen Fuld wrote:

#14 worked in Exec levels 31 and prior because the Exec kept the TAL
(Type and Level) of whatever was currently executing in Exec R14,
which could be read, but not written, by a user program.-a The Type
of a demand run was 4 versus 6 for a batch run.-a But in Exec 33,
when TIP was integrated into the Exec, the definition was changed
such that the type of a TIP transaction was 4, and demand was
changed to 6, the same as batch, so the trick no longer worked.
BTW, since TAL, and ER14 usage was internal to Exec, the change was
not documented, and this broke programs that relied on it.

The values are in A4 when a program starts.
04 is Demand
05 is Deadline Batch
06 is Batch

Yes, that is explained in the "trick".-a-a But as also explained there,
if you are writing say a subroutine library that might be called by
either a batch or demand program, A4 was probably used by that program
long ago, so you can't depend on it any more.

A volatile register can be overwritten?-a Amazing.
UCSINITREG$ is the UCS call, I think ER DMGC$ also returns that value
for BM programs although that is from my memory and it may well be incorrect.-a I'm also not sure if both calls return those TIP values, one may not.
Btw, I think @ACOB saves those A4/A5 values in some fixed place before
it does anything else - its Supplimentary Reference should say something about register usage.

Remember, this was 1975. UCS was perhaps a dream in some Univac
software designers mind. It wouldn't be available for some years. I
think ACOB was available, but I don't think it had replaced its
predecessor @COB (fieldata COBOL) in most sites. It certainly didn't
where I worked.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.unisys

On 3/9/26 14:47, R Daneel Olivaw wrote:

I found this at http://fourmilab.org/documents/univac/cute-tricks.html

Steve B

That link is bad, it's cute_tricks and not cute-tricks.-a Oh, and https.
Some of those tricks are really outdated - 13, 14 and 19 in particular
(19 assumes non-write-protected I-Banks).-a Ascii versions of some of the others would be useful.

Sorry about the link. PEBKAC. (Problem exists between keyboard and chair).

Absolutely some of the tricks are outdated. The page was posted by a
fellow reminiscing about his time working on an 1108.

Steve B
--- Synchronet 3.21d-Linux NewsLink 1.2