If you end your interrupt code with 'JMP $1F4', you'll return to the mainline code, and on the next interrupt you will run the same code as before.
If you do a 'LINK $1F5, $1F4' in your interrupt code, you will return to the mainline code, and then on the next interrupt you will continue from right after the LINK instruction in your interrupt code.
LINK was used on the Friden/Singer/ICL System Ten manufactured from 1969-1981 and on the ICL System 25 manufactured from 1981-1993. Both mini-s were still in widespread use in 1999.
LINK was a Branch and Link instruction, virtually identical to a JMPRET instruction. The return address was written, and then a branch/jump to the destination address.
I would not be surprised if the DEC 10 and IBM 360 of the 70's used the same mnemonic. http://www.fano.co.uk/history/sys10c.html (see page 2)
It's like it writes a note and leaves it somewhere before it leaves, to later return.
That sounds somewhat similar to a plot element in the move Déjà Vu with Denzel Washington.
How about SETINT | SCHDLE | CHAIN | RELAY | HANDOFF | LINKUP | DETOUR | ERRAND?
Okay, maybe CHAIN doesn't work, but I liked the sound of it. And ERRAND sounds like a logic operation went awry, but does suggest a small task will be handled. DETOUR is kind of cool. Anyway, it's fun to think outside (and inside) the box. Love the progress! We're back! Carry on.
2. Given we care, LINK actually is quite descriptive. PLINK, seems best to me, if we are to avoid a common use symbolic use.
This instruction is the link between processes.
**I only put JMG in the mnemonic for fun, and it was just one character different. Just popped in there. Gotta get the fun where I can kind of thing. Maybe we can get an instruction called SPUD. I would totally take it.
I got all the hooks in to make the LINK injector and it didn't even change the LE count on the compile. It entailed another mux selection in the PC computation and on the instruction input, an added input term to the cog state machine, and another term on the conditional qualifier. Oh, and the interrupt signal, itself, which involves a request that gets qualified with all those conditions laid out before (no ALTDS/AUGS/AUGD/REP, etc.).
I just did a recompile with another interrupt source and it increased the LE count by 17. There's some play in there, with every compile.
Now, I just have to add the counter and the instructions, which I think should take about 80 LE's.
Now, I just have to add the counter and the instructions, which I think should take about 80 LE's.
This is a 32b buried counter, that reloads from the D register, or some snapshot copy of the D register ?
I think it will need a buffered reload, otherwise the counter has to grab the COG address bus on every reload.
That means a change in time-rate needs a new launch opcode (not a change in D, D is only used once) ?
Now, I just have to add the counter and the instructions, which I think should take about 80 LE's.
This is a 32b buried counter, that reloads from the D register, or some snapshot copy of the D register ?
I think it will need a buffered reload, otherwise the counter has to grab the COG address bus on every reload.
That means a change in time-rate needs a new launch opcode (not a change in D, D is only used once) ?
It's working! I still don't have the counter in, but I've got it set up to trigger on a pushbutton press. I can see on the logic analyzer that everything is sequencing properly in the cog's state machine and it's working fine with code running.
Yes, the D value (count) will be captured during the initializing opcode into a hidden register so that it can be used to reload the counter on each roll-under, which triggers the interrupt-request.
Two flops were needed to register the interrupt-request pulse and then synchronize it to the cog's state machine.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
How about tying the IRQ to Smartpins instead of a dedicated timer.
If those smart pins were indeed smarter than regular I/O pins, it would work, but regular I/O signals would still be coming down those INA/INB bits. I've always been really leery of using pins as interrupt sources because they are prone to all kinds of noise which could often wind up creating software problems that are hard to diagnose (and fix). I've always found that turning things around and just polling the pins is the best recipe for sanity and stability. I know that's boring. Merely providing pin interrupts, I worry, would invite people down a path of frustration. Things like counters are divorced enough from the real world that they can operate harmoniously as interrupt sources, without any drama.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
CALL always implies a return, while JMP does not, so why not some combination of call and link?
So why not LC, CL, CLINK, CALLINK, LINCALL, or LINKALL ;-)
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
I hadn't noticed those (though I don't see JMP repeated). Wouldn't this complicate the assembler implementation? Why not LLINK, LJMP, LCALL, LCALLA, LCALLB? The preceding "L" is short for "long", which is a familiar concept. I think this would also improve readability.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
CALL always implies a return, while JMP does not, so why not some combination of call and link?
So why not LC, CL, CLINK, CALLINK, LINCALL, or LINKALL ;-)
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
I hadn't noticed those (though I don't see JMP repeated). Wouldn't this complicate the assembler implementation? Why not LLINK, LJMP, LCALL, LCALLA, LCALLB? The preceding "L" is short for "long", which is a familiar concept. I think this would also improve readability.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
I hadn't noticed those (though I don't see JMP repeated). Wouldn't this complicate the assembler implementation? Why not LLINK, LJMP, LCALL, LCALLA, LCALLB? The preceding "L" is short for "long", which is a familiar concept. I think this would also improve readability.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
Fair enough. And I saw that note on LINK. Now I understand what you were saying. Thanks.
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
CALLR sounds good, although I must admit that even though the post was made with tongue firmly in cheek I do like CLINK, and even CALI and LICA, which were afterthoughts.
BTW, thanks for this addition. Even though it's not exactly what I suggested I feel somewhat vindicated for making all those pro interrupt arguments.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
Hi Chip.
I se You made nice progress on new chip architecture.
And many good decisions so I think it is not so much time before we can play with it.
I thought about this a lot, and like Chip and others I am sure, really struggled with how useful a cog with tasking is, compared to one lacking that capability.
This timer really does a lot to close that gap without getting hot and or adding a lot of complexity, while at the same time preserving the robust nature of how a Propeller works with the outside world.
I personally would trade this in a second for the tasking though. So it's a good use case given this design and process limits, but not really something to expand, IMHO.
The new "waitforpin"-instructions have a optional timeout, right?I would like that. But what/where is Q ??
e.g. "WAITPAE D/#,S/# (00, waits for INA, WC=1 for timeout using Q)"
The new "waitforpin"-instructions have a optional timeout, right?I would like that. But what/where is Q ??
e.g. "WAITPAE D/#,S/# (00, waits for INA, WC=1 for timeout using Q)"
Maybe SETQ? There was some indication that this was used for more than CORDIC.
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
Yes, CALLR is ok, - the objective here is to have the primary outcome clear to a casual ASM source reader.Users coming from other modern assemblers and MCUs need to follow as easily as possible.
Wouldn't this complicate the assembler implementation?
It does not matter if the assembler has to do some housekeeping, that is what computers are for!Other assemblers have a generic CALL, that they choose opcode for.I find ASM Readability is better with fewer opcodes.
How about tying the IRQ to Smartpins instead of a dedicated timer.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
The new "waitforpin"-instructions have a optional timeout, right?I would like that. But what/where is Q ??
e.g. "WAITPAE D/#,S/# (00, waits for INA, WC=1 for timeout using Q)"
Maybe SETQ? There was some indication that this was used for more than CORDIC.
Yes, SETQ can be used before WAITPxx to establish a timeout marker.
Comments
If you do a 'LINK $1F5, $1F4' in your interrupt code, you will return to the mainline code, and then on the next interrupt you will continue from right after the LINK instruction in your interrupt code.
Lots of arrangements are possible.
Hit the go button before the brain hurts any more
LINK was a Branch and Link instruction, virtually identical to a JMPRET instruction. The return address was written, and then a branch/jump to the destination address.
I would not be surprised if the DEC 10 and IBM 360 of the 70's used the same mnemonic.
http://www.fano.co.uk/history/sys10c.html (see page 2)
That sounds somewhat similar to a plot element in the move Déjà Vu with Denzel Washington.
How about SETINT | SCHDLE | CHAIN | RELAY | HANDOFF | LINKUP | DETOUR | ERRAND?
Okay, maybe CHAIN doesn't work, but I liked the sound of it. And ERRAND sounds like a logic operation went awry, but does suggest a small task will be handled. DETOUR is kind of cool. Anyway, it's fun to think outside (and inside) the box. Love the progress! We're back! Carry on.
1. It's just a name. Who cares really?
2. Given we care, LINK actually is quite descriptive. PLINK, seems best to me, if we are to avoid a common use symbolic use.
This instruction is the link between processes.
**I only put JMG in the mnemonic for fun, and it was just one character different. Just popped in there. Gotta get the fun where I can kind of thing. Maybe we can get an instruction called SPUD. I would totally take it.
I just did a recompile with another interrupt source and it increased the LE count by 17. There's some play in there, with every compile.
Now, I just have to add the counter and the instructions, which I think should take about 80 LE's.
Now, I just have to add the counter and the instructions, which I think should take about 80 LE's.
This is a 32b buried counter, that reloads from the D register, or some snapshot copy of the D register ?
I think it will need a buffered reload, otherwise the counter has to grab the COG address bus on every reload.
That means a change in time-rate needs a new launch opcode (not a change in D, D is only used once) ?
Now, I just have to add the counter and the instructions, which I think should take about 80 LE's.
This is a 32b buried counter, that reloads from the D register, or some snapshot copy of the D register ?
I think it will need a buffered reload, otherwise the counter has to grab the COG address bus on every reload.
That means a change in time-rate needs a new launch opcode (not a change in D, D is only used once) ?
It's working! I still don't have the counter in, but I've got it set up to trigger on a pushbutton press. I can see on the logic analyzer that everything is sequencing properly in the cog's state machine and it's working fine with code running.
Yes, the D value (count) will be captured during the initializing opcode into a hidden register so that it can be used to reload the counter on each roll-under, which triggers the interrupt-request.
Two flops were needed to register the interrupt-request pulse and then synchronize it to the cog's state machine.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
It's working!
A hackers favourite two words!
It's working!
A hackers favourite two words!
+1
If those smart pins were indeed smarter than regular I/O pins, it would work, but regular I/O signals would still be coming down those INA/INB bits. I've always been really leery of using pins as interrupt sources because they are prone to all kinds of noise which could often wind up creating software problems that are hard to diagnose (and fix). I've always found that turning things around and just polling the pins is the best recipe for sanity and stability. I know that's boring. Merely providing pin interrupts, I worry, would invite people down a path of frustration. Things like counters are divorced enough from the real world that they can operate harmoniously as interrupt sources, without any drama.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
CALL always implies a return, while JMP does not, so why not some combination of call and link?
So why not LC, CL, CLINK, CALLINK, LINCALL, or LINKALL ;-)
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
I hadn't noticed those (though I don't see JMP repeated). Wouldn't this complicate the assembler implementation? Why not LLINK, LJMP, LCALL, LCALLA, LCALLB? The preceding "L" is short for "long", which is a familiar concept. I think this would also improve readability.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
CALL always implies a return, while JMP does not, so why not some combination of call and link?
So why not LC, CL, CLINK, CALLINK, LINCALL, or LINKALL ;-)
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
I hadn't noticed those (though I don't see JMP repeated). Wouldn't this complicate the assembler implementation? Why not LLINK, LJMP, LCALL, LCALLA, LCALLB? The preceding "L" is short for "long", which is a familiar concept. I think this would also improve readability.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
I try to avoid giving instructions names that the programmer might want to use symbolically. I agree that LINK is very generic and would cause reserved-word troubles. If we rename it to TLINK or something, the problem is solved.
Given I can find Branch-link (BL) usage & also jump and link = jal, as existing industry usage, it would seem least confusing to follow those leads ?
The Prop already uses jump terminology over Branch, so that points to JMPLINK or maybe JMPL
It is like a JMP, but it leaves the return address in a register. Seems to me that leaving the return address happens before the JMP, in the mind of the programmer, since it can't go back and do anything after the flying leap. It's like it writes a note and leaves it somewhere before it leaves, to later return. A single word that isn't CALL or JMP seems needed. LINK serves that role, in that it's unique. It took me a while to get used to, though. There could be something better, I suppose. I hear what you are saying, anyway. JMPLINK sounds like you are jumping to some link, not that you are linking your jump. LINKJMP would be more accurate, to me.
At the very least, could you disambiguate the two LINK instructions with different mnemonics? Since the second one in the list appears to work with HUBEXC mode, maybe LINKH or something like that?
The assembler looks at the operands and decides which opcode to use. This is so for LINK, JMP, CALL, CALLA, and CALLB.
I hadn't noticed those (though I don't see JMP repeated). Wouldn't this complicate the assembler implementation? Why not LLINK, LJMP, LCALL, LCALLA, LCALLB? The preceding "L" is short for "long", which is a familiar concept. I think this would also improve readability.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
Fair enough. And I saw that note on LINK. Now I understand what you were saying. Thanks.
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
CALLR sounds good, although I must admit that even though the post was made with tongue firmly in cheek I do like CLINK, and even CALI and LICA, which were afterthoughts.
BTW, thanks for this addition. Even though it's not exactly what I suggested I feel somewhat vindicated for making all those pro interrupt arguments.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
Hi Chip.
I se You made nice progress on new chip architecture.
And many good decisions so I think it is not so much time before we can play with it.
Yeah, for sure.
I thought about this a lot, and like Chip and others I am sure, really struggled with how useful a cog with tasking is, compared to one lacking that capability.
This timer really does a lot to close that gap without getting hot and or adding a lot of complexity, while at the same time preserving the robust nature of how a Propeller works with the outside world.
I personally would trade this in a second for the tasking though. So it's a good use case given this design and process limits, but not really something to expand, IMHO.
e.g. "WAITPAE D/#,S/# (00, waits for INA, WC=1 for timeout using Q)"
e.g. "WAITPAE D/#,S/# (00, waits for INA, WC=1 for timeout using Q)"
Maybe SETQ? There was some indication that this was used for more than CORDIC.
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
Yes, CALLR is ok, - the objective here is to have the primary outcome clear to a casual ASM source reader.Users coming from other modern assemblers and MCUs need to follow as easily as possible.
It does not matter if the assembler has to do some housekeeping, that is what computers are for!Other assemblers have a generic CALL, that they choose opcode for.I find ASM Readability is better with fewer opcodes.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
e.g. "WAITPAE D/#,S/# (00, waits for INA, WC=1 for timeout using Q)"
Maybe SETQ? There was some indication that this was used for more than CORDIC.
Yes, SETQ can be used before WAITPxx to establish a timeout marker.