If we divide 0x9FFFF by 10 we get 0xFFFF as the quotient and this is a negative value so this result causes an overflow error. The official PDP-11 handbook claims when V=1 and C=0 the results are unpredictable. However the 11/70 manual claims that if the DIV overflow occurs then dividend and divisor remain intact - https://forum.vcfed.org/index.php?threa ... lts.73964/ - it seems that most PDP-11 processors unofficially share this behaviors but the 11/34 and 11/44 are definitely outside of this. Anyway, using the result after the overflow is almost an act of exploiting undefined behavior, so it must rather be avoided in good coding. Nevertheless I use this method as an option for my pi spigot algorithm implementation because it is just a bit faster.This is what I thought, and coded my PDP11 emulator to do this, and I was initially worried that I'd be hitting signed/unsigned ambiguities. But the divide10 code *always* works with unambiguously positive numbers. The first part does &0000nnnn DIV 10, so both parts are unsigned positive numbers, the second part does up to &0009FFFF DIV 10, again both parts are unsigned positive numbers. So it never gets to a case where there are signed negative numbers.
But I also have a general variant that works on any PDP-11.BTW a PDP-11/70 (misspiggy) is still online at LCM. So it is easy to test any thing there. They also have the 11/84 but it is offline this year.
IMHO you could mention the Soviet VM1, VM2, VM3 of the K1801 series processors, the VM3 is still in production! Anyway these chips were produced in large quantities and are still widely available and cheap.Something to add to my list of things to avoid when coding.
Statistics: Posted by litwr — Thu Oct 31, 2024 5:46 am