Welcome to the Parallax Discussion Forums, sign-up to participate.

• Posts: 1,284
Chip, below is a table of #s and the resulting index values. PTRx not relevant and omitted.

rev A is P2 silicon
rev B1 is my idea of yesterday
rev B2 is my idea of today
```876543210
#s		   index for rev
1supiiiii	 A	 B1	 B2

1x0000000	 0	 0	 0	assemble to this if index=0
1x0000001	+1	+1	+1
1x0001111	+15	+15	+15
1x0010000	-16	+16 !	-16
1x0011111	-1	+31 !	-1

1x0100000	n/a	-32	+16
1x0100001	n/a	-31	+17
1x0101111	n/a	-17	+31
1x0110000	n/a	-16	-32
1x0111111	n/a	-1	-17

1x1000000	 0	+16 !	+16 !
1x1000001	+1	+1	+1
1x1001111	+15	+15	+15
1x1010000	-16	-16	-16
1x1011111	-1	-1	-1

1x1100000	 0	+16 !	+16 !
1x1100001	+1	+1	+1
1x1101111	+15	+15	+15
1x1110000	-16	-16	-16
1x1111111	-1	-1	-1

! indicates B1 or B2 not same as A
```

I've even had a go at the Verilog change:

Existing
```// rev B1
wire [5:0] ptr_nx	= ix[s6] ? {ix[s4], ix[s4] || ~|ix[s3:s0], ix[s3:s0]}	// ptra/ptrb-update with -16..+16 scaled index
: ix[s5:s0];					// ptra/ptrb-static with -32..+31 scaled index
```

Proposed
```// rev B2
wire [5:0] ptr_nx	= ix[s6] ? {ix[s4], ix[s4] || ~|ix[s3:s0], ix[s3:s0]}	// ptra/ptrb-update with -16..+16 scaled index
: {ix[s4], ix[s5]^ix[s4], ix[s3:s0]};		// ptra/ptrb-static with -32..+31 scaled index
```

An index of -16..+15 will encode the same in rev B2 as rev A, if you assemble S to 1s0000000 when index=0.
Formerly known as TonyB
• Posts: 1,284
Bumping this in case it was overlooked.
Formerly known as TonyB
• Posts: 3,383
Maintaining binary compatibility between the fpga/test silicon and final silicon is a great idea. Thanks for this suggestion, @TonyB_. I hope @cgracey can implement it this way!
• Posts: 11,703
After I rest, I'll get into that. Too tired now.
• Posts: 13,903
ersmith wrote: »
Maintaining binary compatibility between the fpga/test silicon and final silicon is a great idea. Thanks for this suggestion, @TonyB_. I hope @cgracey can implement it this way!

Yes, certainly worth keeping. I was unclear if that table was binary compatible ( at least in all present use cases), or if it just improved the compatibility % ?
ie +16 appears more than once in the B2 column & 0 appears more than once in Rev A column ?
• Posts: 1,284
edited 2019-01-11 - 21:44:29
There are two changes proposed from rev A:

1. Use spare #s bit to extend Index range to -32..+31 when PTRx is not updated
2. Replace two superfluous PTRx+0 update instructions with PTRx+16

Here is a table that includes PTRx:
```#s          Expression      Address used         PTRx after instr       Index

1x0iiiiii   PTRx[Index]     PTRx + Index*Scale   PTRx                   -32..+31
1x11iiiii   PTRx++[Index]   PTRx                 PTRx ++= Index*Scale   -16..-1,+1..+16
1x10iiiii   ++PTRx[Index]   PTRx + Index*Scale   PTRx ++= Index*Scale   -16..-1,+1..+16
```

Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided with B2.
Formerly known as TonyB
• Posts: 13,903
TonyB_ wrote: »
Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided.

That was what I hoped, does that mean the table case where A != B2, never occur in actual code use ?
• Posts: 1,284
jmg wrote: »
TonyB_ wrote: »
Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided.

That was what I hoped, does that mean the table case where A != B2, never occur in actual code use ?

Yes, provided that (a) index=0 is always assembled to #s=1x0000000 and (b) people can control themselves and not use an index outside -16..+15 with rev A, or there is an assembler switch.

1x01xxxxx is not a valid #s value for rev A. I don't know what would happen if it is created "by hand" and the same question could apply to invalid opcodes for other instructions, I imagine.
Formerly known as TonyB
• Posts: 1,284
TonyB_ wrote: »
There are two changes proposed from rev A:

1. Use spare #s bit to extend Index range to -32..+31 when PTRx is not updated
2. Replace two superfluous PTRx+0 update instructions with PTRx+16

Here is a table that includes PTRx:
```#s          Expression      Address used         PTRx after instr       Index

1x0iiiiii   PTRx[Index]     PTRx + Index*Scale   PTRx                   -32..+31
1x11iiiii   PTRx++[Index]   PTRx                 PTRx ++= Index*Scale   -16..-1,+1..+16
1x10iiiii   ++PTRx[Index]   PTRx + Index*Scale   PTRx ++= Index*Scale   -16..-1,+1..+16
```

Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided with B2.

I have a feeling this change was not implemented before all the analogue innovations. If so, Chip could you please look at this again sometime? Perhaps when sorting out the bugs and other outstanding issues. Here's the link to my original post:
http://forums.parallax.com/discussion/comment/1453877/#Comment_1453877

The only downside is that it would be a little bit harder to patch instructions to change the index, if that is ever needed. The much bigger upside is that rev A and rev B could use the same toolset.
Formerly known as TonyB
• Posts: 11,703
TonyB_ wrote: »
TonyB_ wrote: »
There are two changes proposed from rev A:

1. Use spare #s bit to extend Index range to -32..+31 when PTRx is not updated
2. Replace two superfluous PTRx+0 update instructions with PTRx+16

Here is a table that includes PTRx:
```#s          Expression      Address used         PTRx after instr       Index

1x0iiiiii   PTRx[Index]     PTRx + Index*Scale   PTRx                   -32..+31
1x11iiiii   PTRx++[Index]   PTRx                 PTRx ++= Index*Scale   -16..-1,+1..+16
1x10iiiii   ++PTRx[Index]   PTRx + Index*Scale   PTRx ++= Index*Scale   -16..-1,+1..+16
```

Rev B1 and B2 in the top post on this page have the same functionality but only B2 is binary-compatible with rev A, therefore two sets of tools can be avoided with B2.

I have a feeling this change was not implemented before all the analogue innovations. If so, Chip could you please look at this again sometime? Perhaps when sorting out the bugs and other outstanding issues. Here's the link to my original post:
http://forums.parallax.com/discussion/comment/1453877/#Comment_1453877

The only downside is that it would be a little bit harder to patch instructions to change the index, if that is ever needed. The much bigger upside is that rev A and rev B could use the same toolset.

I did implement the +16, but not in a way that is completely binary compatible. I may need to go back and do it a little bit differently.