9 Jul
2024
9 Jul
'24
5:35 p.m.
I don't know of any OSes that use floating point. But the IBM operating
systems for S/360/370 did use packed decimal instructions in a few places.
This was an issue for the System/360 model 44. The model 44 was
essentially a model 40 but with the (much faster) model 65's floating point
hardware. It was intended as a reduced-cost high-performance technical
computing machine for small research outfits.
To keep the cost down, the model 44 lacked the packed decimal arithmetic
instructions, which of course are not needed in HPTC. But that meant that
off-the-shelf OS/360 would not run on the 44. It had its own OS called
PS/44.
IIRC VAX/VMS ran into similar issues when the microVAX architecture was
adopted. To save on chip real estate, microVAX did not implement packed
decimal, the complicated character string instructions, H-floating point,
and some other exotica (such as CRC) in hardware. They were emulated by
the OS. For performance reasons it behooved one to avoid those data types
and instructions on later VAXen.
I once traced a severe performance problem to a subroutine where there were
only a few instructions that weren't generating emulator faults. The
culprit was the oddball conversion semantics of PL/I, which caused what
should have been D-float arithmetic to be done in 15-digit packed decimal.
Once I fixed that the program ran 100 times faster.
-Paul W.
9 Jul
9 Jul
5:46 p.m.
On Tue, Jul 9, 2024 at 1:35 PM Paul Winalski <paul.winalski(a)gmail.com> wrote:
I don't know of any OSes that use floating point.
I've seen it. Not for numeric computations, primarily, but for fast
data transfer a la `memcpy` using SIMD instructions in the FPU. In
the BSD kernels circa 4.3, load average calculation used a modicum of
FP (multiplication as double's). Oh, and I've seen some amount of FP
hardware used for computing checksums.
Of course, the OS must save and restore the state of the FPU on a
context switch, but that's rather obviously not what you meant; I only
mention it for completeness.
But the IBM operating systems for S/360/370 did use
packed decimal instructions in a few places. This was an issue for the System/360 model
44. The model 44 was essentially a model 40 but with the (much faster) model 65's
floating point hardware. It was intended as a reduced-cost high-performance technical
computing machine for small research outfits.
To keep the cost down, the model 44 lacked the packed decimal arithmetic instructions,
which of course are not needed in HPTC. But that meant that off-the-shelf OS/360 would
not run on the 44. It had its own OS called PS/44.
IIRC VAX/VMS ran into similar issues when the microVAX architecture was adopted. To save
on chip real estate, microVAX did not implement packed decimal, the complicated character
string instructions, H-floating point, and some other exotica (such as CRC) in hardware.
They were emulated by the OS. For performance reasons it behooved one to avoid those data
types and instructions on later VAXen.
I once traced a severe performance problem to a subroutine where there were only a few
instructions that weren't generating emulator faults. The culprit was the oddball
conversion semantics of PL/I, which caused what should have been D-float arithmetic to be
done in 15-digit packed decimal. Once I fixed that the program ran 100 times faster.
It never ceases to amaze me how seemingly minor details can have such
outsized impact.
- Dan C.
10:20 p.m.
Dan Cross wrote in
<CAEoi9W5SepgWyepx2r7YJLA5AtAGgQdnFMgMEBXmxQHurcrSeA(a)mail.gmail.com>:
|On Tue, Jul 9, 2024 at 1:35 PM Paul Winalski <paul.winalski(a)gmail.com> \
|wrote:
|> I don't know of any OSes that use floating point.
|
|I've seen it. Not for numeric computations, primarily, but for fast
|data transfer a la `memcpy` using SIMD instructions in the FPU. In
Yes, .. not SIMD (what i know), but using the floating-point stack
on x86 one could get dramatic performance boosts for bzero(), and
for the copies etc. (Ie, by fildq loading for example 64 bytes
into the stack, then fistpq saving it to the destination. On
Athlon this was very fast even on non-aligned pointers.) And
i think the MMX extension registers effectively "were" the FP
stack.
|the BSD kernels circa 4.3, load average calculation used a modicum of
|FP (multiplication as double's). Oh, and I've seen some amount of FP
|hardware used for computing checksums.
|
|Of course, the OS must save and restore the state of the FPU on a
|context switch, but that's rather obviously not what you meant; I only
|mention it for completeness.
..
I am an integer fan. The hardware front brought so many
floating-point improvements that today i think they are "as fast"
as integer on x86, multiplication and division, etc.
But i hated sox ("the Swiss Army knife of audio manipulation") for
using floating point internally, when i come in with 16-bit audio
data; i keep the all-integer tremor library for Ogg Vorbis audio,
for some future day; noone used it, i still do not understand why.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
72
days inactive
72
days old
2 comments
3 participants
participants (3)
-
Dan Cross -
Paul Winalski -
Steffen Nurpmeso