Help: PDP-11 instruction classification (again!)

Steven M. Schultz sms at
Wed May 10 13:22:57 AEST 2000

Hi --

> From: johnh at
> 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
	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 '' and '' - 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

Received: (from major at localhost)
	by (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