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!
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 ?
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.
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 ?
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.
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.
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.
Comments
rev A is P2 silicon
rev B1 is my idea of yesterday
rev B2 is my idea of today
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 indexProposed
// 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 indexAn index of -16..+15 will encode the same in rev B2 as rev A, if you assemble S to 1s0000000 when index=0.
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 ?
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:
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.
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.
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.