Won't that happen when the message to activate / deactivate the modes is used?
Yes. The SysCLK is already routed to all the pins, for sampling work, so that clock-bus power is fixed,
A Binary counter, Qn side, only draws as much power as two FF's toggling at fSys/.2
The Clock tree to the counter register chain will draw some power, but it is very local and short.
Likely that part will be Gated by the Activate command.
Die-area is likely to be a larger issue, than power when looking at IO pin cells.
(that and also meeting the 200MHz target)
Phil,
My first thought was: Isn't "cmps D, S wc, wr" the same as "subs D, S" ? However it looks like the C flag is handle a little differently for CMPS verses SUBS.
I'm not sure if Chip did the change to drop the WR/NR bit from instructions or not, but I could see how they might be useful in some rare cases.
There was some talk about repurposing the wr flag, since "it wasn't very useful." So I went through all my code to see how I had used wr and nr. Here's what I found:
(Not shown are the instances where I could have used another instruction without the modifier.)
Although I didn't use the modifiers very often, they were definitely useful when I needed them.
-Phil
The SHL (SHR,ROL,ROR) with NR can now all be replaced by ISOB so we have a solution here.
I have used CMPSUB NR myself. Need to think about this one !!!
CMPS WR is an interesting one. Need to think about this one !!!
OR NR,WZ is a nice dual test for zero! Replace with 2x TEST instructions
ADD x,#1 WZ,NR could be replaced with CMP x,allones WZ (allones long $FFFFFFFF - uses a register)
CMPS x,y NR is just a CMPS x,y. No issue here.
Phil,
My first thought was: Isn't "cmps D, S wc, wr" the same as "subs D, S" ? However it looks like the C flag is handle a little differently for CMPS verses SUBS.
I'm not sure if Chip did the change to drop the WR/NR bit from instructions or not, but I could see how they might be useful in some rare cases.
Sorry, I haven't been in this forum for a few days so this 40-freaking-page thread just popped up and I only had time to skim it, not read everything. If these are stupid questions that have already been answered, please forgive me.
I really like the idea of going back to basics with the P1+ (or whatever this thing will be called), I thought the feature creep has been completely going out of hand since last year's failed shuttle run.
Some things I haven't seen answered yet:
1. So TV-out is gone, but if it will run at 200MHz and 100MIPS and it has D/A converters, shouldn't it be possible to generate CVBS from RGB data on the fly? Or at least convert RGB to YUV on the fly and use some external circuitry?
2. If the instruction set is going to be source-compatible with the P1 but not binary-compatible, won't that break pretty much all self-modifying code? I bet there's a lot of that around, and it won't be possible to simply convert it automatically, it will have to be rewritten.
I have been thinking about INDA/INDB and in particular to using them as pointers to a cog stack.
The reason that a CALLINDA cannot be used is that in the second clock, the return address is written. It would also require INDA to be incremented and written.
* Perhaps the CALLINDA could take 4 clocks, and the instruction itself perform the INC INDA in clocks 3 & 4.
* Perhaps we could modify the fixed address $1EF CALL instruction to use INDA as a pointer to where the return address would be stored. For the fixed use case (GCC etc), the program would need to set INDA to $1EF (or wherever) at initialisation.
With this change, we could use INDA as the pointer to a stack. INC and DEC of INDA would need to be performed by the subroutine like this...
CALL SUB1 'uses [INDA] to store the return address.
...
SUB1 ADD INDA,#1
...
SUB INDA,#1
RET 'uses [INDA] for the return address
To PUSH and POP we would also have to use a group of instructions...
ALTD INDA
MOV 0,<value>
ADD INDA,#1
and
SUB INDA,#1
ALTS INDA
MOV <get>,0
While not ideal, it is a solution, and is faster than using hub. It only requires a minor change to the existing fixed CALL instruction, and gives the side effect of being able to set the fixed address anywhere in the cog when used as the fixed call.
Given the nice DAC output, composite / component video will be possible in software at good signal quality.
Not sure yet how color space conversions will get done. Maybe they just won't and we can use lookups and simple formulas to make it more simple.
The hardware color space engine in the other design is too much of a beast for this process. IMHO, going VGA only makes sense. That really means software drivers like we did on P1, and we have a nice selection of those to port, and we get much better signal quality and color depth.
We can look forward to the beast in the smaller process someday.
I suppose a color lookup COG could get a lot of the functionality done. Or not, depending on what people need. With mor cogs in the mix, having one to do that might not be a worry. Color redirection was expensive on P1, unless it was two or 4 color. On this chip, it looks like we won't get any in hardware, but we get a lot more COGS!
If desired, we still get the very high color depths though, and resolutions somewhere around XGA. Lower bit depths should still get us HDTV. Component isn't a huge challenge compared to VGA, but we will have to manage the DAC output for sync levels ourselves. Not sure what Chip has planned there.
Video: I am really going to miss being able to do composite color. I like the cheap Car Reversing Monitors <$25 as they make nice screens.
When the dust settles, maybe Chip might add it into one of the cogs on the quiet???
Yeah, code will require rewrites, depending. This was going to be true no matter what. Code compatability was ruled out as a feature years ago. Waitvid changes, counters changes, pins get little brains right on them, the ROM changes and it's gonna be located at the beginning of RAM, taking up $e00 to $f00 or so. SPIN changes, we should see inline PASM, bigger programs, etc...
But we get speed, lots of COGS, a huge HUB RAM space, smart pins, ability for a COG to run a PASM program out of the HUB memory directly, etc...
That all means better, faster C performance and more library code makes sense, and it won't have to be LMM, so a lot of things just get a little nicer, easier, more roomy.
@Cluso: Composite color will happen anyway. I use it all the time myself. If Chip can put it in, great! If not, we have good P1 code for doing it manually. Eric Ball was nice enough to entertain a couple of projects and got us there in a couple of useful ways.
Should perform comparably to what the other design did, minus the nice color space hardware. I'm starting on it the moment we get an FPGA. TV is just too useful not to.
If you were to remove the increment/decrement functionality of INDx, then I'm guessing the use of INDx would be reduced to a MUX (with S/D) for the load. It would still require additional instructions to manipulate INDx, but that's not the critical function of those registers. Would that resolve the critical path timing issue?
INDA/INDB had pre- and post- increment and decrement. We could achieve something similar by extending the ALTD/ALTS instructions:
ALTDS D/#,S/# - set next D and S fields to D/# and S/#, respectively
ALTD D/# - set next D field to D/#
ALTS D/# - set next S field to D/#
ALTD_PI D - Set next D field to D+1, increment D (pre-inc)
ALTD_IP D - Set next D field to D, increment D (inc-post)
ALTD_PD D - Set next D field to D-1, decrement D (pre-inc)
ALTD_DP D - Set next D field to D, decrement D (inc-post)
ALTS_PI D - Set next S field to D+1, increment D (pre-inc)
ALTS_IP D - Set next S field to D, increment D (inc-post)
ALTS_PD D - Set next S field to D-1, decrement D (pre-inc)
ALTS_DP D - Set next S field to D, decrement D (inc-post)
Wait! We could do even better by treating one D register as two separate 9-bit fields which get pre/post-inc/dec treatment based on some S/# pattern:
ALTDS2 D,S/# - Set next D and S fields to some pre/post-inc/dec combination of D[17:9] and D[8:0]
That way, one register can be two pointers, with separate controls. Ultimately, a two-instruction combo could, for example, be coded as:
MOV [ptr1++],
The D register fields could be modified, or not. This could make cog-RAM stacks easy to implement.
I have been thinking about INDA/INDB and in particular to using them as pointers to a cog stack.
Maybe I'm missing something, but I would think that ALTD/ALTS would support the increment/decrement capability we know from INDx. If so, then PUSH would be:
MOV [SP++], reg
or
ALTD SP++
MOV 0, reg
and POP would be:
MOV reg,
or
ALTS --SP
MOV reg, 0
(note: I used "SP" instead of "INDA" to avoid confusion with the registers that were formerly at $1FE/$1FF, and no longer exist with this scheme.)
Chip answered before I hit the submit button... he's covered it.
I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:
ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode
S/# = %ddd_sss
ddd = 000: don't alter D field of next instruction
ddd = 001: alter D field of next instruction by substituting current D[17:9]
ddd = 010: <some mode we could define>
ddd = 011: <some mode we could define>
ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]
sss = 000: don't alter S field of next instruction
sss = 001: alter S field of next instruction by substituting current D[8:0]
sss = 010: <some mode we could define>
sss = 011: <some mode we could define>
sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]
Usage could be made simple by the assembler:
MOVS ptr,#from
MOVD ptr,#to
REP #count,#2
MOV [ptr++],[ptr++] 'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:
One core instruction, with control variants should certainly be ok and .cleaner assembler support is also a good idea.
Did you mean to have two separate pointers here ?
MOVS ptrF,#from
MOVD ptrT,#to
REP #count,#2
MOV [ptrT++],[ptrF++] 'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
This also underlines the need for cleaner assembler version of REP (seems that is still in this ?), as the two count is not clear in the MOV, but is handled easily by the Assembler in this
MOVS ptrF,#from
MOVD ptrT,#to
REP #count,#_LoopS,_LoopE ' Loop between _LoopS,_LoopE count times, Self adjusts and also checks for needed delays if any.
:_LoopS
MOV [ptrT++],[ptrF++] ' actually two instructions: ALTDS and MOV
.. other code
:_LoopE
One core instruction, with control variants should certainly be ok and .cleaner assembler support is also a good idea.
Did you mean to have two separate pointers here ?
MOVS ptrF,#from
MOVD ptrT,#to
REP #count,#2
MOV [ptrT++],[ptrF++] 'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
This also underlines the need for cleaner assembler version of REP (seems that is still in this ?), as the two count is not clear in the MOV, but is handled easily by the Assembler in this
MOVS ptrF,#from
MOVD ptrT,#to
REP #count,#_LoopS,_LoopE ' Loop between _LoopS,_LoopE count times, Self adjusts and also checks for needed delays if any.
:_LoopS
MOV [ptrT++],[ptrF++] ' actually two instructions: ALTDS and MOV
.. other code
:_LoopE
I don't know what to do about the pointer names. They are just different 9-bit fields within the same register.
You're right about REPS needing some automation on the code size.
I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:
ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode
S/# = %ddd_sss
ddd = 000: don't alter D field of next instruction
ddd = 001: alter D field of next instruction by substituting current D[17:9]
ddd = 010: <some mode we could define>
ddd = 011: <some mode we could define>
ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]
sss = 000: don't alter S field of next instruction
sss = 001: alter S field of next instruction by substituting current D[8:0]
sss = 010: <some mode we could define>
sss = 011: <some mode we could define>
sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]
Usage could be made simple by the assembler:
MOVS ptr,#from
MOVD ptr,#to
REP #count,#2
MOV [ptr++],[ptr++] 'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
Nice Chip!
A cool variant of "TARG".
Maybe one of the undefined modes could be used as a "NR" substitute. (Dummy write)
Brian
I need to read a bunch of preceding posts to know what has been floated, but I think we only need ONE instruction to handle the whole indirect mechanism:
ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode
S/# = %ddd_sss
ddd = 000: don't alter D field of next instruction
ddd = 001: alter D field of next instruction by substituting current D[17:9]
ddd = 010: <some mode we could define>
ddd = 011: <some mode we could define>
ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]
sss = 000: don't alter S field of next instruction
sss = 001: alter S field of next instruction by substituting current D[8:0]
sss = 010: <some mode we could define>
sss = 011: <some mode we could define>
sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]
Usage could be made simple by the assembler:
MOVS ptr,#from
MOVD ptr,#to
REP #count,#2
MOV [ptr++],[ptr++] 'move using pointers in ptr, this is actually two instructions: ALTDS and MOV
That is smart Chip! As the instruction ALTDS can only write to D, combining the 2 pointers by using the D & S positions is great
I have wondered if an AUGDS #d,#s might be useful ?
One instruction can add the upper 9 bits (#D & #S) to both D & S of the next instruction (makes 18 bits total - we only need 17 for now, but nice to reserve 18 bits for sw compatibility if you make a 1MB hub version later.
Nice Chip!
A cool variant of "TARG".
Maybe one of the undefined modes could be used as a "NR" substitute. (Dummy write)
Brian
Great idea!!!
We've only got six bits specified for S/# in ALTDS, so we can use the three bits above to specify write-register alteration, with D[31:23] serving as the pointer for write redirection:
ALTDS D,S/#
S/# = %rrr_ddd_sss
rrr = same as ddd/sss, but uses D[31:23] as a write redirection pointer.
We've only got six bits specified for S/# in ALTDS, so we can use the three bits above to specify write-register alteration, with D[31:23] serving as the pointer for write redirection:
ALTDS D,S/#
S/# = %rrr_ddd_sss
rrr = same as ddd/sss, but uses D[31:23] as a write redirection pointer.
MOVI D,S/# can be used to set D[31:23]
Now we've got it all in one instruction!!!
My first thought was you were going to change the next instruction's opcode.
But what you have done is amazing. Hope it does not take much silicon.
Could we perhaps use the CNT register for NR (It is a read only register)? Maybe a pseudo NR name?
I don't know what to do about the pointer names. They are just different 9-bit fields within the same register.
Good point - Perhaps another approach to name overlaying above, would be a record-style syntax
so the S and D sub-fields, are treated as records.
MOV operand becomes generic, and Name.D -> MOVD, Name.S -> MOVS, Name.I -> MOVI
As the opcode is identical, both syntax forms could be supported.
MOV ptr.S,#from
MOV ptr.D,#to
REP #count,#_LoopS,_LoopE ' Loop between _LoopS,_LoopE count times, Self adjusts and also checks for needed delays if any.
:_LoopS
MOV [ptr.D++],[ptr.S++] ' actually two instructions: ALTDS and MOV
.. other code
:_LoopE
In this ASM code, what is written is what actually happens, so it is easier to follow and edit than the naturally confusing form of
MOV [ptr++],[ptr++] ' user wonders, is ptr +2 at the end of this ?
whereas .D++ and .S++ shows clearly what is being INC'd - the 9 bit subfield records.
Tiny point; I'd swap the increment and decrements over, so a '1' LSB corresponds to 'add one' (zero LSB would be the -- ) . Not a big deal, and yes the compiler would hide this anyway
:_LoopS REP #count,#_LoopE-LoopS
MOV [ptr.D++],[ptr.S++]
.. other code
:_LoopE
Rather than have the extra lines, can't we simply put something in the MOV instruction that indicates it's D & S fields are being modified?
I find the whole record thing confusing personally, and I prefer MOVD and MOVS, because they will be used by themselves. Typically, we just label the instruction to be modified, and that's clear.
? The typing of the two forms is exactly the same, but the benefit of the dual label form, is the first label can be syntax checked for any required preamble delays.
Users cannot miss-format their REPS blocks using my simple approach.
It's more verbose, and I would much rather keep that to a minimum, and:
rep #50, #3
add dest, #5
and dest, #1100
mov temp, dest
Is still valid, brief, easy to read, while also permitting people to add the complexity where they want it, and where it will pay off. It won't always pay off, and when we get inline in SPIN, we may well want simple, easy to read PASM bits here and there. The less verbose the better, and that's what SPIN is about too, while both are easy to read.
And are we even going to have delays? Chip?
Splitting the middle:
:loop1 rep #50, #:loop2-:loop1
add dest, #5
and dest, #1100
:loop2 mov temp, dest
It's more verbose, and I would much rather keep that to a minimum, and:
If you apply that (quite strange) logic then you should be coding directly in HEX, after all,
rep #50, #3
Is more verbose than the most compact form of a hex opcode 0xabcd, and you have claimed you like to keep to a minimum.
Why do you not do that now ?
Simple, because you want the tools to do work for you. Let them work for others too.
Most programmers I know (or would employ) consider code reliability way above file size.
Comments
Somewhat concerned now about how much logic/power the "smart pins" are going to use.
Maybe later in the design process explore a way to power-gate OFF a lot of this functionality/power in those pins?
Yes. The SysCLK is already routed to all the pins, for sampling work, so that clock-bus power is fixed,
A Binary counter, Qn side, only draws as much power as two FF's toggling at fSys/.2
The Clock tree to the counter register chain will draw some power, but it is very local and short.
Likely that part will be Gated by the Activate command.
Die-area is likely to be a larger issue, than power when looking at IO pin cells.
(that and also meeting the 200MHz target)
My first thought was: Isn't "cmps D, S wc, wr" the same as "subs D, S" ? However it looks like the C flag is handle a little differently for CMPS verses SUBS.
I'm not sure if Chip did the change to drop the WR/NR bit from instructions or not, but I could see how they might be useful in some rare cases.
I have used CMPSUB NR myself. Need to think about this one !!!
CMPS WR is an interesting one. Need to think about this one !!!
OR NR,WZ is a nice dual test for zero! Replace with 2x TEST instructions
ADD x,#1 WZ,NR could be replaced with CMP x,allones WZ (allones long $FFFFFFFF - uses a register)
CMPS x,y NR is just a CMPS x,y. No issue here.
Sorry, I haven't been in this forum for a few days so this 40-freaking-page thread just popped up and I only had time to skim it, not read everything. If these are stupid questions that have already been answered, please forgive me.
I really like the idea of going back to basics with the P1+ (or whatever this thing will be called), I thought the feature creep has been completely going out of hand since last year's failed shuttle run.
Some things I haven't seen answered yet:
1. So TV-out is gone, but if it will run at 200MHz and 100MIPS and it has D/A converters, shouldn't it be possible to generate CVBS from RGB data on the fly? Or at least convert RGB to YUV on the fly and use some external circuitry?
2. If the instruction set is going to be source-compatible with the P1 but not binary-compatible, won't that break pretty much all self-modifying code? I bet there's a lot of that around, and it won't be possible to simply convert it automatically, it will have to be rewritten.
Thanks!
===Jac
The reason that a CALLINDA cannot be used is that in the second clock, the return address is written. It would also require INDA to be incremented and written.
* Perhaps the CALLINDA could take 4 clocks, and the instruction itself perform the INC INDA in clocks 3 & 4.
* Perhaps we could modify the fixed address $1EF CALL instruction to use INDA as a pointer to where the return address would be stored. For the fixed use case (GCC etc), the program would need to set INDA to $1EF (or wherever) at initialisation.
With this change, we could use INDA as the pointer to a stack. INC and DEC of INDA would need to be performed by the subroutine like this...
CALL SUB1 'uses [INDA] to store the return address.
...
SUB1 ADD INDA,#1
...
SUB INDA,#1
RET 'uses [INDA] for the return address
To PUSH and POP we would also have to use a group of instructions...
ALTD INDA
MOV 0,<value>
ADD INDA,#1
and
SUB INDA,#1
ALTS INDA
MOV <get>,0
While not ideal, it is a solution, and is faster than using hub. It only requires a minor change to the existing fixed CALL instruction, and gives the side effect of being able to set the fixed address anywhere in the cog when used as the fixed call.
SHR and ROR are alreday covered by the TEST d,#1 wc instruction.
The part in boldface ... Oops! How'd that get in there?
-Phil
Not sure yet how color space conversions will get done. Maybe they just won't and we can use lookups and simple formulas to make it more simple.
The hardware color space engine in the other design is too much of a beast for this process. IMHO, going VGA only makes sense. That really means software drivers like we did on P1, and we have a nice selection of those to port, and we get much better signal quality and color depth.
We can look forward to the beast in the smaller process someday.
I suppose a color lookup COG could get a lot of the functionality done. Or not, depending on what people need. With mor cogs in the mix, having one to do that might not be a worry. Color redirection was expensive on P1, unless it was two or 4 color. On this chip, it looks like we won't get any in hardware, but we get a lot more COGS!
If desired, we still get the very high color depths though, and resolutions somewhere around XGA. Lower bit depths should still get us HDTV. Component isn't a huge challenge compared to VGA, but we will have to manage the DAC output for sync levels ourselves. Not sure what Chip has planned there.
When the dust settles, maybe Chip might add it into one of the cogs on the quiet???
But we get speed, lots of COGS, a huge HUB RAM space, smart pins, ability for a COG to run a PASM program out of the HUB memory directly, etc...
That all means better, faster C performance and more library code makes sense, and it won't have to be LMM, so a lot of things just get a little nicer, easier, more roomy.
@Cluso: Composite color will happen anyway. I use it all the time myself. If Chip can put it in, great! If not, we have good P1 code for doing it manually. Eric Ball was nice enough to entertain a couple of projects and got us there in a couple of useful ways.
Should perform comparably to what the other design did, minus the nice color space hardware. I'm starting on it the moment we get an FPGA. TV is just too useful not to.
INDA/INDB had pre- and post- increment and decrement. We could achieve something similar by extending the ALTD/ALTS instructions:
Wait! We could do even better by treating one D register as two separate 9-bit fields which get pre/post-inc/dec treatment based on some S/# pattern:
ALTDS2 D,S/# - Set next D and S fields to some pre/post-inc/dec combination of D[17:9] and D[8:0]
That way, one register can be two pointers, with separate controls. Ultimately, a two-instruction combo could, for example, be coded as:
MOV [ptr1++],
The D register fields could be modified, or not. This could make cog-RAM stacks easy to implement.
Sounds exactly what Bill was asking for in #768
http://forums.parallax.com/showthread.php/155132-The-New-16-Cog-512KB-64-analog-I-O-Propeller-Chip?p=1259835&viewfull=1#post1259835
Maybe I'm missing something, but I would think that ALTD/ALTS would support the increment/decrement capability we know from INDx. If so, then PUSH would be:
MOV [SP++], reg
or
ALTD SP++
MOV 0, reg
and POP would be:
MOV reg,
or
ALTS --SP
MOV reg, 0
(note: I used "SP" instead of "INDA" to avoid confusion with the registers that were formerly at $1FE/$1FF, and no longer exist with this scheme.)
Chip answered before I hit the submit button... he's covered it.
ALTDS D,S/# - Selectively alter D and S fields in next instruction by using D as dual 9-bit pointers with S/# specifying the mode
S/# = %ddd_sss
ddd = 000: don't alter D field of next instruction
ddd = 001: alter D field of next instruction by substituting current D[17:9]
ddd = 010: <some mode we could define>
ddd = 011: <some mode we could define>
ddd = 100: alter D field of next instruction by substituting current D[17:9], increment current D[17:9]
ddd = 101: alter D field of next instruction by substituting current D[17:9], decrement current D[17:9]
ddd = 110: alter D field of next instruction by substituting current D[17:9]+1, increment current D[17:9]
ddd = 111: alter D field of next instruction by substituting current D[17:9]-1, decrement current D[17:9]
sss = 000: don't alter S field of next instruction
sss = 001: alter S field of next instruction by substituting current D[8:0]
sss = 010: <some mode we could define>
sss = 011: <some mode we could define>
sss = 100: alter S field of next instruction by substituting current D[8:0], increment current D[8:0]
sss = 101: alter S field of next instruction by substituting current D[8:0], decrement current D[8:0]
sss = 110: alter S field of next instruction by substituting current D[8:0]+1, increment current D[8:0]
sss = 111: alter S field of next instruction by substituting current D[8:0]-1, decrement current D[8:0]
Usage could be made simple by the assembler:
Did you mean to have two separate pointers here ?
This also underlines the need for cleaner assembler version of REP (seems that is still in this ?), as the two count is not clear in the MOV, but is handled easily by the Assembler in this
I don't know what to do about the pointer names. They are just different 9-bit fields within the same register.
You're right about REPS needing some automation on the code size.
Nice Chip!
A cool variant of "TARG".
Maybe one of the undefined modes could be used as a "NR" substitute. (Dummy write)
Brian
I have wondered if an AUGDS #d,#s might be useful ?
One instruction can add the upper 9 bits (#D & #S) to both D & S of the next instruction (makes 18 bits total - we only need 17 for now, but nice to reserve 18 bits for sw compatibility if you make a 1MB hub version later.
Great idea!!!
We've only got six bits specified for S/# in ALTDS, so we can use the three bits above to specify write-register alteration, with D[31:23] serving as the pointer for write redirection:
ALTDS D,S/#
S/# = %rrr_ddd_sss
rrr = same as ddd/sss, but uses D[31:23] as a write redirection pointer.
MOVI D,S/# can be used to set D[31:23]
Now we've got it all in one instruction!!!
But what you have done is amazing. Hope it does not take much silicon.
Could we perhaps use the CNT register for NR (It is a read only register)? Maybe a pseudo NR name?
Good point - Perhaps another approach to name overlaying above, would be a record-style syntax
so the S and D sub-fields, are treated as records.
MOV operand becomes generic, and Name.D -> MOVD, Name.S -> MOVS, Name.I -> MOVI
As the opcode is identical, both syntax forms could be supported.
In this ASM code, what is written is what actually happens, so it is easier to follow and edit than the naturally confusing form of
MOV [ptr++],[ptr++] ' user wonders, is ptr +2 at the end of this ?
whereas .D++ and .S++ shows clearly what is being INC'd - the 9 bit subfield records.
Tiny point; I'd swap the increment and decrements over, so a '1' LSB corresponds to 'add one' (zero LSB would be the -- ) . Not a big deal, and yes the compiler would hide this anyway
:_LoopS REP #count,#_LoopE-LoopS MOV [ptr.D++],[ptr.S++] .. other code :_LoopERather than have the extra lines, can't we simply put something in the MOV instruction that indicates it's D & S fields are being modified?
I find the whole record thing confusing personally, and I prefer MOVD and MOVS, because they will be used by themselves. Typically, we just label the instruction to be modified, and that's clear.
movd target, #value …some code target mov 0-0, sourceFar easier to agree on a "ptr" convention, like we have done with "0-0" in the past to indicate the instruction itself is being modified.
One thing I really like about PASM is that it doesn't need to be all that verbose, and it's expressive.
? The typing of the two forms is exactly the same, but the benefit of the dual label form, is the first label can be syntax checked for any required preamble delays.
Users cannot miss-format their REPS blocks using my simple approach.
It's more verbose, and I would much rather keep that to a minimum, and:
rep #50, #3 add dest, #5 and dest, #1100 mov temp, destIs still valid, brief, easy to read, while also permitting people to add the complexity where they want it, and where it will pay off. It won't always pay off, and when we get inline in SPIN, we may well want simple, easy to read PASM bits here and there. The less verbose the better, and that's what SPIN is about too, while both are easy to read.
And are we even going to have delays? Chip?
Splitting the middle:
:loop1 rep #50, #:loop2-:loop1 add dest, #5 and dest, #1100 :loop2 mov temp, destGets a nice, neat, vertically sparse block.
If you apply that (quite strange) logic then you should be coding directly in HEX, after all,
rep #50, #3
Is more verbose than the most compact form of a hex opcode 0xabcd, and you have claimed you like to keep to a minimum.
Why do you not do that now ?
Simple, because you want the tools to do work for you. Let them work for others too.
Most programmers I know (or would employ) consider code reliability way above file size.
Yup, sure,
That's exactly what I have done above.