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