In this mode, you also have two output choices: old data or don't care.
In Old Data Mode, a read-during-write operation to different ports causes the RAM outputs to reflect the old data at that address location.
I suppose the explanation for this is timing stays the same when treating the RAM as a buffer. "Old" data would work fine. I'm guess Chip can easily edit this setting.
So, to get "new" data passing through would require explicit logic outside the RAM block.
I'm guessing OnSemi arrangement is likely very similar except maybe "old" could be default setting there.
I was wondering about the SETQ+RDLONG combo...
Will that work inside REP?
Yep, there's no restriction on time, excepting IRQs disabled, or data memory ranges. The one big restriction is all branching is a loop cancel. Including another REP. Issuing a second REP while still within the first, from the hardware's view, is just restarting the REP operation at the new REP instruction. The old REP instruction is forgotten.
It's like comparing GOTO vs GOSUB. REPs are all GOTO type branching.
I think even a branch over one instruction within the REP loop will cancel the REP operation, ie: It'll fall out the bottom as if the loop count had completed. This is where having conditional execution is another bonus.
I was able to replicate weirdness in my code using a JATN instruction.
It terminates the REP block then restarts the REP block again.
I replaced it with a POLLATN WC and a IF_C JMP #somewhere and it worked.
Looks like there is something about the Jxxx instructions inside REP blocks that breaks things.
This is a separate issue to the last instruction being a branch that was mentioned earlier.
All of the 9-bit-immediate-address jump instructions are relative. I think they may be jumping relative to the REP loop address, because the REP affected the program counter in the prior instruction cycle, already. If this is the trouble, you just can't use a relative branch at the very end of a REP block. I don't think there is anything that can be done about this.
All of the 9-bit-immediate-address jump instructions are relative. I think they may be jumping relative to the REP loop address, because the REP affected the program counter in the prior instruction cycle, already. If this is the trouble, you just can't use a relative branch at the very end of a REP block. I don't think there is anything that can be done about this.
That would fit the symptoms, and means the reljmp is not actually finally jumping at all, but simply falls thru the packer NOPs (a delay test would verify that).
If a double-change is occurring, and is stable, you could still use a reljmp at the very end, it just needs a fix-up of the rel value.
For immediate rep loops, the assembler could catch this, but for var based REPs (far less common) it may just have to issue a warning, but here it would be nice to know where the rep boundary is.
Such VAR reach reps would be rare, but a specific repend local label could give a bound to the assembler, as well as help clarity and editing.
In this case, if Asm sees VAR reach REP and reljmps inside that longest-indicated bound, it needs to issue the 'do this only if you really know what you are doing' warning.
For CONST REP loops, the ASM can manage the reljmps.
JMG,
The lock-up on branch at last instruction issue is the one that is PC-relative encoding sensitive. There is no fall-through in this case. And it happens every execution.
Two distinct behaviours.
The fall-through issue is all about the Jxxx branch on event instructions exclusively. And can be triggered from any position in the REP block, but only has a probability of triggering. It makes no diff about rel vs abs. I've even tested using register absolute.
The workaround for the lock-up flaw is move the branch off the end of the block.
The workaround for the fall-through flaw is don't use event branching inside a REP block at all.
JMG,
The lock-up on branch at last instruction issue is the one that is PC-relative encoding sensitive. There is no fall-through in this case. And it happens every execution.
Two distinct behaviours.
The fall-through issue is all about the Jxxx branch on event instructions exclusively. And can be triggered from any position in the REP block, but only has a probability of triggering. It makes no diff about rel vs abs. I've even tested using register absolute.
Yes, Chip's post, and my reply, were solely focused on the last-instruction case. As ozpropdev mentions, that's separate from erratic Jxx issue.
You said NOP packers were needed, and I explained why that fits with Chip's summary. ie The PC is modified twice, but in a predictable manner, and there is an Assembler solution possible.
There is no fall-through with that issue. It simply locks solid.
Oops, is was ozpropdev that said NOPs were needed, not you, I confused posters.
His code shows the effect, and that NOP 'fix' matches Chip's note about early loading of PC, so it actually loads PC twice - once to get ready to go back, and again by reljmp, only now the reljmp is applied from REP opcode addr not the end.
NOP's fix that by moving the 2nd change to span the REP loop. Code works, but with an added delay, as it falls thru the block of NOPs.
My point is that the assembler can do the pre-fix, (for CONST rep size), so the NOPs are not needed.
Hmm, I'm getting a different outcome there Brian. I can throw lots of NOPs at it, but it never gets to the debug code after that. The REP loop stops cycling and nothing else appears to happen.
One difference I can see is I'm relative branching back to before the REP instruction.
Hmm, I'm getting a different outcome there Brian. I can throw lots of NOPs at it, but it never gets to the debug code after that. The REP loop stops cycling and nothing else appears to happen.
One difference I can see is I'm relative branching back to before the REP instruction.
If going back the, NOPs would need to be before the destination ?
( as the PC first sets to REP start, then it reljmp modifies next, but the ASM uses the reljmp address as the base)
If going back the, NOPs would need to be before the destination ?
( as the PC first sets to REP start, then it reljmp modifies next, but the ASM uses the reljmp address as the base)
Damn, I think you're right. I filled before the destination with NOPs and it's working.
What I hadn't thought about is my code, without the NOPs, is reusing that space for variables after initial execution.
Comments
It would have been single ported if that road was taken.
Will that work inside REP?
I vaguely remember some conditions on REP... I'm pretty sure you can't have nested REPs... There was something else though...
I suppose the explanation for this is timing stays the same when treating the RAM as a buffer. "Old" data would work fine. I'm guess Chip can easily edit this setting.
So, to get "new" data passing through would require explicit logic outside the RAM block.
I'm guessing OnSemi arrangement is likely very similar except maybe "old" could be default setting there.
It's like comparing GOTO vs GOSUB. REPs are all GOTO type branching.
I think even a branch over one instruction within the REP loop will cancel the REP operation, ie: It'll fall out the bottom as if the loop count had completed. This is where having conditional execution is another bonus.
I was able to replicate weirdness in my code using a JATN instruction.
It terminates the REP block then restarts the REP block again.
I replaced it with a POLLATN WC and a IF_C JMP #somewhere and it worked.
Looks like there is something about the Jxxx instructions inside REP blocks that breaks things.
This is a separate issue to the last instruction being a branch that was mentioned earlier.
Sounds right. Thanks for the checking.
All of the 9-bit-immediate-address jump instructions are relative. I think they may be jumping relative to the REP loop address, because the REP affected the program counter in the prior instruction cycle, already. If this is the trouble, you just can't use a relative branch at the very end of a REP block. I don't think there is anything that can be done about this.
To clarify, was that tested on a P2 ?
Does it fail always, or at some lower failure rate like evanh mentioned ?
That particular issue is not an end-of-block problem. It can intermittently happen with the Jxxx instruction at any position in the block.
The end-of-block issue is separate one.
That would fit the symptoms, and means the reljmp is not actually finally jumping at all, but simply falls thru the packer NOPs (a delay test would verify that).
If a double-change is occurring, and is stable, you could still use a reljmp at the very end, it just needs a fix-up of the rel value.
For immediate rep loops, the assembler could catch this, but for var based REPs (far less common) it may just have to issue a warning, but here it would be nice to know where the rep boundary is.
Such VAR reach reps would be rare, but a specific repend local label could give a bound to the assembler, as well as help clarity and editing.
In this case, if Asm sees VAR reach REP and reljmps inside that longest-indicated bound, it needs to issue the 'do this only if you really know what you are doing' warning.
For CONST REP loops, the ASM can manage the reljmps.
The lock-up on branch at last instruction issue is the one that is PC-relative encoding sensitive. There is no fall-through in this case. And it happens every execution.
Two distinct behaviours.
The fall-through issue is all about the Jxxx branch on event instructions exclusively. And can be triggered from any position in the REP block, but only has a probability of triggering. It makes no diff about rel vs abs. I've even tested using register absolute.
The workaround for the lock-up flaw is move the branch off the end of the block.
The workaround for the fall-through flaw is don't use event branching inside a REP block at all.
Yes, Chip's post, and my reply, were solely focused on the last-instruction case. As ozpropdev mentions, that's separate from erratic Jxx issue.
You said NOP packers were needed, and I explained why that fits with Chip's summary. ie The PC is modified twice, but in a predictable manner, and there is an Assembler solution possible.
Oops, is was ozpropdev that said NOPs were needed, not you, I confused posters.
His code shows the effect, and that NOP 'fix' matches Chip's note about early loading of PC, so it actually loads PC twice - once to get ready to go back, and again by reljmp, only now the reljmp is applied from REP opcode addr not the end.
NOP's fix that by moving the 2nd change to span the REP loop. Code works, but with an added delay, as it falls thru the block of NOPs.
My point is that the assembler can do the pre-fix, (for CONST rep size), so the NOPs are not needed.
Did you read ozpropdev's post and comment ? Here :
With the NOP's REP loop works as expected.
Without the NOP's, an extra loop is executed.
All of which is explained by the PC loading twice.
http://forums.parallax.com/discussion/comment/1458296/#Comment_1458296
One difference I can see is I'm relative branching back to before the REP instruction.
The REP is a special case and works nicely. I can live with restrictions.
Maybe reverse relatve branching only works in the northern hemisphere.
If going back the, NOPs would need to be before the destination ?
( as the PC first sets to REP start, then it reljmp modifies next, but the ASM uses the reljmp address as the base)
Damn, I think you're right. I filled before the destination with NOPs and it's working.
What I hadn't thought about is my code, without the NOPs, is reusing that space for variables after initial execution.
Found another one! A little comical too. Smartpin "long repository" modes only seem to work when DIR is forced on with TT=%01.
I will look into that.
EDIT: Using a smartpin for this came about only because I didn't want to disable the total hubRAM filling happening from another cog.