The DECOD2/3/4/5 instructions can copy the two bits above those being decoded into Z/C via WZ/WC. I've been using these for the Spin interpreter, as they provide mask functions with flag setting.
The ISOB/NOTB... instructions copy the original bit into C, with Z being affected by the long result. Maybe those flag results aren't so important, but they have some uses.
So if the SETBC, SETBNC, SETBZ, SETBNZ don't have any special uses for the WZ & WC - This would also free up 3 full instructions. SETB and CLRB would also free up an instruction. Worth keeping in mid for possible later use (I don't see any requirements for now, other than the CALL/RET/LINK instructions you were working on).
After I get this LINK stuff done, I want to add your USB pin instructions. The only matter after that (and maybe some related CRC instruction(s)) is the SERDES.
LINKTAB D,@S 'jump to location in table (PC+S+D) and write {Z,C,%00_0000_0000_0000,PC} into register $000.
LINK D/#/@ 'jump to location and write {Z,C,%00_0000_0000_0000,PC} into register $000.
They seem to all work fine, but I'll test more tomorrow and get an update out.
LINKTAB D,@S 'jump to location in table (PC+S+D) and write {Z,C,%00_0000_0000_0000,PC} into register $000.
LINK D/#/@ 'jump to location and write {Z,C,%00_0000_0000_0000,PC} into register $000.
They seem to all work fine, but I'll test more tomorrow and get an update out.
Great! Thanks for adding the LINK instruction! I know there was some doubt here about its necessity but I think it will help with PropGCC and hopefully other things as well.
Does code execution inside the cog always start at $0 (with no ability to say otherwise?)
Given that, does a new task inside that same cog also start at $0, and is it the task itself that has to remap the registers?
What I guess I'm trying to say, is, how does this all expected to work?
Can someone write a code snippet so I can understand how this address 0 thing works without causing a cog to trip over itself?
We do similat things with P1. All you need is a jump away from address zero, or just let the program start running, then init tasks and anything else no longer running code there.
On P1, locating data at 0 made things faster. Start COG, jmp to program, the first thing it does is replace the jmp at 0 with the data and everything is fine.
May I suggest the JMPLIST & JMPR (or CALLIST & CALLR) be named LINKLST & LINK.
LINK/LINKLST feels best, so I changed to those names. What about LINKTAB for 'link table', instead of LINKLST?
First, this isn't really a serious suggestion so feel free to disregard it! :-)
I suggest that we rename all of the CALLx instructions to PUSHJx and all RETx instructions to POPJx. This says more directly what they actually do, push their return address on a stack and jump. Those are also the names of instructions on one of my favorite processors, the PDP-10.
If we do that then CALL can be used for the instruction that stores its return address in COG location $000 and jumps. And RET can be a synonum for JMP $000.
Well, I had to suggest it. I know we can't be naming instructions after computers that have been obsolete for 30 years but I thought maybe there would be a chance since so many people here seem to like old computers. This isn't a Z80 though so I may not have much of a chance! :-)
Edit: An interesting parallel between the PDP-10 and the Propeller is that you could execute instructions from the registers of a PDP-10 just like you can from the COG registers in the Propeller.
I did not know that about the PDP-10. I'll go off and do some reading later this week. It is a machine often mentioned that I know little about.
Personally, I like descriptive names. Your suggestion is fine with me. I've always struggled with the core function vs descriptive names. On one hand, it jumps, and it can be in the collection of things that jump and be seen as such, because J is a starting character. So one sees it a jump, then goes to look up the details.
With the descriptive names, sometimes one goes to look up what all can perform a jump, get details, then select an instruction. A periodic table of instructions is helpful here, just as a detail listing is helpful in the other scenario.
In the end, there are enough instructions and details to warrant reference material, cards, tables, etc... either way, leaving it a preference. I like old computers, and so I like the name suggestion.
First, this isn't really a serious suggestion so feel free to disregard it! :-)
I suggest that we rename all of the CALLx instructions to PUSHJx and all RETx instructions to POPJx. This says more directly what they actually do, push their return address on a stack and jump. Those are also the names of instructions on one of my favorite processors, the PDP-10.
If we do that then CALL can be used for the instruction that stores its return address in COG location $000 and jumps. And RET can be a synonum for JMP $000.
I think you also need to keep in mind all those coming from 'other assemblers/micros'.
CALL and RET are close to universal, and even on the tiny-stack brain-dead micros, can be nested to the stacks ability
Opcodes that behave like this (can be nested) should be called CALL and RET & any student knows what happens.
Opcodes that do not use the normal stack, and cannot be nested, and/or have special rules, need less common mnemonics
I think the instruction that stores its return address in COG location $000 and jumps and instruction JMP $000 are the special case ones, and they should not be given already widely used generic names.
A paired mnemonic that reflects the limited 'stack' of the special case would make most sense.
CALLL just looks funny, and the 000 is essentially a queue, so maybe CALLQ RETQ ?
Just to check this opcode CALLQ..JMP..RETQ would be ok, but CALLQ ..CALLQ..RETQ would fail, right ?
Did Chip say each thread now has a queue-copy ? Maybe CALLT, RETT, or does RETT look too strange ? ( CALLQT, RETQT ?)
I think you also need to keep in mind all those coming from 'other assemblers/micros'.
CALL and RET are close to universal, and even on the tiny-stack brain-dead micros, can be nested to the stacks ability
Opcodes that behave like this (can be nested) should be called CALL and RET & any student knows what happens.
Opcodes that do not use the normal stack, and cannot be nested, and/or have special rules, need less common mnemonics
I think the instruction that stores its return address in COG location $000 and jumps and instruction JMP $000 are the special case ones, and they should not be given already widely used generic names.
A paired mnemonic that reflects the limited 'stack' of the special case would make most sense.
CALLL just looks funny, and the 000 is essentially a queue, so maybe CALLQ RETQ ?
Just to check this opcode CALLQ..JMP..RETQ would be ok, but CALLQ ..CALLQ..RETQ would fail, right ?
Did Chip say each thread now has a queue-copy ? Maybe CALLT, RETT, or does RETT look too strange ? ( CALLQT, RETQT ?)
I think you may have missed the first sentence in my post. :-)
I wanted to call them CALLLR and RETLR but three "L"s in a row is a bit much. Also, CALL_LR and RET_LR are kind of ugly because none of the other opcodes have underscores. I guess CALL0 and RET0 would be okay.
I got that it was not entirely serious, but it did have some valid scope, re mnemonic choices.
CALL0 RET0 is ok too, as the '0' alerts users, and anyone who types CALLO will trip an error.
Or it could be CALLZ and RETZ I suppose to avoid the zero vs "O" confusion. To be honest, Chip can call it whatever he likes. I'm just glad to have the functionality by whatever name! :-)
Interesting about the PDP-10 instruction set. I suggested LINK (and LINKRET) because it had been described as putting the return address in the LINK register.
However, LINK was used in the Friden/Singer/ICL System Ten & System 25 minis (assembler) that I worked on in the 70's+. It has analogies to the prop in that it has a common = hub code/data memory, and partition = cog memory per processor (up to 20, and hardware time-sliced). Instructions were 2 operands memory to memory, no accumulators, and 3 special memory locations were also index registers. It was common to self-modify code. An instruction could ADD A,B where A would be added to B and the result would be stored in B - this was in decimal, and could specify up to 10 digits for each of A and B. The Ten was built from 1969-1981 and the 25 from 1981-1993 and supported to end 1999. The Ten was core memory and the 25 was battery backed DRAM. I bought my own second hand System Ten in 1977 and it ran until I sold it for scrap in 2001.
Comments
Sorry, I meant ISOB...SETBNZ, or whatever constitutes that group of eight. They all treat Z and C the same.
68000 translation -- was only one of possibility's to use that instruction.
And as I can see --- all proposos I made for P2 give it strength.
And Yes TRAP was an interrupt ---- that why instruction to simulate that cases need be CALL type
Ps. --- I can always use construct that need 10 else more instructions to resolve that problem.
But as i UNDERSTAND it is bad way to go on P2
LINKTAB D,@S 'jump to location in table (PC+S+D) and write {Z,C,%00_0000_0000_0000,PC} into register $000.
LINK D/#/@ 'jump to location and write {Z,C,%00_0000_0000_0000,PC} into register $000.
They seem to all work fine, but I'll test more tomorrow and get an update out.
Does code execution inside the cog always start at $0 (with no ability to say otherwise?)
Given that, does a new task inside that same cog also start at $0, and is it the task itself that has to remap the registers?
What I guess I'm trying to say, is, how does this all expected to work?
Can someone write a code snippet so I can understand how this address 0 thing works without causing a cog to trip over itself?
On P1, locating data at 0 made things faster. Start COG, jmp to program, the first thing it does is replace the jmp at 0 with the data and everything is fine.
Personally, I like descriptive names. Your suggestion is fine with me. I've always struggled with the core function vs descriptive names. On one hand, it jumps, and it can be in the collection of things that jump and be seen as such, because J is a starting character. So one sees it a jump, then goes to look up the details.
With the descriptive names, sometimes one goes to look up what all can perform a jump, get details, then select an instruction. A periodic table of instructions is helpful here, just as a detail listing is helpful in the other scenario.
In the end, there are enough instructions and details to warrant reference material, cards, tables, etc... either way, leaving it a preference. I like old computers, and so I like the name suggestion.
I think you also need to keep in mind all those coming from 'other assemblers/micros'.
CALL and RET are close to universal, and even on the tiny-stack brain-dead micros, can be nested to the stacks ability
Opcodes that behave like this (can be nested) should be called CALL and RET & any student knows what happens.
Opcodes that do not use the normal stack, and cannot be nested, and/or have special rules, need less common mnemonics
I think the instruction that stores its return address in COG location $000 and jumps and instruction JMP $000 are the special case ones, and they should not be given already widely used generic names.
A paired mnemonic that reflects the limited 'stack' of the special case would make most sense.
CALLL just looks funny, and the 000 is essentially a queue, so maybe CALLQ RETQ ?
Just to check this opcode CALLQ..JMP..RETQ would be ok, but CALLQ ..CALLQ..RETQ would fail, right ?
Did Chip say each thread now has a queue-copy ? Maybe CALLT, RETT, or does RETT look too strange ? ( CALLQT, RETQT ?)
LINK and LINKRET are okay with me.
That disturb have Variables starting from 0
I got that it was not entirely serious, but it did have some valid scope, re mnemonic choices.
CALL0 RET0 is ok too, as the '0' alerts users, and anyone who types CALLO will trip an error.
When you go into multi-tasking with a COG, you put it in Heater mode.
.... or like sports teams, Parallax could sell "Naming Rights" to the instruction mnemonics to generate a little cash flow during R&D.
Just having some fun here.
What about LEAF,LEAFRET?
However, LINK was used in the Friden/Singer/ICL System Ten & System 25 minis (assembler) that I worked on in the 70's+. It has analogies to the prop in that it has a common = hub code/data memory, and partition = cog memory per processor (up to 20, and hardware time-sliced). Instructions were 2 operands memory to memory, no accumulators, and 3 special memory locations were also index registers. It was common to self-modify code. An instruction could ADD A,B where A would be added to B and the result would be stored in B - this was in decimal, and could specify up to 10 digits for each of A and B. The Ten was built from 1969-1981 and the 25 from 1981-1993 and supported to end 1999. The Ten was core memory and the 25 was battery backed DRAM. I bought my own second hand System Ten in 1977 and it ran until I sold it for scrap
I'd agree, they sound very conditional on the Z flag.
Valid point, I think the location it used can be fixed anywhere ?
Is there a better address location ?
I think leaf use is what started this, but this is an Assembler mnemonic which I think should at least have CALL and RET in the name somewhere.
I believe address $0 was chosen to fit in with register re-mapping / multi tasks.