Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse


devel / comp.arch / PDP-11-like ISA

SubjectAuthor
* PDP-11-like ISAMitchAlsup
+* Re: PDP-11-like ISAJimBrakefield
|`- Re: PDP-11-like ISAMitchAlsup
+* Re: PDP-11-like ISAQuadibloc
|+* Re: PDP-11-like ISAQuadibloc
||`- Re: PDP-11-like ISAMitchAlsup
|+- Re: PDP-11-like ISAMitchAlsup
|+- Re: PDP-11-like ISAMitchAlsup
|`* Re: PDP-11-like ISAchris
| `* Re: PDP-11-like ISAQuadibloc
|  +* Re: PDP-11-like ISAMitchAlsup
|  |+* Re: PDP-11-like ISAIvan Godard
|  ||+* Re: PDP-11-like ISAMitchAlsup
|  |||`- Re: PDP-11-like ISAIvan Godard
|  ||`* Re: PDP-11-like ISATerje Mathisen
|  || `* Re: PDP-11-like ISAIvan Godard
|  ||  +* Re: PDP-11-like ISAMitchAlsup
|  ||  |+- Re: PDP-11-like ISATerje Mathisen
|  ||  |`* Re: PDP-11-like ISAEricP
|  ||  | +* Re: PDP-11-like ISAMitchAlsup
|  ||  | |`- Re: PDP-11-like ISAEricP
|  ||  | `- Re: PDP-11-like ISATerje Mathisen
|  ||  `* Re: PDP-11-like ISAStephen Fuld
|  ||   `* Re: PDP-11-like ISAIvan Godard
|  ||    `* Re: PDP-11-like ISAStephen Fuld
|  ||     +- Re: PDP-11-like ISAIvan Godard
|  ||     `- Re: PDP-11-like ISAIvan Godard
|  |`* Re: PDP-11-like ISAQuadibloc
|  | +* Re: PDP-11-like ISAQuadibloc
|  | |+* Re: PDP-11-like ISAIvan Godard
|  | ||`* Re: PDP-11-like ISAQuadibloc
|  | || `* Re: PDP-11-like ISAJames Harris
|  | ||  +* Condition codes (was: PDP-11-like ISA)Anton Ertl
|  | ||  |`* Re: Condition codes (was: PDP-11-like ISA)Quadibloc
|  | ||  | `- Re: Condition codes (was: PDP-11-like ISA)Anton Ertl
|  | ||  `* Re: PDP-11-like ISAMitchAlsup
|  | ||   `* Re: PDP-11-like ISAJames Harris
|  | ||    `- Re: PDP-11-like ISAMitchAlsup
|  | |`- Re: PDP-11-like ISAQuadibloc
|  | +* Re: PDP-11-like ISAMitchAlsup
|  | |`* Re: PDP-11-like ISAEricP
|  | | `- Re: PDP-11-like ISAMitchAlsup
|  | `- Condition codes (was: PDP-11-like ISA)Anton Ertl
|  `* Re: PDP-11-like ISAAnton Ertl
|   `* Re: PDP-11-like ISAQuadibloc
|    `* Re: PDP-11-like ISAAnton Ertl
|     +* Re: PDP-11-like ISAQuadibloc
|     |`- Re: PDP-11-like ISAQuadibloc
|     `* Re: PDP-11-like ISAMitchAlsup
|      `- Re: PDP-11-like ISAQuadibloc
`* Re: PDP-11-like ISAEricP
 +* Re: PDP-11-like ISAJimBrakefield
 |`* Re: PDP-11-like ISAMitchAlsup
 | `- Re: PDP-11-like ISAJimBrakefield
 +* Re: PDP-11-like ISAMitchAlsup
 |+* Re: PDP-11-like ISAQuadibloc
 ||+- Re: PDP-11-like ISAMitchAlsup
 ||`- Re: PDP-11-like ISAMitchAlsup
 |`* Re: PDP-11-like ISAEricP
 | +* Re: PDP-11-like ISAMitchAlsup
 | |`* Re: PDP-11-like ISAEricP
 | | `* Re: PDP-11-like ISAMitchAlsup
 | |  +- Re: PDP-11-like ISAJimBrakefield
 | |  +- Re: PDP-11-like ISAThomas Koenig
 | |  `* Re: PDP-11-like ISATerje Mathisen
 | |   +- Re: PDP-11-like ISAQuadibloc
 | |   +- Re: PDP-11-like ISAMitchAlsup
 | |   `* Re: PDP-11-like ISAStefan Monnier
 | |    `- Re: PDP-11-like ISATerje Mathisen
 | `* Re: PDP-11-like ISATerje Mathisen
 |  +* Re: PDP-11-like ISAEricP
 |  |`* Re: PDP-11-like ISATerje Mathisen
 |  | `* Re: PDP-11-like ISAMitchAlsup
 |  |  `* Re: PDP-11-like ISATerje Mathisen
 |  |   `* Re: PDP-11-like ISAEricP
 |  |    `* Re: PDP-11-like ISAMitchAlsup
 |  |     `- Re: PDP-11-like ISAEricP
 |  `* Re: PDP-11-like ISAMitchAlsup
 |   +* Re: PDP-11-like ISAMitchAlsup
 |   |`* Re: PDP-11-like ISAQuadibloc
 |   | `- Re: PDP-11-like ISAMitchAlsup
 |   `* Re: PDP-11-like ISATerje Mathisen
 |    `* Re: PDP-11-like ISAMitchAlsup
 |     +* Re: PDP-11-like ISAQuadibloc
 |     |`* Re: PDP-11-like ISAMitchAlsup
 |     | +* Re: PDP-11-like ISAJimBrakefield
 |     | |`- Re: PDP-11-like ISAMitchAlsup
 |     | `- Re: PDP-11-like ISATerje Mathisen
 |     `* Re: PDP-11-like ISAJames Harris
 |      `* Re: PDP-11-like ISAThomas Koenig
 |       +* Re: PDP-11-like ISAAnton Ertl
 |       |`- Re: PDP-11-like ISAThomas Koenig
 |       +* Re: PDP-11-like ISATerje Mathisen
 |       |`- Re: PDP-11-like ISAIvan Godard
 |       `- Re: PDP-11-like ISAEricP
 `* Re: PDP-11-like ISAQuadibloc
  +- Re: PDP-11-like ISAMitchAlsup
  `* Re: PDP-11-like ISAEricP
   +- Re: PDP-11-like ISABGB
   +* Re: PDP-11-like ISAMitchAlsup
   |`* Re: PDP-11-like ISATerje Mathisen
   `* Re: PDP-11-like ISAQuadibloc

Pages:12345
PDP-11-like ISA

<548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17573&group=comp.arch#17573

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:a645:: with SMTP id p66mr2174944qke.499.1623282927425;
Wed, 09 Jun 2021 16:55:27 -0700 (PDT)
X-Received: by 2002:a9d:704b:: with SMTP id x11mr110948otj.110.1623282927072;
Wed, 09 Jun 2021 16:55:27 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 9 Jun 2021 16:55:26 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:38cb:6673:6d33:77a5;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:38cb:6673:6d33:77a5
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
Subject: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 09 Jun 2021 23:55:27 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Wed, 9 Jun 2021 23:55 UTC

As I mentioned in Concertina II yesterday, there may be some way to implement
a PDP-11-like ISA and get reasonable performance and high code density.
This thread illustrates both.

Consider an general address mode machine like the original PDP-11, except that
the 8 general registers are 64-bits wide, and that the virtual address space is
also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.

Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
the opcode, the registers and their address modes; the address modes specifies
how the register participates in delivering an operand into a data manipulation.
The address modes are pure PDP-11;

000 the register is used directly in the calculation
001 the register is used to access a value in memory which is the operand
010 the register is used to access a value in memory which is the operand and
.... the register is incremented
011 the register is used to access a value in memory
.... which is then used to access another value in memory which is the operand
.... the register is incremented
100 the register is used to access a value in memory which is the operand and
.... the register is decremented
101 the register is used to access a value in memory
.... which is then used to access another value in memory which is the operand
.... the register is decremented
110 the register and the following 16-bit word displaement are added
.... and used to access a value in memory which is the operand

111 the register and the following 16-bit word displaement are added
.... and used to access a value in memory
.... which is then used to access another value in memory which is the operand

I will use PDP-11 assembler writing style.

Immediates, absolute addresses, relative addresses, and relative deferred
addresses are simple addresse modes applied to the IP register (R7)

The stack is easily manipulated pushing, poping values by using address modes
on the stack pointing register (R6).

The PDP-11 only had a 64KB address space originally, this new semi-derivative
has a 64-bit address space. In modern machines the number of general purpose
registers is 16-32 sometimes more. IN order to make up for only having 8 GPRs
I want us to consider that the 16-bit displacement addressing modes provide
access to 64KB of <you guessed it> registers ! 8192 of them !! each being 64-
bits wide. Now we end up using the deferred modes to access the memory those
registers point at; or these registers can hold actual data. {One would expect
HW acceleration in accessing this register file.}

The Instruction Set Architecture is like many of those designed oh so long ago
in that it uses the update model of the PDP-11::

AM( Src1 ) = AM( Src1 ) OpCode AM( Src2 )

rather than the non-destructive register model of RISC instruction sets. Since
the address modes are relatively powerful, you are not really destroying 8 GPR
registers "all that often" and when you do, you are getting 2 units of work out
of one instruction (even more if you could the extra memory references as use-
ful work.)

So, given the 2 registers and the 2 address mode specifiers, we are left with
only 16 Major Opcodes. I assign these to the more significant powition in the
16-bit instruction.

Certain medium use instructions are not provided with full address mode support.
Integer Multiply, Divide, Floating point sacrifice one address mode on the Rs1
operand and become:

Src1 = Src1 OpCode AM( Src2 )

If we allow 4 of these formats we get 32 instructions, which cover medium usage
integer instructions, and all the 2-operand floating point instructions.

Since we don't have to specify a second register for 1-operand instructions,
we sacrifice all 6-bits of the Src1 specifier and we have a format that provides

AM( Src2 ) = OpCode{ AM( Src2 ) }

And we have lots of room for 1-operand instructions (up to 128 if we need then.)

Branch instructions use the IP deferred address mode giving ±64Kb (since we know
instructions are on halfword boundaries!) this covers the vast majority of branch
within subroutine boundaries.

Assuming the compiler and linker conspire to use a portion of the memory mapped
registers for program linkage, Calls become an index deferred address mode into
those registers.

--------------------------------------------------------------------------------

The execution model of instructions if to consider that the front end of the
machine fetches 128-bits per cycle and is prepaired to lob as many instructions
as it can PARSE per cycle into reservation stations. The 8 GPRs are monitored
for dependencies {RAW, WAR, WAW} as are the 8K memory registers. This gives the
reservation stations enough dependency information to fetch GPRs and MRs in an
appropriate order with few constriants, and because actual memory accesses are
from these original dependencies, memory order is also known and can be followed.

Other than this, the reservaton stations are multi-fire. That is the send a unit
of work into execution when the unit of work is in order and there is a function
unit to process the request. When a result returns, then next unit of work is
scheduled, and when all units of work are complete, the instruction retires out
of the reservation station.

The example I illustrated yester day::

ADD @disp1(R3),@disp2(R4)

is a three (3) 16-bit parcel instruction PARSEd in one cycle. The reservation
station can issue: disp(R3) and disp2(r4) simultaneously, and assuming cache
hits, when both return 3-ish cycles later, the reservation station can issue
@disp(R3) and @disp2(R4) also simultaneously. When this set of data returns
the add is performed, and the result of the ADD is written to @disp2(r3). 6
units of work, 5 memory references and 3 arithmetic calculations (not counting
the IP increments to fetch disp1 and disp2).

The front end will be in a position to detect::

MOV Rk,AM( Rj )
OP AM( Ri ),Rk

And CoIssue these into singel multi-fire reservation station "sequencers". This
makes up for the paltry 4-bit Major OpCode space with only a minor penalty in
code density. So for the 2-oprand instructions that are register and address
mode, there is a clean means to get OP AM( Rj ), AM( Rk )

Now, while one wants { ADD, SUB, AND, OR, XOR, MOV } to share the 2-address mode
configurations, one nealry always wants CMP (compare) to use the register plus
address mode configuration. CMP feeds into Brnahces or Predicates, or COnvert
to TRUE or FALSE instructions. CMP × {BC, PC, SET} will always be CoIssued.

SO, As I see it:: {MOV, ADD, SUB, AND, OR, XOR} are allocated to the 2-address
mode set (6 of 16), whiile {CMP, IMUL, IDIV, SR, SL, FADD, FSUB, FMUL, FDIV}
are allocated to the register plus address mode encoding space. It is convienent
to assign a different R+AM space for integer expansion and Floating Point.

--------------------------------------------------------------------------------

I am still thinking about data width being applied to Operands and results.

Re: PDP-11-like ISA

<7078174e-6311-4148-be32-525bdc14d950n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17574&group=comp.arch#17574

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:7f14:: with SMTP id f20mr2897347qtk.166.1623290068446;
Wed, 09 Jun 2021 18:54:28 -0700 (PDT)
X-Received: by 2002:aca:650b:: with SMTP id m11mr1654433oim.99.1623290068112;
Wed, 09 Jun 2021 18:54:28 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 9 Jun 2021 18:54:27 -0700 (PDT)
In-Reply-To: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:a0d0:9f90:5c61:f68f:a92f:6f4f;
posting-account=AoizIQoAAADa7kQDpB0DAj2jwddxXUgl
NNTP-Posting-Host: 2600:1700:a0d0:9f90:5c61:f68f:a92f:6f4f
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7078174e-6311-4148-be32-525bdc14d950n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jim.brak...@ieee.org (JimBrakefield)
Injection-Date: Thu, 10 Jun 2021 01:54:28 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 224
 by: JimBrakefield - Thu, 10 Jun 2021 01:54 UTC

On Wednesday, June 9, 2021 at 6:55:28 PM UTC-5, MitchAlsup wrote:
> As I mentioned in Concertina II yesterday, there may be some way to implement
> a PDP-11-like ISA and get reasonable performance and high code density.
> This thread illustrates both.
>
> Consider an general address mode machine like the original PDP-11, except that
> the 8 general registers are 64-bits wide, and that the virtual address space is
> also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
>
> Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> the opcode, the registers and their address modes; the address modes specifies
> how the register participates in delivering an operand into a data manipulation.
> The address modes are pure PDP-11;
>
> 000 the register is used directly in the calculation
> 001 the register is used to access a value in memory which is the operand
> 010 the register is used to access a value in memory which is the operand and
> ... the register is incremented
> 011 the register is used to access a value in memory
> ... which is then used to access another value in memory which is the operand
> ... the register is incremented
> 100 the register is used to access a value in memory which is the operand and
> ... the register is decremented
> 101 the register is used to access a value in memory
> ... which is then used to access another value in memory which is the operand
> ... the register is decremented
> 110 the register and the following 16-bit word displaement are added
> ... and used to access a value in memory which is the operand
>
> 111 the register and the following 16-bit word displaement are added
> ... and used to access a value in memory
> ... which is then used to access another value in memory which is the operand
>
> I will use PDP-11 assembler writing style.
>
> Immediates, absolute addresses, relative addresses, and relative deferred
> addresses are simple addresse modes applied to the IP register (R7)
>
> The stack is easily manipulated pushing, poping values by using address modes
> on the stack pointing register (R6).
>
> The PDP-11 only had a 64KB address space originally, this new semi-derivative
> has a 64-bit address space. In modern machines the number of general purpose
> registers is 16-32 sometimes more. IN order to make up for only having 8 GPRs
> I want us to consider that the 16-bit displacement addressing modes provide
> access to 64KB of <you guessed it> registers ! 8192 of them !! each being 64-
> bits wide. Now we end up using the deferred modes to access the memory those
> registers point at; or these registers can hold actual data. {One would expect
> HW acceleration in accessing this register file.}
>
> The Instruction Set Architecture is like many of those designed oh so long ago
> in that it uses the update model of the PDP-11::
>
> AM( Src1 ) = AM( Src1 ) OpCode AM( Src2 )
>
> rather than the non-destructive register model of RISC instruction sets. Since
> the address modes are relatively powerful, you are not really destroying 8 GPR
> registers "all that often" and when you do, you are getting 2 units of work out
> of one instruction (even more if you could the extra memory references as use-
> ful work.)
>
> So, given the 2 registers and the 2 address mode specifiers, we are left with
> only 16 Major Opcodes. I assign these to the more significant powition in the
> 16-bit instruction.
>
> Certain medium use instructions are not provided with full address mode support.
> Integer Multiply, Divide, Floating point sacrifice one address mode on the Rs1
> operand and become:
>
> Src1 = Src1 OpCode AM( Src2 )
>
> If we allow 4 of these formats we get 32 instructions, which cover medium usage
> integer instructions, and all the 2-operand floating point instructions.
>
> Since we don't have to specify a second register for 1-operand instructions,
> we sacrifice all 6-bits of the Src1 specifier and we have a format that provides
>
> AM( Src2 ) = OpCode{ AM( Src2 ) }
>
> And we have lots of room for 1-operand instructions (up to 128 if we need then.)
>
> Branch instructions use the IP deferred address mode giving ±64Kb (since we know
> instructions are on halfword boundaries!) this covers the vast majority of branch
> within subroutine boundaries.
>
> Assuming the compiler and linker conspire to use a portion of the memory mapped
> registers for program linkage, Calls become an index deferred address mode into
> those registers.
>
> --------------------------------------------------------------------------------
>
> The execution model of instructions if to consider that the front end of the
> machine fetches 128-bits per cycle and is prepaired to lob as many instructions
> as it can PARSE per cycle into reservation stations. The 8 GPRs are monitored
> for dependencies {RAW, WAR, WAW} as are the 8K memory registers. This gives the
> reservation stations enough dependency information to fetch GPRs and MRs in an
> appropriate order with few constriants, and because actual memory accesses are
> from these original dependencies, memory order is also known and can be followed.
>
> Other than this, the reservaton stations are multi-fire. That is the send a unit
> of work into execution when the unit of work is in order and there is a function
> unit to process the request. When a result returns, then next unit of work is
> scheduled, and when all units of work are complete, the instruction retires out
> of the reservation station.
>
> The example I illustrated yester day::
>
> ADD @disp1(R3),@disp2(R4)
>
> is a three (3) 16-bit parcel instruction PARSEd in one cycle. The reservation
> station can issue: disp(R3) and disp2(r4) simultaneously, and assuming cache
> hits, when both return 3-ish cycles later, the reservation station can issue
> @disp(R3) and @disp2(R4) also simultaneously. When this set of data returns
> the add is performed, and the result of the ADD is written to @disp2(r3). 6
> units of work, 5 memory references and 3 arithmetic calculations (not counting
> the IP increments to fetch disp1 and disp2).
>
> The front end will be in a position to detect::
>
> MOV Rk,AM( Rj )
> OP AM( Ri ),Rk
>
> And CoIssue these into singel multi-fire reservation station "sequencers".. This
> makes up for the paltry 4-bit Major OpCode space with only a minor penalty in
> code density. So for the 2-oprand instructions that are register and address
> mode, there is a clean means to get OP AM( Rj ), AM( Rk )
>
> Now, while one wants { ADD, SUB, AND, OR, XOR, MOV } to share the 2-address mode
> configurations, one nealry always wants CMP (compare) to use the register plus
> address mode configuration. CMP feeds into Brnahces or Predicates, or COnvert
> to TRUE or FALSE instructions. CMP × {BC, PC, SET} will always be CoIssued.
>
> SO, As I see it:: {MOV, ADD, SUB, AND, OR, XOR} are allocated to the 2-address
> mode set (6 of 16), whiile {CMP, IMUL, IDIV, SR, SL, FADD, FSUB, FMUL, FDIV}
> are allocated to the register plus address mode encoding space. It is convienent
> to assign a different R+AM space for integer expansion and Floating Point..
>
> --------------------------------------------------------------------------------
>
> I am still thinking about data width being applied to Operands and results.

Ugh, not sure it you are staying with original PDP11 pre-decrement modes
or changing the implementation of those modes?
The PDP11 register decrement modes decrement the register before use.
(checked my yellowed PDP11 Processor Handbook)

|> 100 the register is used to access a value in memory which is the operand and
|> ... the register is decremented
|> 101 the register is used to access a value in memory
|> ... which is then used to access another value in memory which is the operand
|> ... the register is decremented

Re: PDP-11-like ISA

<bce3fbd9-bc00-44b6-8520-bb7a841dd040n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17575&group=comp.arch#17575

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a0c:edcf:: with SMTP id i15mr3130702qvr.10.1623290531500; Wed, 09 Jun 2021 19:02:11 -0700 (PDT)
X-Received: by 2002:a54:4e81:: with SMTP id c1mr1773984oiy.119.1623290531186; Wed, 09 Jun 2021 19:02:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 9 Jun 2021 19:02:10 -0700 (PDT)
In-Reply-To: <7078174e-6311-4148-be32-525bdc14d950n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:38cb:6673:6d33:77a5; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:38cb:6673:6d33:77a5
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <7078174e-6311-4148-be32-525bdc14d950n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bce3fbd9-bc00-44b6-8520-bb7a841dd040n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 02:02:11 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 226
 by: MitchAlsup - Thu, 10 Jun 2021 02:02 UTC

On Wednesday, June 9, 2021 at 8:54:29 PM UTC-5, JimBrakefield wrote:
> On Wednesday, June 9, 2021 at 6:55:28 PM UTC-5, MitchAlsup wrote:
> > As I mentioned in Concertina II yesterday, there may be some way to implement
> > a PDP-11-like ISA and get reasonable performance and high code density.
> > This thread illustrates both.
> >
> > Consider an general address mode machine like the original PDP-11, except that
> > the 8 general registers are 64-bits wide, and that the virtual address space is
> > also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
> >
> > Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> > the opcode, the registers and their address modes; the address modes specifies
> > how the register participates in delivering an operand into a data manipulation.
> > The address modes are pure PDP-11;
> >
> > 000 the register is used directly in the calculation
> > 001 the register is used to access a value in memory which is the operand
> > 010 the register is used to access a value in memory which is the operand and
> > ... the register is incremented
> > 011 the register is used to access a value in memory
> > ... which is then used to access another value in memory which is the operand
> > ... the register is incremented
> > 100 the register is used to access a value in memory which is the operand and
> > ... the register is decremented
> > 101 the register is used to access a value in memory
> > ... which is then used to access another value in memory which is the operand
> > ... the register is decremented
> > 110 the register and the following 16-bit word displaement are added
> > ... and used to access a value in memory which is the operand
> >
> > 111 the register and the following 16-bit word displaement are added
> > ... and used to access a value in memory
> > ... which is then used to access another value in memory which is the operand
> >
> > I will use PDP-11 assembler writing style.
> >
> > Immediates, absolute addresses, relative addresses, and relative deferred
> > addresses are simple addresse modes applied to the IP register (R7)
> >
> > The stack is easily manipulated pushing, poping values by using address modes
> > on the stack pointing register (R6).
> >
> > The PDP-11 only had a 64KB address space originally, this new semi-derivative
> > has a 64-bit address space. In modern machines the number of general purpose
> > registers is 16-32 sometimes more. IN order to make up for only having 8 GPRs
> > I want us to consider that the 16-bit displacement addressing modes provide
> > access to 64KB of <you guessed it> registers ! 8192 of them !! each being 64-
> > bits wide. Now we end up using the deferred modes to access the memory those
> > registers point at; or these registers can hold actual data. {One would expect
> > HW acceleration in accessing this register file.}
> >
> > The Instruction Set Architecture is like many of those designed oh so long ago
> > in that it uses the update model of the PDP-11::
> >
> > AM( Src1 ) = AM( Src1 ) OpCode AM( Src2 )
> >
> > rather than the non-destructive register model of RISC instruction sets.. Since
> > the address modes are relatively powerful, you are not really destroying 8 GPR
> > registers "all that often" and when you do, you are getting 2 units of work out
> > of one instruction (even more if you could the extra memory references as use-
> > ful work.)
> >
> > So, given the 2 registers and the 2 address mode specifiers, we are left with
> > only 16 Major Opcodes. I assign these to the more significant powition in the
> > 16-bit instruction.
> >
> > Certain medium use instructions are not provided with full address mode support.
> > Integer Multiply, Divide, Floating point sacrifice one address mode on the Rs1
> > operand and become:
> >
> > Src1 = Src1 OpCode AM( Src2 )
> >
> > If we allow 4 of these formats we get 32 instructions, which cover medium usage
> > integer instructions, and all the 2-operand floating point instructions..
> >
> > Since we don't have to specify a second register for 1-operand instructions,
> > we sacrifice all 6-bits of the Src1 specifier and we have a format that provides
> >
> > AM( Src2 ) = OpCode{ AM( Src2 ) }
> >
> > And we have lots of room for 1-operand instructions (up to 128 if we need then.)
> >
> > Branch instructions use the IP deferred address mode giving ±64Kb (since we know
> > instructions are on halfword boundaries!) this covers the vast majority of branch
> > within subroutine boundaries.
> >
> > Assuming the compiler and linker conspire to use a portion of the memory mapped
> > registers for program linkage, Calls become an index deferred address mode into
> > those registers.
> >
> > --------------------------------------------------------------------------------
> >
> > The execution model of instructions if to consider that the front end of the
> > machine fetches 128-bits per cycle and is prepaired to lob as many instructions
> > as it can PARSE per cycle into reservation stations. The 8 GPRs are monitored
> > for dependencies {RAW, WAR, WAW} as are the 8K memory registers. This gives the
> > reservation stations enough dependency information to fetch GPRs and MRs in an
> > appropriate order with few constriants, and because actual memory accesses are
> > from these original dependencies, memory order is also known and can be followed.
> >
> > Other than this, the reservaton stations are multi-fire. That is the send a unit
> > of work into execution when the unit of work is in order and there is a function
> > unit to process the request. When a result returns, then next unit of work is
> > scheduled, and when all units of work are complete, the instruction retires out
> > of the reservation station.
> >
> > The example I illustrated yester day::
> >
> > ADD @disp1(R3),@disp2(R4)
> >
> > is a three (3) 16-bit parcel instruction PARSEd in one cycle. The reservation
> > station can issue: disp(R3) and disp2(r4) simultaneously, and assuming cache
> > hits, when both return 3-ish cycles later, the reservation station can issue
> > @disp(R3) and @disp2(R4) also simultaneously. When this set of data returns
> > the add is performed, and the result of the ADD is written to @disp2(r3). 6
> > units of work, 5 memory references and 3 arithmetic calculations (not counting
> > the IP increments to fetch disp1 and disp2).
> >
> > The front end will be in a position to detect::
> >
> > MOV Rk,AM( Rj )
> > OP AM( Ri ),Rk
> >
> > And CoIssue these into singel multi-fire reservation station "sequencers". This
> > makes up for the paltry 4-bit Major OpCode space with only a minor penalty in
> > code density. So for the 2-oprand instructions that are register and address
> > mode, there is a clean means to get OP AM( Rj ), AM( Rk )
> >
> > Now, while one wants { ADD, SUB, AND, OR, XOR, MOV } to share the 2-address mode
> > configurations, one nealry always wants CMP (compare) to use the register plus
> > address mode configuration. CMP feeds into Brnahces or Predicates, or COnvert
> > to TRUE or FALSE instructions. CMP × {BC, PC, SET} will always be CoIssued.
> >
> > SO, As I see it:: {MOV, ADD, SUB, AND, OR, XOR} are allocated to the 2-address
> > mode set (6 of 16), whiile {CMP, IMUL, IDIV, SR, SL, FADD, FSUB, FMUL, FDIV}
> > are allocated to the register plus address mode encoding space. It is convienent
> > to assign a different R+AM space for integer expansion and Floating Point.
> >
> > --------------------------------------------------------------------------------
> >
> > I am still thinking about data width being applied to Operands and results.
> Ugh, not sure it you are staying with original PDP11 pre-decrement modes
> or changing the implementation of those modes?
> The PDP11 register decrement modes decrement the register before use.
> (checked my yellowed PDP11 Processor Handbook)
> |> 100 the register is used to access a value in memory which is the operand and
> |> ... the register is decremented
> |> 101 the register is used to access a value in memory
> |> ... which is then used to access another value in memory which is the operand
> |> ... the register is decremented
<
Yes, of course you are correct, predecrement. Grrrrrrrrr (at me)


Click here to read the complete article
Re: PDP-11-like ISA

<312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17576&group=comp.arch#17576

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a0c:c3d1:: with SMTP id p17mr3205366qvi.44.1623293409033;
Wed, 09 Jun 2021 19:50:09 -0700 (PDT)
X-Received: by 2002:a9d:2287:: with SMTP id y7mr578562ota.22.1623293408808;
Wed, 09 Jun 2021 19:50:08 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 9 Jun 2021 19:50:08 -0700 (PDT)
In-Reply-To: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:f8e3:d700:5830:5211:29ff:f948;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:f8e3:d700:5830:5211:29ff:f948
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Thu, 10 Jun 2021 02:50:09 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Thu, 10 Jun 2021 02:50 UTC

On Wednesday, June 9, 2021 at 5:55:28 PM UTC-6, MitchAlsup wrote:
> As I mentioned in Concertina II yesterday, there may be some way to implement
> a PDP-11-like ISA and get reasonable performance and high code density.

I had been content to make the dense ISA I was adding to the Concertina II...
dense. I saw no hope of getting reasonable performance in a pipelined situation,
since to make it like a PDP-11, I am now using only banks of eight registers.

I'm not sure how to fix _that_, but I think there *is* a way to fix another of the horrible
inefficiencies a very PDP-11-like architecture has: all the operate instructions set the
condition codes.

If I get rid of one of the unnecessary CISC-y characterisics of the PDP-11, allowing the
*destination* operand to be in memory too... I free up bits. Enough to put in a bit
indicating if an operate instruction sets the condition codes.

John Savard

Re: PDP-11-like ISA

<356698e0-e7e2-4987-8960-0e90195d491fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17577&group=comp.arch#17577

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:70cf:: with SMTP id g15mr3273089qtp.360.1623296282662;
Wed, 09 Jun 2021 20:38:02 -0700 (PDT)
X-Received: by 2002:a05:6830:118c:: with SMTP id u12mr702923otq.82.1623296282415;
Wed, 09 Jun 2021 20:38:02 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 9 Jun 2021 20:38:02 -0700 (PDT)
In-Reply-To: <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:f8e3:d700:5830:5211:29ff:f948;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:f8e3:d700:5830:5211:29ff:f948
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <356698e0-e7e2-4987-8960-0e90195d491fn@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Thu, 10 Jun 2021 03:38:02 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Thu, 10 Jun 2021 03:38 UTC

On Wednesday, June 9, 2021 at 8:50:10 PM UTC-6, Quadibloc wrote:
> I saw no hope of getting reasonable performance in a pipelined situation,
> since to make it like a PDP-11, I am now using only banks of eight registers.

> I'm not sure how to fix _that_,

I've now replaced the PDP-11-like ISA by one where most of the instructions are
16 bits long, but there is access to all 32 registers. The price of that, though,
is that the ISA now only resembles the PDP-11 in a vestigial manner; the load-store
instructions have the four 9900 modes for their source operand only.

Also there is control over the condition codes being set, so the ISA is now as
reasonably efficient as any RISC ISA.

John Savard

Re: PDP-11-like ISA

<cyowI.31628$8f1.4834@fx23.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17586&group=comp.arch#17586

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx23.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: PDP-11-like ISA
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
In-Reply-To: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 93
Message-ID: <cyowI.31628$8f1.4834@fx23.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Thu, 10 Jun 2021 13:35:04 UTC
Date: Thu, 10 Jun 2021 09:33:44 -0400
X-Received-Bytes: 4161
 by: EricP - Thu, 10 Jun 2021 13:33 UTC

MitchAlsup wrote:
> As I mentioned in Concertina II yesterday, there may be some way to implement
> a PDP-11-like ISA and get reasonable performance and high code density.
> This thread illustrates both.
>
> Consider an general address mode machine like the original PDP-11, except that
> the 8 general registers are 64-bits wide, and that the virtual address space is
> also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
>
> Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> the opcode, the registers and their address modes; the address modes specifies
> how the register participates in delivering an operand into a data manipulation.
> The address modes are pure PDP-11;
>
> 000 the register is used directly in the calculation

PC = R7

PC should be illegal as a destination,
Should use branch instructions.

> 001 the register is used to access a value in memory which is the operand

> 010 the register is used to access a value in memory which is the operand and
> .... the register is incremented

register is post-incremented by the operand size

(PC)+ means operand size number of bytes immediately follow
On PDP-11 PC is incremented by 2 (PDP-11 word size).
On VAX PC is incremented by operand size.

> 011 the register is used to access a value in memory
> .... which is then used to access another value in memory which is the operand
> .... the register is incremented

register is post-incremented by the address size

@(PC)+ means the absolute address bytes immediately follow

> 100 the register is used to access a value in memory which is the operand and
> .... the register is decremented

register is pre-decremented by operand size

-(PC) should be illegal as it would decrement the incremented PC
back to that instruction and use it as an operand source or destination.

> 101 the register is used to access a value in memory
> .... which is then used to access another value in memory which is the operand
> .... the register is decremented

register is pre-decremented by address size

@-(PC) should be illegal as it would decrement the incremented PC
back to that instruction and use it as an operand address.

> 110 the register and the following 16-bit word displaement are added
> .... and used to access a value in memory which is the operand

DISP(PC) means program counter relative address of operand

Note on VAX DISP can be byte, word, or long.

> 111 the register and the following 16-bit word displaement are added
> .... and used to access a value in memory
> .... which is then used to access another value in memory which is the operand

@DISP(PC) means program counter relative address of address of operand

Note on VAX DISP can be byte, word, or long.

By the way, the VAX usage stats for address modes are:

%
Register Rn 42.9
Displacement D(Rn) 18.5
Short literal #n 13.8
PC-relative D(PC) 9.4
Register deferred (Rn) 7.1
Immediate (PC)+ 3.8
Disp deferred @D(Rn) 1.5
Autoincrement (Rn)+ 1.2
----
98.2%

The rest of the address modes total 1.8%, many are 0.0%.

The above can be indexed with an additional specifier,
which occurred 5.6% of the time.

Re: PDP-11-like ISA

<4a4110a3-5102-4f41-a2d3-1658d22c55ean@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17587&group=comp.arch#17587

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a0c:b38c:: with SMTP id t12mr1599956qve.44.1623334641073;
Thu, 10 Jun 2021 07:17:21 -0700 (PDT)
X-Received: by 2002:a9d:7612:: with SMTP id k18mr2668178otl.178.1623334640798;
Thu, 10 Jun 2021 07:17:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 07:17:20 -0700 (PDT)
In-Reply-To: <cyowI.31628$8f1.4834@fx23.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:a0d0:9f90:bd62:d7c5:aec5:e911;
posting-account=AoizIQoAAADa7kQDpB0DAj2jwddxXUgl
NNTP-Posting-Host: 2600:1700:a0d0:9f90:bd62:d7c5:aec5:e911
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <cyowI.31628$8f1.4834@fx23.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4a4110a3-5102-4f41-a2d3-1658d22c55ean@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jim.brak...@ieee.org (JimBrakefield)
Injection-Date: Thu, 10 Jun 2021 14:17:21 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 5171
 by: JimBrakefield - Thu, 10 Jun 2021 14:17 UTC

On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > As I mentioned in Concertina II yesterday, there may be some way to implement
> > a PDP-11-like ISA and get reasonable performance and high code density.
> > This thread illustrates both.
> >
> > Consider an general address mode machine like the original PDP-11, except that
> > the 8 general registers are 64-bits wide, and that the virtual address space is
> > also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
> >
> > Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> > the opcode, the registers and their address modes; the address modes specifies
> > how the register participates in delivering an operand into a data manipulation.
> > The address modes are pure PDP-11;
> >
> > 000 the register is used directly in the calculation
> PC = R7
>
> PC should be illegal as a destination,
> Should use branch instructions.
> > 001 the register is used to access a value in memory which is the operand
>
> > 010 the register is used to access a value in memory which is the operand and
> > .... the register is incremented
>
> register is post-incremented by the operand size
>
> (PC)+ means operand size number of bytes immediately follow
> On PDP-11 PC is incremented by 2 (PDP-11 word size).
> On VAX PC is incremented by operand size.
> > 011 the register is used to access a value in memory
> > .... which is then used to access another value in memory which is the operand
> > .... the register is incremented
>
> register is post-incremented by the address size
>
> @(PC)+ means the absolute address bytes immediately follow
> > 100 the register is used to access a value in memory which is the operand and
> > .... the register is decremented
>
> register is pre-decremented by operand size
>
> -(PC) should be illegal as it would decrement the incremented PC
> back to that instruction and use it as an operand source or destination.
> > 101 the register is used to access a value in memory
> > .... which is then used to access another value in memory which is the operand
> > .... the register is decremented
>
> register is pre-decremented by address size
>
> @-(PC) should be illegal as it would decrement the incremented PC
> back to that instruction and use it as an operand address.
> > 110 the register and the following 16-bit word displaement are added
> > .... and used to access a value in memory which is the operand
>
> DISP(PC) means program counter relative address of operand
>
> Note on VAX DISP can be byte, word, or long.
> > 111 the register and the following 16-bit word displaement are added
> > .... and used to access a value in memory
> > .... which is then used to access another value in memory which is the operand
>
> @DISP(PC) means program counter relative address of address of operand
>
> Note on VAX DISP can be byte, word, or long.
>
>
>
> By the way, the VAX usage stats for address modes are:
>
> %
> Register Rn 42.9
> Displacement D(Rn) 18.5
> Short literal #n 13.8
> PC-relative D(PC) 9.4
> Register deferred (Rn) 7.1
> Immediate (PC)+ 3.8
> Disp deferred @D(Rn) 1.5
> Autoincrement (Rn)+ 1.2
> ----
> 98.2%
>
> The rest of the address modes total 1.8%, many are 0.0%.
>
> The above can be indexed with an additional specifier,
> which occurred 5.6% of the time.

For VAX and PDP11 as well @(--Rn) and @(Rn+disp) are rarely used.
Culling them from a modified PDP11 ISA allows two additional codes that could be
used for (Rn+disp32) and (Rn+disp64) as well as the already present (Rn+disp16)

Use a 32-bit escape instruction format in addition to the 16-bit instruction formats and
everything stays half word aligned and decode is fast.
The 32-bit instruction format could support additional data sizes, additional registers
and plenty of op-codes.

Re: PDP-11-like ISA

<a4eda425-8edd-4fed-8ed4-928391a3966an@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17596&group=comp.arch#17596

 copy link   Newsgroups: comp.arch
X-Received: by 2002:aed:2166:: with SMTP id 93mr394735qtc.374.1623353286629;
Thu, 10 Jun 2021 12:28:06 -0700 (PDT)
X-Received: by 2002:a4a:1145:: with SMTP id 66mr186253ooc.14.1623353286386;
Thu, 10 Jun 2021 12:28:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!tncsrv06.tnetconsulting.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 12:28:06 -0700 (PDT)
In-Reply-To: <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a4eda425-8edd-4fed-8ed4-928391a3966an@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 19:28:06 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 28
 by: MitchAlsup - Thu, 10 Jun 2021 19:28 UTC

On Wednesday, June 9, 2021 at 9:50:10 PM UTC-5, Quadibloc wrote:
> On Wednesday, June 9, 2021 at 5:55:28 PM UTC-6, MitchAlsup wrote:
> > As I mentioned in Concertina II yesterday, there may be some way to implement
> > a PDP-11-like ISA and get reasonable performance and high code density.
<
> I had been content to make the dense ISA I was adding to the Concertina II...
> dense. I saw no hope of getting reasonable performance in a pipelined situation,
> since to make it like a PDP-11, I am now using only banks of eight registers.
<
My PDP-11 has 8 GPRs, which enable access to 8192 "registers", it is these
"registers" which do the heavy lifting, and HW is going to make these faster
that a typical memory ref, but slower than the 8 GPRs. Say, 1 cycle. Don't have
the scheme all worked out yet. But the thought is that the 8 GPRs are pointers
to sets of registers, and these registers will be put in a register cache so that
they have 1 ycle access (as opposed to 3 cycle typical memory access).
Also note, this whole memory space is 64-bit units, 64-bit aligned, indexed
by a 16-bit immediate in the instruction.
>
> I'm not sure how to fix _that_, but I think there *is* a way to fix another of the horrible
> inefficiencies a very PDP-11-like architecture has: all the operate instructions set the
> condition codes.
<
Well, My PDP-11 will not have condition codes....
>
> If I get rid of one of the unnecessary CISC-y characterisics of the PDP-11, allowing the
> *destination* operand to be in memory too... I free up bits. Enough to put in a bit
> indicating if an operate instruction sets the condition codes.
>
> John Savard

Re: PDP-11-like ISA

<257b9f1c-5f2d-4edb-b515-9fbcb8201737n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17597&group=comp.arch#17597

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ae9:c30f:: with SMTP id n15mr179674qkg.71.1623353447302; Thu, 10 Jun 2021 12:30:47 -0700 (PDT)
X-Received: by 2002:a4a:55c1:: with SMTP id e184mr174781oob.74.1623353447190; Thu, 10 Jun 2021 12:30:47 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 12:30:46 -0700 (PDT)
In-Reply-To: <356698e0-e7e2-4987-8960-0e90195d491fn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com> <356698e0-e7e2-4987-8960-0e90195d491fn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <257b9f1c-5f2d-4edb-b515-9fbcb8201737n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 19:30:47 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 22
 by: MitchAlsup - Thu, 10 Jun 2021 19:30 UTC

On Wednesday, June 9, 2021 at 10:38:03 PM UTC-5, Quadibloc wrote:
> On Wednesday, June 9, 2021 at 8:50:10 PM UTC-6, Quadibloc wrote:
> > I saw no hope of getting reasonable performance in a pipelined situation,
> > since to make it like a PDP-11, I am now using only banks of eight registers.
>
> > I'm not sure how to fix _that_,
<
> I've now replaced the PDP-11-like ISA by one where most of the instructions are
> 16 bits long, but there is access to all 32 registers. The price of that, though,
> is that the ISA now only resembles the PDP-11 in a vestigial manner; the load-store
> instructions have the four 9900 modes for their source operand only.
<
This is roughly how I was going to access the 8K registers, use 1 of the GPRs
to point at a set (32-64 registers) and then throw a HW cache at that memory
space.
>
> Also there is control over the condition codes being set, so the ISA is now as
> reasonably efficient as any RISC ISA.
<
My PDP-11 will have no condition codes, and will have certain instructions
which are guaranteed to CoIssue--like CMP-BC, LD-BEQ0,...
>
> John Savard

Re: PDP-11-like ISA

<465a2d40-4a01-4f47-b483-69a6ab88c746n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17598&group=comp.arch#17598

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a0c:8346:: with SMTP id j64mr1258648qva.16.1623353551887; Thu, 10 Jun 2021 12:32:31 -0700 (PDT)
X-Received: by 2002:a9d:12a9:: with SMTP id g38mr25471otg.114.1623353551650; Thu, 10 Jun 2021 12:32:31 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 12:32:31 -0700 (PDT)
In-Reply-To: <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <465a2d40-4a01-4f47-b483-69a6ab88c746n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 19:32:31 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 23
 by: MitchAlsup - Thu, 10 Jun 2021 19:32 UTC

On Wednesday, June 9, 2021 at 9:50:10 PM UTC-5, Quadibloc wrote:
> On Wednesday, June 9, 2021 at 5:55:28 PM UTC-6, MitchAlsup wrote:
> > As I mentioned in Concertina II yesterday, there may be some way to implement
> > a PDP-11-like ISA and get reasonable performance and high code density.
> I had been content to make the dense ISA I was adding to the Concertina II...
> dense. I saw no hope of getting reasonable performance in a pipelined situation,
> since to make it like a PDP-11, I am now using only banks of eight registers.
>
> I'm not sure how to fix _that_, but I think there *is* a way to fix another of the horrible
> inefficiencies a very PDP-11-like architecture has: all the operate instructions set the
> condition codes.
>
> If I get rid of one of the unnecessary CISC-y characterisics of the PDP-11, allowing the
> *destination* operand to be in memory too... I free up bits. Enough to put in a bit
> indicating if an operate instruction sets the condition codes.
<
Yes!!
<
OP AM( Rs1 ),AM( Rs2)
<
AM( Rs1) is used as both an operand and as a place to store the result--whatever
it happens to be !!
>
> John Savard

Re: PDP-11-like ISA

<dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17599&group=comp.arch#17599

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:154:: with SMTP id v20mr436912qtw.91.1623354126988; Thu, 10 Jun 2021 12:42:06 -0700 (PDT)
X-Received: by 2002:a9d:27a1:: with SMTP id c30mr36492otb.342.1623354126737; Thu, 10 Jun 2021 12:42:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 12:42:06 -0700 (PDT)
In-Reply-To: <cyowI.31628$8f1.4834@fx23.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <cyowI.31628$8f1.4834@fx23.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 19:42:06 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 117
 by: MitchAlsup - Thu, 10 Jun 2021 19:42 UTC

On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > As I mentioned in Concertina II yesterday, there may be some way to implement
> > a PDP-11-like ISA and get reasonable performance and high code density.
> > This thread illustrates both.
> >
> > Consider an general address mode machine like the original PDP-11, except that
> > the 8 general registers are 64-bits wide, and that the virtual address space is
> > also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
> >
> > Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> > the opcode, the registers and their address modes; the address modes specifies
> > how the register participates in delivering an operand into a data manipulation.
> > The address modes are pure PDP-11;
> >
> > 000 the register is used directly in the calculation
> PC = R7
>
> PC should be illegal as a destination,
<
How then do you perform RET (MOV R7,(SP)+) ?
How then do you perform CALI (MOV R7,disp(Rj) ) ?
<
> Should use branch instructions.
<
Branches are for "within" a subroutine.
<
> > 001 the register is used to access a value in memory which is the operand
>
> > 010 the register is used to access a value in memory which is the operand and
> > .... the register is incremented
>
> register is post-incremented by the operand size
>
> (PC)+ means operand size number of bytes immediately follow
> On PDP-11 PC is incremented by 2 (PDP-11 word size).
> On VAX PC is incremented by operand size.
> > 011 the register is used to access a value in memory
> > .... which is then used to access another value in memory which is the operand
> > .... the register is incremented
<
The "size thing" is a known (and a bit worrisome) problem with this thought train
right now.
>
> register is post-incremented by the address size
>
> @(PC)+ means the absolute address bytes immediately follow
<
It is likely that the PC accessing the instruction stream will have "special"
rules.....sort of like: if you push a byte in x86-64 mode the SP gets incremented
by 8.
<
> > 100 the register is used to access a value in memory which is the operand and
> > .... the register is decremented
>
> register is pre-decremented by operand size
<
Jim caught that one.
>
> -(PC) should be illegal as it would decrement the incremented PC
> back to that instruction and use it as an operand source or destination.
<
I might have to agree with this.
<
> > 101 the register is used to access a value in memory
> > .... which is then used to access another value in memory which is the operand
> > .... the register is decremented
>
> register is pre-decremented by address size
>
> @-(PC) should be illegal as it would decrement the incremented PC
> back to that instruction and use it as an operand address.
<
Same as above--however, I am pretty sure the PDP-11 would have simply
followed microcode and got itself in a pickle.
<
> > 110 the register and the following 16-bit word displaement are added
> > .... and used to access a value in memory which is the operand
>
> DISP(PC) means program counter relative address of operand
<
Sure.
>
> Note on VAX DISP can be byte, word, or long.
> > 111 the register and the following 16-bit word displaement are added
> > .... and used to access a value in memory
> > .... which is then used to access another value in memory which is the operand
>
> @DISP(PC) means program counter relative address of address of operand
>
> Note on VAX DISP can be byte, word, or long.
<
Known issue at this time.
>
>
>
> By the way, the VAX usage stats for address modes are:
>
> %
> Register Rn 42.9
> Displacement D(Rn) 18.5
> Short literal #n 13.8
> PC-relative D(PC) 9.4
> Register deferred (Rn) 7.1
> Immediate (PC)+ 3.8
> Disp deferred @D(Rn) 1.5
> Autoincrement (Rn)+ 1.2
> ----
> 98.2%
>
> The rest of the address modes total 1.8%, many are 0.0%.
<
I think every agrees, at this point in time, that VAX went a bit over the edge.
But, I am trying hard to resurrect something that smells like a PDP-11 but
with modern operand widths.
>
> The above can be indexed with an additional specifier,
> which occurred 5.6% of the time.

Re: PDP-11-like ISA

<e7118b96-2777-47a9-8e19-d3463bee87a8n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17600&group=comp.arch#17600

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:45a6:: with SMTP id y6mr1315743qvu.54.1623354457587;
Thu, 10 Jun 2021 12:47:37 -0700 (PDT)
X-Received: by 2002:a9d:19ed:: with SMTP id k100mr28604otk.329.1623354457341;
Thu, 10 Jun 2021 12:47:37 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 12:47:37 -0700 (PDT)
In-Reply-To: <4a4110a3-5102-4f41-a2d3-1658d22c55ean@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <4a4110a3-5102-4f41-a2d3-1658d22c55ean@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e7118b96-2777-47a9-8e19-d3463bee87a8n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 19:47:37 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Thu, 10 Jun 2021 19:47 UTC

On Thursday, June 10, 2021 at 9:17:22 AM UTC-5, JimBrakefield wrote:
> On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
> > MitchAlsup wrote:
> > > As I mentioned in Concertina II yesterday, there may be some way to implement
> > > a PDP-11-like ISA and get reasonable performance and high code density.
> > > This thread illustrates both.
> > >
> > > Consider an general address mode machine like the original PDP-11, except that
> > > the 8 general registers are 64-bits wide, and that the virtual address space is
> > > also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
> > >
> > > Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> > > the opcode, the registers and their address modes; the address modes specifies
> > > how the register participates in delivering an operand into a data manipulation.
> > > The address modes are pure PDP-11;

> For VAX and PDP11 as well @(--Rn) and @(Rn+disp) are rarely used.
> Culling them from a modified PDP11 ISA allows two additional codes that could be
> used for (Rn+disp32) and (Rn+disp64) as well as the already present (Rn+disp16)
<
Thank you for that idea.
>
> Use a 32-bit escape instruction format in addition to the 16-bit instruction formats and
> everything stays half word aligned and decode is fast.
<
I have an encoding scheme that allows for 8 AM+AM, 32 R+AM, and 128 1-operand AM.
A quick look see enables all of the simple integer, logical to use AM+AM, the difficult
integer, FP, and transcendentals to use Reg+AM, and there is plenty of room for 1-operand.
<
> The 32-bit instruction format could support additional data sizes, additional registers
> and plenty of op-codes.
<
I am trying hard not to need such a beast, but getting there looks straightforward.

Re: PDP-11-like ISA

<37b4cf2c-9ceb-41dd-9cc3-b53ba2326ab6n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17605&group=comp.arch#17605

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:4090:: with SMTP id f16mr1009669qko.225.1623365566024;
Thu, 10 Jun 2021 15:52:46 -0700 (PDT)
X-Received: by 2002:a9d:27a1:: with SMTP id c30mr517515otb.342.1623365565755;
Thu, 10 Jun 2021 15:52:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 15:52:45 -0700 (PDT)
In-Reply-To: <cyowI.31628$8f1.4834@fx23.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:f8e3:d700:458b:c4ba:60fa:5685;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:f8e3:d700:458b:c4ba:60fa:5685
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <cyowI.31628$8f1.4834@fx23.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <37b4cf2c-9ceb-41dd-9cc3-b53ba2326ab6n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Thu, 10 Jun 2021 22:52:46 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Thu, 10 Jun 2021 22:52 UTC

On Thursday, June 10, 2021 at 7:35:07 AM UTC-6, EricP wrote:

> PC should be illegal as a destination,
> Should use branch instructions.

Why not do it the other way around, and save an opcode?
The hardware could know that loading the PC _is_ a branch,
and therefore to take the necessary precautions with the
pipeline when it happens.

John Savard

Re: PDP-11-like ISA

<eeb20a94-4e7f-424a-a422-e9bbf63cc77cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17606&group=comp.arch#17606

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:6d15:: with SMTP id o21mr1226759qtt.54.1623365846275;
Thu, 10 Jun 2021 15:57:26 -0700 (PDT)
X-Received: by 2002:aca:f452:: with SMTP id s79mr521058oih.84.1623365846063;
Thu, 10 Jun 2021 15:57:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 15:57:25 -0700 (PDT)
In-Reply-To: <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:f8e3:d700:458b:c4ba:60fa:5685;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:f8e3:d700:458b:c4ba:60fa:5685
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <eeb20a94-4e7f-424a-a422-e9bbf63cc77cn@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Thu, 10 Jun 2021 22:57:26 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Thu, 10 Jun 2021 22:57 UTC

On Thursday, June 10, 2021 at 1:42:08 PM UTC-6, MitchAlsup wrote:
> On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:

> > Should use branch instructions.

> Branches are for "within" a subroutine.

I think he meant "should use regular jump instructions", and was *not*
specifically referring to the kind of "branch" instruction that the TMS 9900
and the PDP-11 had with a 256-bit signed displacement.

Those, indeed, are for within a single code module.

But I don't think he would make the mistake of thinking you could, say,
call the operating system library sine function with a 256-bit displacement
relative branch. Anyone would have known better than that, but not necessarily
everyone is familiar with how branch instructions worked on the PDP-11.

So I think you were being too harsh here.

John Savard

Re: PDP-11-like ISA

<1ac25337-6914-4fa2-868f-84910c66db85n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17607&group=comp.arch#17607

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:4e29:: with SMTP id d9mr1276161qtw.136.1623365934275;
Thu, 10 Jun 2021 15:58:54 -0700 (PDT)
X-Received: by 2002:a05:6830:1d1:: with SMTP id r17mr561373ota.5.1623365933972;
Thu, 10 Jun 2021 15:58:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 15:58:53 -0700 (PDT)
In-Reply-To: <37b4cf2c-9ceb-41dd-9cc3-b53ba2326ab6n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <37b4cf2c-9ceb-41dd-9cc3-b53ba2326ab6n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1ac25337-6914-4fa2-868f-84910c66db85n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 22:58:54 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Thu, 10 Jun 2021 22:58 UTC

On Thursday, June 10, 2021 at 5:52:46 PM UTC-5, Quadibloc wrote:
> On Thursday, June 10, 2021 at 7:35:07 AM UTC-6, EricP wrote:
>
> > PC should be illegal as a destination,
> > Should use branch instructions.
<
> Why not do it the other way around, and save an opcode?
> The hardware could know that loading the PC _is_ a branch,
> and therefore to take the necessary precautions with the
> pipeline when it happens.
<
I can see both sides of the argument, back in the PDP-11 days we were
more worried that we couldn't get something done, than we were about
not breaking something. At CMP we had a IBM 360/67 and were told
it had an impenetrable shield, we also had 3 PDP-10s of various {I,L,K}.
PDP-10s had two UUO instructions and if nobody installed the UUO
microcode anyone could crash the PDP-10--so NOBODY bothered to
TRY. On the other hand, we at CMU along with cohorts at MIT and Stanford
devised dozens of ways to take over the /67 and convert it to our uses
while time slicing what we did not need of the machine back to the actual
users so it would not stand out like a sore thumb.
<
On the other hand, there should be certain ways to use the IP as a destination
and make it safe by restricting the OpCOde and the address modes of the
other operand in order to allow the useful cases while preventing attacks.
>
> John Savard

Re: PDP-11-like ISA

<811b49bd-b077-4621-ab36-c5ca0be6a705n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17608&group=comp.arch#17608

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:40b:: with SMTP id n11mr1246766qtx.60.1623366184185;
Thu, 10 Jun 2021 16:03:04 -0700 (PDT)
X-Received: by 2002:a9d:4f18:: with SMTP id d24mr569036otl.16.1623366183947;
Thu, 10 Jun 2021 16:03:03 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 16:03:03 -0700 (PDT)
In-Reply-To: <eeb20a94-4e7f-424a-a422-e9bbf63cc77cn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
<eeb20a94-4e7f-424a-a422-e9bbf63cc77cn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <811b49bd-b077-4621-ab36-c5ca0be6a705n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 23:03:04 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Thu, 10 Jun 2021 23:03 UTC

On Thursday, June 10, 2021 at 5:57:27 PM UTC-5, Quadibloc wrote:
> On Thursday, June 10, 2021 at 1:42:08 PM UTC-6, MitchAlsup wrote:
> > On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
>
> > > Should use branch instructions.
>
> > Branches are for "within" a subroutine.
> I think he meant "should use regular jump instructions", and was *not*
> specifically referring to the kind of "branch" instruction that the TMS 9900
> and the PDP-11 had with a 256-bit signed displacement.
>
> Those, indeed, are for within a single code module.
>
> But I don't think he would make the mistake of thinking you could, say,
> call the operating system library sine function with a 256-bit displacement
> relative branch. Anyone would have known better than that, but not necessarily
> everyone is familiar with how branch instructions worked on the PDP-11.
>
> So I think you were being too harsh here.
<
I use the word branch in a precise manner which is based on IP+constant.
JUMPs do IP=register with no relativism.
<
High level languages do not allow control transfer across subroutine
boundaries (except for nested subroutines, and even here one is restricted
by the un-nested subroutine.) So, processors should not either. You want
trickery, use longjump.
>
> John Savard

Re: PDP-11-like ISA

<a33babcc-b7f9-410f-95c5-0fde1d5e5336n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17609&group=comp.arch#17609

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:4dd:: with SMTP id 29mr1086069qks.100.1623366273378;
Thu, 10 Jun 2021 16:04:33 -0700 (PDT)
X-Received: by 2002:a4a:e9b1:: with SMTP id t17mr692394ood.0.1623366273145;
Thu, 10 Jun 2021 16:04:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 16:04:32 -0700 (PDT)
In-Reply-To: <eeb20a94-4e7f-424a-a422-e9bbf63cc77cn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
<eeb20a94-4e7f-424a-a422-e9bbf63cc77cn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a33babcc-b7f9-410f-95c5-0fde1d5e5336n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 10 Jun 2021 23:04:33 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Thu, 10 Jun 2021 23:04 UTC

On Thursday, June 10, 2021 at 5:57:27 PM UTC-5, Quadibloc wrote:
> On Thursday, June 10, 2021 at 1:42:08 PM UTC-6, MitchAlsup wrote:
> > On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
>
> > > Should use branch instructions.
>
> > Branches are for "within" a subroutine.
<
> I think he meant "should use regular jump instructions", and was *not*
> specifically referring to the kind of "branch" instruction that the TMS 9900
> and the PDP-11 had with a 256-bit signed displacement.
<
What if the ISA has ip=whatever IS the JMP instruction ?
<
I mean it falls out for free! especially is IP is part of the register file.
>
> Those, indeed, are for within a single code module.
>
> But I don't think he would make the mistake of thinking you could, say,
> call the operating system library sine function with a 256-bit displacement
> relative branch. Anyone would have known better than that, but not necessarily
> everyone is familiar with how branch instructions worked on the PDP-11.
>
> So I think you were being too harsh here.
>
> John Savard

Re: PDP-11-like ISA

<j0ywI.36041$431.5756@fx39.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17610&group=comp.arch#17610

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: PDP-11-like ISA
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
In-Reply-To: <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 192
Message-ID: <j0ywI.36041$431.5756@fx39.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Fri, 11 Jun 2021 00:21:35 UTC
Date: Thu, 10 Jun 2021 20:20:57 -0400
X-Received-Bytes: 8002
 by: EricP - Fri, 11 Jun 2021 00:20 UTC

MitchAlsup wrote:
> On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
>> MitchAlsup wrote:
>>> As I mentioned in Concertina II yesterday, there may be some way to implement
>>> a PDP-11-like ISA and get reasonable performance and high code density.
>>> This thread illustrates both.
>>>
>>> Consider an general address mode machine like the original PDP-11, except that
>>> the 8 general registers are 64-bits wide, and that the virtual address space is
>>> also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
>>>
>>> Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
>>> the opcode, the registers and their address modes; the address modes specifies
>>> how the register participates in delivering an operand into a data manipulation.
>>> The address modes are pure PDP-11;
>>>
>>> 000 the register is used directly in the calculation
>> PC = R7
>>
>> PC should be illegal as a destination,
> <
> How then do you perform RET (MOV R7,(SP)+) ?
> How then do you perform CALI (MOV R7,disp(Rj) ) ?

PDP-11 has JSR and RTS which use a linkage register.

If you really want CALL and RET instructions that imply
pushing and popping R7 on the R6 stack then have those instructions.

PUSH reg and POP reg with (R6) inc/dec implied is more efficient.
However since no modern prologue or epilogue would use PUSH or POP
I really don't see the need for them.

That eliminates 99% of the use of auto increment and decrement,
as the VAX usage stats show. Anything left would be for strength
reduction on loop indexed array access, and Add Tiny handles that.

So toss out auto inc/dec address modes and put in two instructions

// pdp-11 asm has dest reg on the right
ADDTY #tiny,reg Add Tiny
SUBTY #tiny,reg Subtract Tiny

where tiny is 1..7 and 0 means 8. Much more generally useful.

> <
>> Should use branch instructions.
> <
> Branches are for "within" a subroutine.

I mean there is no need to be able to write R7 in all
integer and logical instructions.

// pdp-11 asm has dest reg on the right
DIV r3,r7
AND #123,r7

Only branch, bsr, jmp, jsr, instructions should be allowed to modify R7.
If you really, really want to do a DIV into R7 then do

BAL #0,r2 // copy r7 -> r2
DIV r3,r2
JMP r2

Or special case R7 similar to how My 66000 handles R0.

> <
>>> 001 the register is used to access a value in memory which is the operand
>>> 010 the register is used to access a value in memory which is the operand and
>>> .... the register is incremented
>> register is post-incremented by the operand size
>>
>> (PC)+ means operand size number of bytes immediately follow
>> On PDP-11 PC is incremented by 2 (PDP-11 word size).
>> On VAX PC is incremented by operand size.
>>> 011 the register is used to access a value in memory
>>> .... which is then used to access another value in memory which is the operand
>>> .... the register is incremented
> <
> The "size thing" is a known (and a bit worrisome) problem with this thought train
> right now.

If all the integer, logical and float operations can reference memory,
then all must specify operand sizes and sign/zero extension.

This is why the VAX first instruction byte was just for opcode.
Unfortunately they squandered it on useless instructions
which is why the needed a second opcode byte.

>> register is post-incremented by the address size
>>
>> @(PC)+ means the absolute address bytes immediately follow
> <
> It is likely that the PC accessing the instruction stream will have "special"
> rules.....sort of like: if you push a byte in x86-64 mode the SP gets incremented
> by 8.
> <

You might be able to eliminate Deferred mode altogether,
though I know you wanted to use it compensate for small register set,

Since mode 001 (R7) is meaningless you might cheat and define that
if (mode == 001) and (reg == R7) then immediate absolute address follows.

That eliminates the one use for general deferred address mode.

>>> 100 the register is used to access a value in memory which is the operand and
>>> .... the register is decremented
>> register is pre-decremented by operand size
> <
> Jim caught that one.
>> -(PC) should be illegal as it would decrement the incremented PC
>> back to that instruction and use it as an operand source or destination.
> <
> I might have to agree with this.
> <
>>> 101 the register is used to access a value in memory
>>> .... which is then used to access another value in memory which is the operand
>>> .... the register is decremented
>> register is pre-decremented by address size
>>
>> @-(PC) should be illegal as it would decrement the incremented PC
>> back to that instruction and use it as an operand address.
> <
> Same as above--however, I am pretty sure the PDP-11 would have simply
> followed microcode and got itself in a pickle.
> <

I am too.

MOVW -(PC),(PC)

would likely fetch the MOV instruction, increment the PC,
pre-decrement the PC back where it was, load the MOV instruction,
store the move instruction back where it was,
fetch and execute the MOV again an a tight loop.

>>> 110 the register and the following 16-bit word displaement are added
>>> .... and used to access a value in memory which is the operand
>> DISP(PC) means program counter relative address of operand
> <
> Sure.
>> Note on VAX DISP can be byte, word, or long.
>>> 111 the register and the following 16-bit word displaement are added
>>> .... and used to access a value in memory
>>> .... which is then used to access another value in memory which is the operand
>> @DISP(PC) means program counter relative address of address of operand
>>
>> Note on VAX DISP can be byte, word, or long.
> <
> Known issue at this time.
>>
>>
>> By the way, the VAX usage stats for address modes are:
>>
>> %
>> Register Rn 42.9
>> Displacement D(Rn) 18.5
>> Short literal #n 13.8
>> PC-relative D(PC) 9.4
>> Register deferred (Rn) 7.1
>> Immediate (PC)+ 3.8
>> Disp deferred @D(Rn) 1.5
>> Autoincrement (Rn)+ 1.2
>> ----
>> 98.2%
>>
>> The rest of the address modes total 1.8%, many are 0.0%.
> <
> I think every agrees, at this point in time, that VAX went a bit over the edge.
> But, I am trying hard to resurrect something that smells like a PDP-11 but
> with modern operand widths.

Right, but those VAX address modes are the same as the PDP-11 ones.
So one question is to what extent those stats also apply?

You might be able to eliminate Deferred, AutoInc and AutoDec modes.

>> The above can be indexed with an additional specifier,
>> which occurred 5.6% of the time.

You might also get an indexed address mode in there
since the mode and reg fields are both 3 bits,
we can reuse one of the mode fields to hold a register number.
Then one of the modes, say source, can specify either an
indexed source and register dest, or register source and indexed dest.

ADDW [rBase + rIndex*operand_size], rDst
MULQ rSrc, [rBase + rIndex*operand_size]

Re: PDP-11-like ISA

<ac0da74d-b52b-4b52-b25e-cf1070ce5e04n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17611&group=comp.arch#17611

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:100e:: with SMTP id d14mr1771345qte.254.1623375153201;
Thu, 10 Jun 2021 18:32:33 -0700 (PDT)
X-Received: by 2002:aca:4703:: with SMTP id u3mr798603oia.37.1623375152869;
Thu, 10 Jun 2021 18:32:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 18:32:32 -0700 (PDT)
In-Reply-To: <j0ywI.36041$431.5756@fx39.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:9c97:15b4:6004:2552;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:9c97:15b4:6004:2552
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
<j0ywI.36041$431.5756@fx39.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ac0da74d-b52b-4b52-b25e-cf1070ce5e04n@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Fri, 11 Jun 2021 01:32:33 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Fri, 11 Jun 2021 01:32 UTC

On Thursday, June 10, 2021 at 7:21:39 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
> >> MitchAlsup wrote:
> >>> As I mentioned in Concertina II yesterday, there may be some way to implement
> >>> a PDP-11-like ISA and get reasonable performance and high code density.
> >>> This thread illustrates both.
> >>>
> >>> Consider an general address mode machine like the original PDP-11, except that
> >>> the 8 general registers are 64-bits wide, and that the virtual address space is
> >>> also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
> >>>
> >>> Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> >>> the opcode, the registers and their address modes; the address modes specifies
> >>> how the register participates in delivering an operand into a data manipulation.
> >>> The address modes are pure PDP-11;
> >>>
> >>> 000 the register is used directly in the calculation
> >> PC = R7
> >>
> >> PC should be illegal as a destination,
> > <
> > How then do you perform RET (MOV R7,(SP)+) ?
> > How then do you perform CALI (MOV R7,disp(Rj) ) ?
<
> PDP-11 has JSR and RTS which use a linkage register.
<
Not so much linkage, but intermediary.
>
> If you really want CALL and RET instructions that imply
> pushing and popping R7 on the R6 stack then have those instructions.
<
If you can express the semantics without having those instructions, why not ?
>
> PUSH reg and POP reg with (R6) inc/dec implied is more efficient.
> However since no modern prologue or epilogue would use PUSH or POP
> I really don't see the need for them.
<
Remember, I am trying to bring PDP-11 into the modern age and with
64-bit as the std operand size, and to use disp(pc) to access more
registers (like 1k-8K registers) with HW support that makes this
subsection of memory almost as fast as R0-R7. A restriction one
gets to that section is memory is everything in it is 64-bits in size.
This allows me to scavenge bits to denote size and maybe a few
other odds and ends.
>
> That eliminates 99% of the use of auto increment and decrement,
> as the VAX usage stats show. Anything left would be for strength
> reduction on loop indexed array access, and Add Tiny handles that.
>
> So toss out auto inc/dec address modes and put in two instructions
>
> // pdp-11 asm has dest reg on the right
> ADDTY #tiny,reg Add Tiny
> SUBTY #tiny,reg Subtract Tiny
>
> where tiny is 1..7 and 0 means 8. Much more generally useful.
> > <
> >> Should use branch instructions.
> > <
> > Branches are for "within" a subroutine.
> I mean there is no need to be able to write R7 in all
> integer and logical instructions.
<
I remain unconvinced.
>
> // pdp-11 asm has dest reg on the right
> DIV r3,r7
> AND #123,r7
<
Its my architecture, I can position the fields and write the ASM in the
direction I am accustomed. You may do the same with yours.
>
> Only branch, bsr, jmp, jsr, instructions should be allowed to modify R7.
> If you really, really want to do a DIV into R7 then do
>
> BAL #0,r2 // copy r7 -> r2
> DIV r3,r2
> JMP r2
<
This is an argument that IP should not be part of the GPRs, not that
existing instructions should not be used.
>
> Or special case R7 similar to how My 66000 handles R0.
<
I have been thinking about this, back on this topic a bit later.
> > <
> >>> 001 the register is used to access a value in memory which is the operand
> >>> 010 the register is used to access a value in memory which is the operand and
> >>> .... the register is incremented
> >> register is post-incremented by the operand size
> >>
> >> (PC)+ means operand size number of bytes immediately follow
> >> On PDP-11 PC is incremented by 2 (PDP-11 word size).
> >> On VAX PC is incremented by operand size.
> >>> 011 the register is used to access a value in memory
> >>> .... which is then used to access another value in memory which is the operand
> >>> .... the register is incremented
> > <
> > The "size thing" is a known (and a bit worrisome) problem with this thought train
> > right now.
<
> If all the integer, logical and float operations can reference memory,
> then all must specify operand sizes and sign/zero extension.
<
I am working on a general solution to this without blowing the 16-bit
AM+AM architecture. {I may also fail here}
>
> This is why the VAX first instruction byte was just for opcode.
> Unfortunately they squandered it on useless instructions
<
BINGO !!
<
> which is why the needed a second opcode byte.
> >> register is post-incremented by the address size
> >>
> >> @(PC)+ means the absolute address bytes immediately follow
> > <
> > It is likely that the PC accessing the instruction stream will have "special"
> > rules.....sort of like: if you push a byte in x86-64 mode the SP gets incremented
> > by 8.
> > <
> You might be able to eliminate Deferred mode altogether,
> though I know you wanted to use it compensate for small register set,
<
My current train of thought is that when one used AM=11x (6 or 7) and R0
then the 16-bit immediate is used too access 1K-8K of registers, the lower
order 3-bits is used to denote size and signedness, and depending on a lot
of things, the upper order bits could be used for other purposes {saturation
SIMD,Decimal,...}
>
> Since mode 001 (R7) is meaningless you might cheat and define that
> if (mode == 001) and (reg == R7) then immediate absolute address follows.
>
> That eliminates the one use for general deferred address mode.
> >>> 100 the register is used to access a value in memory which is the operand and
> >>> .... the register is decremented
> >> register is pre-decremented by operand size
> > <
> > Jim caught that one.
> >> -(PC) should be illegal as it would decrement the incremented PC
> >> back to that instruction and use it as an operand source or destination.
> > <
> > I might have to agree with this.
> > <
> >>> 101 the register is used to access a value in memory
> >>> .... which is then used to access another value in memory which is the operand
> >>> .... the register is decremented
> >> register is pre-decremented by address size
> >>
> >> @-(PC) should be illegal as it would decrement the incremented PC
> >> back to that instruction and use it as an operand address.
> > <
> > Same as above--however, I am pretty sure the PDP-11 would have simply
> > followed microcode and got itself in a pickle.
> > <
> I am too.
>
> MOVW -(PC),(PC)
>
> would likely fetch the MOV instruction, increment the PC,
> pre-decrement the PC back where it was, load the MOV instruction,
> store the move instruction back where it was,
> fetch and execute the MOV again an a tight loop.
<
At least it would cache well......
<
> >>> 110 the register and the following 16-bit word displaement are added
> >>> .... and used to access a value in memory which is the operand
> >> DISP(PC) means program counter relative address of operand
> > <
> > Sure.
> >> Note on VAX DISP can be byte, word, or long.
> >>> 111 the register and the following 16-bit word displaement are added
> >>> .... and used to access a value in memory
> >>> .... which is then used to access another value in memory which is the operand
> >> @DISP(PC) means program counter relative address of address of operand
> >>
> >> Note on VAX DISP can be byte, word, or long.
> > <
> > Known issue at this time.
> >>
> >>
> >> By the way, the VAX usage stats for address modes are:
> >>
> >> %
> >> Register Rn 42.9
> >> Displacement D(Rn) 18.5
> >> Short literal #n 13.8
> >> PC-relative D(PC) 9.4
> >> Register deferred (Rn) 7.1
> >> Immediate (PC)+ 3.8
> >> Disp deferred @D(Rn) 1.5
> >> Autoincrement (Rn)+ 1.2
> >> ----
> >> 98.2%
> >>
> >> The rest of the address modes total 1.8%, many are 0.0%.
> > <
> > I think every agrees, at this point in time, that VAX went a bit over the edge.
> > But, I am trying hard to resurrect something that smells like a PDP-11 but
> > with modern operand widths.
<
> Right, but those VAX address modes are the same as the PDP-11 ones.
> So one question is to what extent those stats also apply?
<
VAX only had 16 registers. Machines with 16 registers tended to be LD-Op oriented
whereas machines with 32 (or more) registers tend to be LD/ST and 2-operand
1-result.
<
I am trying for something different, having 8 registers that control stuff,
and having a big register file (1K-8K 64-bit entries) that can be accessed
in one cycle (sort of like a smaller register file), but:: The GPR file only
accesses 64-bit things, the large file can access things based on a size.
So::
disp(r0):SB
says that the data in R[disp>>3] contains a signed byte
@disp(R0):UH
says the 64-bit data in R[disp>>3] points at an unsigned Halfword anywhere in
memory.
I will have to figure out some better ASM mnemonics.
<
But this is not some kind of RISC machine with a small and large pair of
register files, it is an address mode machine; and accessing the large
file eats instruction stream area.
>
> You might be able to eliminate Deferred, AutoInc and AutoDec modes.
> >> The above can be indexed with an additional specifier,
> >> which occurred 5.6% of the time.
> You might also get an indexed address mode in there
> since the mode and reg fields are both 3 bits,
> we can reuse one of the mode fields to hold a register number.
> Then one of the modes, say source, can specify either an
> indexed source and register dest, or register source and indexed dest.
>
> ADDW [rBase + rIndex*operand_size], rDst
> MULQ rSrc, [rBase + rIndex*operand_size]
<
This is a worthy addition.


Click here to read the complete article
Re: PDP-11-like ISA

<3a9993ac-f28e-4cac-9c2b-a392a9ae68ebn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17612&group=comp.arch#17612

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2ec:: with SMTP id a12mr1728093qko.92.1623379270851; Thu, 10 Jun 2021 19:41:10 -0700 (PDT)
X-Received: by 2002:a9d:1d49:: with SMTP id m67mr1155358otm.76.1623379270619; Thu, 10 Jun 2021 19:41:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 10 Jun 2021 19:41:10 -0700 (PDT)
In-Reply-To: <e7118b96-2777-47a9-8e19-d3463bee87a8n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:a0d0:9f90:dd16:cf5c:ef2c:edea; posting-account=AoizIQoAAADa7kQDpB0DAj2jwddxXUgl
NNTP-Posting-Host: 2600:1700:a0d0:9f90:dd16:cf5c:ef2c:edea
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <cyowI.31628$8f1.4834@fx23.iad> <4a4110a3-5102-4f41-a2d3-1658d22c55ean@googlegroups.com> <e7118b96-2777-47a9-8e19-d3463bee87a8n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3a9993ac-f28e-4cac-9c2b-a392a9ae68ebn@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: jim.brak...@ieee.org (JimBrakefield)
Injection-Date: Fri, 11 Jun 2021 02:41:10 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 53
 by: JimBrakefield - Fri, 11 Jun 2021 02:41 UTC

On Thursday, June 10, 2021 at 2:47:38 PM UTC-5, MitchAlsup wrote:
> On Thursday, June 10, 2021 at 9:17:22 AM UTC-5, JimBrakefield wrote:
> > On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
> > > MitchAlsup wrote:
> > > > As I mentioned in Concertina II yesterday, there may be some way to implement
> > > > a PDP-11-like ISA and get reasonable performance and high code density.
> > > > This thread illustrates both.
> > > >
> > > > Consider an general address mode machine like the original PDP-11, except that
> > > > the 8 general registers are 64-bits wide, and that the virtual address space is
> > > > also a 64-bit address space. As with the PDP-11, R7 is the IP and R6 is the SP.
> > > >
> > > > Instructions are a series of 16-bit halfwords, the first 16-bit parcel denotes
> > > > the opcode, the registers and their address modes; the address modes specifies
> > > > how the register participates in delivering an operand into a data manipulation.
> > > > The address modes are pure PDP-11;
> > For VAX and PDP11 as well @(--Rn) and @(Rn+disp) are rarely used.
> > Culling them from a modified PDP11 ISA allows two additional codes that could be
> > used for (Rn+disp32) and (Rn+disp64) as well as the already present (Rn+disp16)
> <
> Thank you for that idea.
> >
> > Use a 32-bit escape instruction format in addition to the 16-bit instruction formats and
> > everything stays half word aligned and decode is fast.
> <
> I have an encoding scheme that allows for 8 AM+AM, 32 R+AM, and 128 1-operand AM.
> A quick look see enables all of the simple integer, logical to use AM+AM, the difficult
> integer, FP, and transcendentals to use Reg+AM, and there is plenty of room for 1-operand.
> <
> > The 32-bit instruction format could support additional data sizes, additional registers
> > and plenty of op-codes.
> <
> I am trying hard not to need such a beast, but getting there looks straightforward.

|> > The 32-bit instruction format could support additional data sizes, additional registers
|> > and plenty of op-codes.

|> I am trying hard not to need such a beast, but getting there looks straightforward.

By using the 17XXXX (octal) floating-point op-codes for an escape to a longer instruction format,
the two RM fields stay put for consistent decoding.
A 24-bit instruction would have an additional byte for two bits of data size and six bits of op-code.
A 32-bit instruction would have room for ibid. and a third 6-bit RM field and two remaining bits.
(chose one, not both of the above)

The non-17XXXX instructions would have the original PDP11 meanings on 8-bit bytes and 64-bit words.
Which is great for nostalgia, maybe not so great for implementation/performance?

Think that the call stack and frame memory should be cached separately from other data.
In other words, there are two sets of stack/frame memory, the small stuff and the big stuff (arrays & such).

The original PDP11 had 64KB, which is 8K 64-bit values. A little large for a L1 cache but not overly so.
So treating the, say, first 64KB of memory as the repose of 64-bit stack and frame data with byte
addressability would fit my idea of a PDP11 upgrade/modernization ISA.

Re: PDP-11-like ISA

<s9vj68$1h6$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17615&group=comp.arch#17615

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!WFgAfjdMCLK7ItoF6n4UQQ.user.gioia.aioe.org.POSTED!not-for-mail
From: chris-no...@tridac.net (chris)
Newsgroups: comp.arch
Subject: Re: PDP-11-like ISA
Date: Fri, 11 Jun 2021 12:59:05 +0100
Organization: Aioe.org NNTP Server
Lines: 44
Message-ID: <s9vj68$1h6$1@gioia.aioe.org>
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <312431da-80d8-4e85-8e8c-ebc814ab099en@googlegroups.com>
NNTP-Posting-Host: WFgAfjdMCLK7ItoF6n4UQQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Fri, 11 Jun 2021 11:59 UTC

On 06/10/21 03:50, Quadibloc wrote:
> On Wednesday, June 9, 2021 at 5:55:28 PM UTC-6, MitchAlsup wrote:
>> As I mentioned in Concertina II yesterday, there may be some way to implement
>> a PDP-11-like ISA and get reasonable performance and high code density.
>
> I had been content to make the dense ISA I was adding to the Concertina II...
> dense. I saw no hope of getting reasonable performance in a pipelined situation,
> since to make it like a PDP-11, I am now using only banks of eight registers.
>
> I'm not sure how to fix _that_, but I think there *is* a way to fix another of the horrible
> inefficiencies a very PDP-11-like architecture has: all the operate instructions set the
> condition codes.

Opinions may vary, but if you were an assembler programmer back in the
days when memory was tight and machines were slow, the fact that
condition codes are set with many instructions, was of great
benefit. Compared to Intel style arch, where a laborious test is
needed before a branch, with pdp11, I can do a branch immediately
following a mov, for example, which saves memory and improves
efficiency.

A very orthoganal architecture, where just about every instruction
works with any addressing mode, register and memory if it sounds
sensible, powerful indirect addressing modes and consistent
instruction encoding. Become fluent in that and more can be
done in a page of macro 11 that takes some architectures much
more.

Different age I guess. Most programming is done in hll these days
and machines are rarely memory constrained, but an updated pdp11
arch for the modern age would be most welcome. Closest i've seen
was the MSP430 form TI, but early versions were memory and
flash limited and never found a project to use it. Gate array
perhaps ?...

Chris

>
> If I get rid of one of the unnecessary CISC-y characterisics of the PDP-11, allowing the
> *destination* operand to be in memory too... I free up bits. Enough to put in a bit
> indicating if an operate instruction sets the condition codes.
>
> John Savard

Re: PDP-11-like ISA

<s9voen$do7$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17617&group=comp.arch#17617

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!Z/OnjRNZ74xzNAVdC5cKTg.user.gioia.aioe.org.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: PDP-11-like ISA
Date: Fri, 11 Jun 2021 15:28:56 +0200
Organization: Aioe.org NNTP Server
Lines: 55
Message-ID: <s9voen$do7$1@gioia.aioe.org>
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad>
<dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
<j0ywI.36041$431.5756@fx39.iad>
NNTP-Posting-Host: Z/OnjRNZ74xzNAVdC5cKTg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.7.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Fri, 11 Jun 2021 13:28 UTC

EricP wrote:
> MitchAlsup wrote:
>> On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
>>> MitchAlsup wrote:
>>>> As I mentioned in Concertina II yesterday, there may be some way to
>>>> implement a PDP-11-like ISA and get reasonable performance and high
>>>> code density. This thread illustrates both.
>>>> Consider an general address mode machine like the original PDP-11,
>>>> except that the 8 general registers are 64-bits wide, and that the
>>>> virtual address space is also a 64-bit address space. As with the
>>>> PDP-11, R7 is the IP and R6 is the SP.
>>>> Instructions are a series of 16-bit halfwords, the first 16-bit
>>>> parcel denotes the opcode, the registers and their address modes;
>>>> the address modes specifies how the register participates in
>>>> delivering an operand into a data manipulation. The address modes
>>>> are pure PDP-11;
>>>> 000 the register is used directly in the calculation
>>> PC = R7
>>> PC should be illegal as a destination,
>> <
>> How then do you perform RET  (MOV  R7,(SP)+) ?
>> How then do you perform CALI (MOV  R7,disp(Rj) ) ?
>
> PDP-11 has JSR and RTS which use a linkage register.
>
> If you really want CALL and RET instructions that imply
> pushing and popping R7 on the R6 stack then have those instructions.
>
> PUSH reg and POP reg with (R6) inc/dec implied is more efficient.
> However since no modern prologue or epilogue would use PUSH or POP
> I really don't see the need for them.
>
> That eliminates 99% of the use of auto increment and decrement,
> as the VAX usage stats show. Anything left would be for strength
> reduction on loop indexed array access, and Add Tiny handles that.
>
> So toss out auto inc/dec address modes and put in two instructions
>
>   // pdp-11 asm has dest reg on the right
>   ADDTY #tiny,reg   Add Tiny
>   SUBTY #tiny,reg   Subtract Tiny
>
> where tiny is 1..7 and 0 means 8. Much more generally useful.

I would rather have 0..7 meaning 1..8, since this is trivially achieved
by always enabling an incoming carry to the address adder.
Special-casing 0 to mean 8 seems like it would need more gates?

I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: PDP-11-like ISA

<8iKwI.317313$N_4.28704@fx36.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17618&group=comp.arch#17618

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: PDP-11-like ISA
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com> <cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com> <j0ywI.36041$431.5756@fx39.iad> <s9voen$do7$1@gioia.aioe.org>
In-Reply-To: <s9voen$do7$1@gioia.aioe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 29
Message-ID: <8iKwI.317313$N_4.28704@fx36.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Fri, 11 Jun 2021 14:19:48 UTC
Date: Fri, 11 Jun 2021 10:19:15 -0400
X-Received-Bytes: 1806
 by: EricP - Fri, 11 Jun 2021 14:19 UTC

Terje Mathisen wrote:
> EricP wrote:
>>
>> So toss out auto inc/dec address modes and put in two instructions
>>
>> // pdp-11 asm has dest reg on the right
>> ADDTY #tiny,reg Add Tiny
>> SUBTY #tiny,reg Subtract Tiny
>>
>> where tiny is 1..7 and 0 means 8. Much more generally useful.
>
> I would rather have 0..7 meaning 1..8, since this is trivially achieved
> by always enabling an incoming carry to the address adder.
> Special-casing 0 to mean 8 seems like it would need more gates?
>
> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
>
> Terje

1..7, 0 => 8 allows the 3 lower bits to be used directly
and a 3-input NOR-3 gate to drive the 4th bit.

0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
an AND-2 and an AND-3 carry lookaheads.

Its in the decoder and there are other more expensive things there,
so it wouldn't be on the critical path either way.

Re: PDP-11-like ISA

<121bdc96-e76a-4b2f-8fec-7465378f51den@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17621&group=comp.arch#17621

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:c447:: with SMTP id h7mr4131037qkm.63.1623423575504;
Fri, 11 Jun 2021 07:59:35 -0700 (PDT)
X-Received: by 2002:a9d:4f18:: with SMTP id d24mr3433789otl.16.1623423575305;
Fri, 11 Jun 2021 07:59:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Fri, 11 Jun 2021 07:59:35 -0700 (PDT)
In-Reply-To: <s9voen$do7$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:a87a:6554:33a2:4294;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:a87a:6554:33a2:4294
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
<j0ywI.36041$431.5756@fx39.iad> <s9voen$do7$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <121bdc96-e76a-4b2f-8fec-7465378f51den@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Fri, 11 Jun 2021 14:59:35 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3863
 by: MitchAlsup - Fri, 11 Jun 2021 14:59 UTC

On Friday, June 11, 2021 at 8:28:59 AM UTC-5, Terje Mathisen wrote:
> EricP wrote:
> > MitchAlsup wrote:
> >> On Thursday, June 10, 2021 at 8:35:07 AM UTC-5, EricP wrote:
> >>> MitchAlsup wrote:
> >>>> As I mentioned in Concertina II yesterday, there may be some way to
> >>>> implement a PDP-11-like ISA and get reasonable performance and high
> >>>> code density. This thread illustrates both.
> >>>> Consider an general address mode machine like the original PDP-11,
> >>>> except that the 8 general registers are 64-bits wide, and that the
> >>>> virtual address space is also a 64-bit address space. As with the
> >>>> PDP-11, R7 is the IP and R6 is the SP.
> >>>> Instructions are a series of 16-bit halfwords, the first 16-bit
> >>>> parcel denotes the opcode, the registers and their address modes;
> >>>> the address modes specifies how the register participates in
> >>>> delivering an operand into a data manipulation. The address modes
> >>>> are pure PDP-11;
> >>>> 000 the register is used directly in the calculation
> >>> PC = R7
> >>> PC should be illegal as a destination,
> >> <
> >> How then do you perform RET (MOV R7,(SP)+) ?
> >> How then do you perform CALI (MOV R7,disp(Rj) ) ?
> >
> > PDP-11 has JSR and RTS which use a linkage register.
> >
> > If you really want CALL and RET instructions that imply
> > pushing and popping R7 on the R6 stack then have those instructions.
> >
> > PUSH reg and POP reg with (R6) inc/dec implied is more efficient.
> > However since no modern prologue or epilogue would use PUSH or POP
> > I really don't see the need for them.
> >
> > That eliminates 99% of the use of auto increment and decrement,
> > as the VAX usage stats show. Anything left would be for strength
> > reduction on loop indexed array access, and Add Tiny handles that.
> >
> > So toss out auto inc/dec address modes and put in two instructions
> >
> > // pdp-11 asm has dest reg on the right
> > ADDTY #tiny,reg Add Tiny
> > SUBTY #tiny,reg Subtract Tiny
> >
> > where tiny is 1..7 and 0 means 8. Much more generally useful.
> I would rather have 0..7 meaning 1..8, since this is trivially achieved
> by always enabling an incoming carry to the address adder.
> Special-casing 0 to mean 8 seems like it would need more gates?
>
> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
<
cnt3 is 1-gate delay.
carry-in is 4-gate delays.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Re: PDP-11-like ISA

<5543b73f-9c76-4486-b183-f576d6a6848en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17622&group=comp.arch#17622

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:ac03:: with SMTP id e3mr4245378qkm.367.1623423664098;
Fri, 11 Jun 2021 08:01:04 -0700 (PDT)
X-Received: by 2002:aca:fd44:: with SMTP id b65mr14175235oii.175.1623423663908;
Fri, 11 Jun 2021 08:01:03 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Fri, 11 Jun 2021 08:01:03 -0700 (PDT)
In-Reply-To: <121bdc96-e76a-4b2f-8fec-7465378f51den@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:a87a:6554:33a2:4294;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:a87a:6554:33a2:4294
References: <548dc91d-831f-4dd7-a947-8fd7974695e3n@googlegroups.com>
<cyowI.31628$8f1.4834@fx23.iad> <dfbead57-fff5-4ddb-bb18-38105da53f64n@googlegroups.com>
<j0ywI.36041$431.5756@fx39.iad> <s9voen$do7$1@gioia.aioe.org> <121bdc96-e76a-4b2f-8fec-7465378f51den@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5543b73f-9c76-4486-b183-f576d6a6848en@googlegroups.com>
Subject: Re: PDP-11-like ISA
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Fri, 11 Jun 2021 15:01:04 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1681
 by: MitchAlsup - Fri, 11 Jun 2021 15:01 UTC

On Friday, June 11, 2021 at 9:59:36 AM UTC-5, MitchAlsup wrote:
> On Friday, June 11, 2021 at 8:28:59 AM UTC-5, Terje Mathisen wrote:
> > EricP wrote:
<
After studying the situation overnight, I agree with EricP that
auto-inc/dec deferred is not worthy of inclusion--which leads
the way to enable base+index addressing.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor