Help: PDP-11 instruction classification (again!)
Steven M. Schultz
sms at moe.2bsd.com
Wed May 10 13:22:57 AEST 2000
Hi --
> From: johnh at psych.usyd.edu.au
> I forgot to mention a critical point. Any PDP-11 runing Unix (except very
> early versions and Miniunix), and certainly from Edition 6 onwards, MUST have
> EIS. Even the Unix bootstraps used EIS. So binaries built for Unix, will run
> on a 11/34/35/40/44/45/50/53/55/60/70/73/83/84/93/94 !!
Absolutely correct. By the time Unix was making its way out of the
lab and becoming commercially available (V7 and later for certain)
the 11/70 was the target machine and while you could order an 11/70
without floating point very few (that I saw) were bought that way.
Even some of the DEC bootstraps used EIS - at least the later RSX-11D
ones did. At one site we couldn't boot the 11/45 into RSX-11D, it
would crash part way thru the boot process. The DEC folks would
bring in their diagnostic disks and they would boot just fine. Finally
I insisted they run full cpu diagnostics and voila - the 'div' (or was
it the 'ash' - been a looong time) instruction was failing. The
diagnostic packs were RT11 based (I believe) and were meant to run
on all processors rather than the 45 and up.
>Floating point is a bit more problematic. The kernel (see crevat latter) didn't
>require it, but had to save FP status and registers on context switches.
The compiler also checks if any FP is done and generates references
to special symbols as needed. The linker can then link in dummy
modules for parts of the 'printf' and int->floating conversion routines
and save some space that way. A kluge but on a small machine every
half kb counts.
>Quite a few processors had the FPP as an option, and so there was FPP emulation
The kernel (at least V7 and later) has special code in it to catch
and ignore the illegal instruction 'setd' if no hardware FP is present.
This is because the crt0 routine (which receives control from the
kernel when a program is run) forces double precision mode in all
programs.
Some floating point simulators (V7's for example) ran in user mode
and caught the SIGILL signal). I guess running slow instead of
crashing is a plus but wow did that bog down the system immensely.
Of course one of the programs that was used a lot was a Fortran
one and f77 generates a *lot* of floating point code. It wasn't just
the emulation of the FP instructions (that would not have been too
bad) but the overhead of the hundreds of signals and context switches
was a system killer.
> build into the kernel (conditionally). There were versions of the C compiler
> that had code tables for the FIS, to suit the 11/35/40.
2.10BSD and later have an in-kernel FP emulator - alas it doesn't
work. About the most I did was get it thru the assembler. All the
systems I have come with builtin FP. At one time Tim Shoppa was
going to take a stab at pulling the FP board out of his 11/44 and
see about getting the emulator working - copious free time permitting
of course ;)
> I have a distant memory, that I have seen FPP instructions used for some
> integer arithmetic for speed. I cannot recall if it was in the kernel or
In the C library. The kernel itself can't (or at least shouldn't)
do floating point stuff because that might happen at interrupt level
and trash the current user process (if any) context.
The C library code (at least in 2.11) uses FP to do the 32 bit
divide and multiply. It's a lot faster (and much less code) to
convert long to double, do the operations and then store&convert
double back to int or long. There might be one or two other cases
but that was the primary use.
And thereby hangs a bit of a tale. The KDJ-11{A,B} handle faults
during a stack push by a FP instruction differently than the 11/44 or
11/70. If you have access to the 2.11BSD bug archive (I know it's
on 'ns.to.gd-es.com' and 'moe.2bsd.com' - not sure of who else is
mirroring it) look for update #150 (Subject is "stack expansion bug
on KDJ-11 cpus".
Steven Schultz
sms at moe.2bsd.com
Received: (from major at localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id NAA76504
for pups-liszt; Wed, 10 May 2000 13:45:07 +1000 (EST)
More information about the TUHS
mailing list