Johnny Billquist wrote:
> So there are some incompatibilities between PDP-10 models. Not as many
> as for the PDP-11, and it's more in the line of added instructions. But
> it still means differences exist. Which a program could even use to
> figure out what model of CPU it is running on.

Yes, and there even were such programs in the official DEC documentations. However, they don't use any instructions are are undefined on the earlier models, but more minute details.

On 2023-09-10 18:11, Lars Brinkhoff wrote:
> Johnny Billquist wrote:
>> So there are some incompatibilities between PDP-10 models. Not as many
>> as for the PDP-11, and it's more in the line of added instructions. But
>> it still means differences exist. Which a program could even use to
>> figure out what model of CPU it is running on.
>
> Yes, and there even were such programs in the official DEC documentations. However, they don't use any instructions are are undefined on the earlier models, but more minute details.

Oh ho... More differences then. :-)
Like on a PDP-11, where SWAB might set or clear the V flag, depending on
model.

Or how a PDP-8 reacts if you combine RAL and RAR.

So much fun with the weird small details.

Johnny

Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-09-10 18:11, Lars Brinkhoff wrote:
>> Johnny Billquist wrote:
>>> So there are some incompatibilities between PDP-10 models. Not as many
>>> as for the PDP-11, and it's more in the line of added instructions. But
>>> it still means differences exist. Which a program could even use to
>>> figure out what model of CPU it is running on.
>>
>> Yes, and there even were such programs in the official DEC
>> documentations. However, they don't use any instructions are are
>> undefined on the earlier models, but more minute details.
>
> Oh ho... More differences then. :-)
> Like on a PDP-11, where SWAB might set or clear the V flag, depending on
> model.
>
> Or how a PDP-8 reacts if you combine RAL and RAR.
>
> So much fun with the weird small details.

If you’re not 100% compatible, it’s going to come back and bite someone.

--
Pete

On Mon, 11 Sep 2023 12:04:00 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> If you’re not 100% compatible, it’s going to come back and bite someone.

One of my favourite sayings from the early days of the PC clone
business - "IBM compatibles aren't".

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Peter Flass <peter_flass@yahoo.com> writes:
>Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-09-10 18:11, Lars Brinkhoff wrote:
>>> Johnny Billquist wrote:
>>>> So there are some incompatibilities between PDP-10 models. Not as many
>>>> as for the PDP-11, and it's more in the line of added instructions. But
>>>> it still means differences exist. Which a program could even use to
>>>> figure out what model of CPU it is running on.
>>>
>>> Yes, and there even were such programs in the official DEC
>>> documentations. However, they don't use any instructions are are
>>> undefined on the earlier models, but more minute details.
>>
>> Oh ho... More differences then. :-)
>> Like on a PDP-11, where SWAB might set or clear the V flag, depending on
>> model.
>>
>> Or how a PDP-8 reacts if you combine RAL and RAR.
>>
>> So much fun with the weird small details.
>
>If you’re not 100% compatible, it’s going to come back and bite someone.

It's not as easy as it sounds.

https://www.masswerk.at/nowgobang/2021/6502-illegal-opcodes

This was more a function of the way ROM (VLIW) worked.

Rich Alderson <news@alderson.users.panix.com> writes:

> Peter Flass <peter_flass@yahoo.com> writes:

>> I wasn't aware of the incompatibilities among various PDP-11 models, but the
>> -10s seemed to have areas of incompatibility also. I believe IBM was the
>> first to define an "architecture�" independent of any particular
>> implementation, and then make sure (nearly) all S/360 models conformed to
>> it.

> Other than the addition of extended addressing to the KL-10 and KS-10, what
> did you have in mind for the PDP-10 systems? Asking for a friend... ;->

I clearly didn't have enough coffee before checking in to a.f.c.

In the PDP-6, KA-10, KI-10, and KL-10, there is a class of instructions devoted
to input-output operations. (All I/O controllers are designed to operate the
same way.)

In the KS-10, I/O instructions are much more broadly defined, to interoperate
with Unibus peripherals (using a slightly extended Unibus which handles 18 bit
data rather than 16 bit).

As it happens, because the XKL Toad-1 uses a completely different bus structure
than any DEC product, the KS-10 model (individually defined I/O instructions)
was used in the Toad, although of course the particular assignments are very
different.

Macro-10/Macro-20 (the DEC standard assembler) has the following code in the
initialization sequence; note that this particular version includes a test for
the XKL Toad-1, a PDP-10 clone:

; ;HERE TO TEST FOR CPU AND SET VALUE IN .CPU.
;PDP-6 = 1
;KA-10 = 2
;KI-10 = 3
;KL-10 = 4
;XKL = 5
MOVEI V,1 ;START WITH PDP-6

JFCL 1,.+1 ;CLEAR PC CHANGE FLAG
JRST .+1 ;THEN CHANGE PC
JFCL 1,.PDP6. ;IF FLAG ON, ITS A PDP6

HRLOI 1,-2 ;CHECK FOR KA-10
AOBJP 1,.KA10. ;CHECK CARRY BETWEEN HALVES

SETZ 1, ;CLEAR AC
BLT 1,0 ;AND TRY BLT, KI WILL BE 0 AND
JUMPE 1,.KI10. ;KL WILL HAVE 1,,1

MOVSI 1,400000 ;Largest negative number
ADJBP 1,[430100,,0] ;Check if this changes
CAMN 1,[430100,,0] ;If it doesn't we have a KL10
JRST .KL10.

MOVSI 1,450000 ;A one-word global byte pointer
IBP 1 ;The KS doesn't have OWGBPs
CAMN 1,[450000,,0]
JRST .KS10. ;So the KS won't change it

; JRST .XKL1. ;but the Toad will

.XKL1.: AOS V
.KS10.: AOS V
.KL10.: AOS V
.KI10.: AOS V
.KA10.: AOS V
.PDP6.: MOVEM V,CPUV ;[775] SAVE IT FOR CORE SIZE TYPEOUT

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

According to Peter Flass <peter_flass@yahoo.com>:
>> Or how a PDP-8 reacts if you combine RAL and RAR.
>>
>> So much fun with the weird small details.
>
>If you’re not 100% compatible, it’s going to come back and bite someone.

It's more subtle than that. A well defined architecture says what has
to be compatible and what can vary from one model to another. Good
software only depends on the copatible part, or has explicit
dependencies on the parts that aren't so you can rewrite that part for
new models.

S/360 was well defined, Vax was eventually pretty well defined, other
DEC architectures were only defined by their implementation, which as
you noted led to a lot of pain down the road.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Rich Alderson <news@alderson.users.panix.com> wrote:
> Rich Alderson <news@alderson.users.panix.com> writes:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>
>>> I wasn't aware of the incompatibilities among various PDP-11 models, but the
>>> -10s seemed to have areas of incompatibility also. I believe IBM was the
>>> first to define an "architectureв" independent of any particular
>>> implementation, and then make sure (nearly) all S/360 models conformed to
>>> it.
>
>> Other than the addition of extended addressing to the KL-10 and KS-10, what
>> did you have in mind for the PDP-10 systems? Asking for a friend... ;->
>
> I clearly didn't have enough coffee before checking in to a.f.c.
>
> In the PDP-6, KA-10, KI-10, and KL-10, there is a class of instructions devoted
> to input-output operations. (All I/O controllers are designed to operate the
> same way.)
>
> In the KS-10, I/O instructions are much more broadly defined, to interoperate
> with Unibus peripherals (using a slightly extended Unibus which handles 18 bit
> data rather than 16 bit).
>
> As it happens, because the XKL Toad-1 uses a completely different bus structure
> than any DEC product, the KS-10 model (individually defined I/O instructions)
> was used in the Toad, although of course the particular assignments are very
> different.
>
> Macro-10/Macro-20 (the DEC standard assembler) has the following code in the
> initialization sequence; note that this particular version includes a test for
> the XKL Toad-1, a PDP-10 clone:

Ah, the trouble that can be avoided by a small ROM.

>
> ; ;HERE TO TEST FOR CPU AND SET VALUE IN .CPU.
> ;PDP-6 = 1
> ;KA-10 = 2
> ;KI-10 = 3
> ;KL-10 = 4
> ;XKL = 5
> MOVEI V,1 ;START WITH PDP-6
>
> JFCL 1,.+1 ;CLEAR PC CHANGE FLAG
> JRST .+1 ;THEN CHANGE PC
> JFCL 1,.PDP6. ;IF FLAG ON, ITS A PDP6
>
> HRLOI 1,-2 ;CHECK FOR KA-10
> AOBJP 1,.KA10. ;CHECK CARRY BETWEEN HALVES
>
> SETZ 1, ;CLEAR AC
> BLT 1,0 ;AND TRY BLT, KI WILL BE 0 AND
> JUMPE 1,.KI10. ;KL WILL HAVE 1,,1
>
> MOVSI 1,400000 ;Largest negative number
> ADJBP 1,[430100,,0] ;Check if this changes
> CAMN 1,[430100,,0] ;If it doesn't we have a KL10
> JRST .KL10.
>
> MOVSI 1,450000 ;A one-word global byte pointer
> IBP 1 ;The KS doesn't have OWGBPs
> CAMN 1,[450000,,0]
> JRST .KS10. ;So the KS won't change it
>
> ; JRST .XKL1. ;but the Toad will
>
> .XKL1.: AOS V
> .KS10.: AOS V
> .KL10.: AOS V
> .KI10.: AOS V
> .KA10.: AOS V
> .PDP6.: MOVEM V,CPUV ;[775] SAVE IT FOR CORE SIZE TYPEOUT
>

--
Pete

John Levine <johnl@taugh.com> schrieb:
> S/360 was well defined, Vax was eventually pretty well defined, other
> DEC architectures were only defined by their implementation, which as
> you noted led to a lot of pain down the road.

Wasn't there an unholy mess about POLY on the VAX?

Thomas Koenig <tkoenig@netcologne.de> wrote:
> John Levine <johnl@taugh.com> schrieb:
>> S/360 was well defined, Vax was eventually pretty well defined, other
>> DEC architectures were only defined by their implementation, which as
>> you noted led to a lot of pain down the road.
>
> Wasn't there an unholy mess about POLY on the VAX?
>

How the VAX Lost Its POLY (and EMOD and ACB_floating too)

http://simh.trailing-edge.com/docs/vax_poly.pdf

--
Pete