10 Apr
2026
10 Apr
'26
3:51 p.m.
On 10/04/2026 15.46, Paul Koning wrote:
Thanks. That makes sense. About Tops-10 and NSP - a bit surprising,
considering that all other implementations manage to do it without FP.
On Apr 10, 2026, at 9:18 AM, Johnny Billquist
<bqt(a)softjar.se>wrote;wrote:
On 10/04/2026 05.30, Terri Kennedy wrote:
Same in RSTS. If FPP exists the kernel will context switch the FP state, if the
currently executing program has set the flag to ask the kernel to do that. Apart from
that, nothing uses it and the kernel itself doesn't care about the FPP. The only OS I
can think of that actually using floating point in the kernel is TOPS-10; I was told
DECnet-10 uses it in the NSP delay estimation algorithm. On 2026-04-09 09:24, Dave McGuire wrote:
I know (heard) that CIS would be used for copying memory around, but what in the kernel
would depend on FPP?
(A little surprising is that RSX don't, however, it will use the blockmove
instruction of the Mentec processors that have that one.)
In RSX, it only is a topic for context switching and trap handling. The kernel don't
depend on the actual behavior more than in the most basic sense otherwise (auto
increment/decrement being done with the right amounts, and only the actual registers
referred to being changed when expected, and so on. /me slaps forehead
The 11/70's FP board set is flaky, and it has been removed pending
repair. I had forgotten about that. But the "hello world" program
shouldn't use any FP instructions..?
Be careful with bad FP and modern(ish)
RSTS/E. It will use FP
(and CIS, for that matter) in the monitor, and if your boards are
returning garbage, you can scarfle* your system disk. CIS is used for memory copy, which happens in the file
system cache code so a malfunctioning MOVC3 will potentially mess up the file system.
Thanks for confirming. I thought I'd heard something along those lines.
And I do find it a little interesting that RSX don't, especially since
it does check, and use the Mentec instruction that does the same thing,
if it exists.
Johnny